A Blog Post by Bruce Schneier
Link

http://www.wired.com/politics/security/commentary/securitymatters/2009/07/securitymatters_0715

Don't try this at home if you're not very familiar with whatever encryption product you're using. Failure results in a bricked computer. Don't blame me.

Step One: Before you board your plane, add another key to your whole-disk encryption (it'll probably mean adding another "user") -- and make random. By "random," I mean really random: Pound the keyboard for a while, like a monkey trying to write Shakespeare. Don't make it memorable. Don't even try to memorize it.

Technically, this key doesn't directly encrypt your hard drive. Instead, it encrypts the key that is used to encrypt your hard drive -- that's how the software allows multiple keys.
So now there are two different users named with two different keys: the one you normally use, and some random one you just invented.

Step Two: Send that new random key to someone you trust. Make sure the trusted recipient has it, and make sure it works. You won't be able to recover your hard drive without it.

Step Three: Burn, shred, delete or otherwise destroy all copies of that new random key. Forget it. If it was sufficiently random and non-memorable, this should be easy.

Step Four: Board your plane normally and use your computer for the whole flight.

Step Five: Before you land, delete the key you normally use.
At this point, you will not be able to boot your computer. The only key remaining is the one you forgot in Step Three. There's no need to lie to the customs official; you can even show him a copy of this article if he doesn't believe you.

Step Six: When you're safely through customs, get that random key back from your confidant, boot your computer and re-add the key you normally use to access your hard drive.

In this blog post I’m going to highlight some of the design and architecture lessons that I’ve learned so far. In future posts I’ll be drilling down in some of the areas and present concrete examples.

So here is my list so far:

1) Do not forget standard/proven design and architecture patterns just because you are using SharePoint.

SharePoint should be seen as another layer in your technology stack that your code will interact with. But just because you are using this layer you should not forget to follow good and proven design practices. The following points describe some of the principles that sometimes seem to be forgotten when using SharePoint.

2) Create a data access layer to access your lists.

After all you would be doing this if you were programming against a database table so why not do the same for a SharePoint list. The last thing you want is to have several components of your application accessing the same list in several different ways. If the list schema, name or location changes then you would need to change the code in every component that uses that list (this could be acceptable for small proof of concept applications but not for enterprise applications). In a future post I'll be giving an example of designing and coding a simple SharePoint data access layer.

3) Use SharePoint lists to store configuration data. Create a configuration site, on your site collection, containing all the configuration lists.

Before SharePoint all configuration needed by you applications resided in a data store (normally a database). You then needed to build a UI to allow power users and/or administrators to change that information. You also had to implement security mechanisms to make sure that only the users with the correct permissions were allowed to change or access that data. With SharePoint you can accomplish all of that with out of the box functionality without writing a single line of code. You can also adopt the same principle for structured content. For example let’s say that you want to create a very simple top navigation menu (like the one on the top right corner of this page) and allow your users to add new links or edit existing ones. You could create a TopNavs list on a “/config” site under your site collection with “Name” and “URL” columns. You could then create the menu using a simple ASP custom control and bind it to the TopNavs list. I’ll be showing how to do exactly that in a future post.

4) Do not forget about databases.

Just because you are using SharePoint and have all of those nice lists that you can easily create and configure it doesn’t mean that you should stop using databases (disregarding the fact that SharePoint is actually storing all of the list data on a database). You should always ask yourself the reasons why you should use a SharePoint list instead of a database table. Remember - SharePoint is a service layer - so if you are not using the services provided by that layer then perhaps you should be using a database table instead. SharePoint lists also have greater limitations than database tables (see this Microsoft document for more information on those limitations).

5) Empower business users but try to keep them in their comfort zone.

I know that this sounds like a sales cliché but it’s actually one of the main SharePoint selling points. You should ear this sentence echoing in the back of your mind every time you are talking to a customer. This will help you making better decisions and keep your customers happy. Here is an example:
a. You are responsible for the architecture and design of a brochureware site for a major financial institution. One of the main reasons for them to adopt SharePoint was to give more control to business users. You decided to base the site on the out of the box publishing site definition and you are just about to test your first content page (which is using the out of the box Rich HTML editing control).You look at the generated html code and suddenly freeze. Your heart starts pumping faster and you cannot believe on what your eyes are telling you; the HTML code generated by the control is appalling. Your professional pride kicks in and tells you that you cannot be responsible for code like this.

What do you do?
i. Talk to the customer about the problem and suggest replacing the control with a “professional quality” third party editing control (they would need to agree the extra costs).
ii. Tell the customer that you cannot be responsible about the quality of the codegenerated by the control and ask them to make a decision. You can point out that, although the quality of the generated code is far from ideal, it can be a viable option as long as they are not concerned with accessibility issues.
iii. Tell the customer to continue to use the control and teach them how to improve the code by showing them the control’s HTML view.
Option (iii) is the least appealing one because it will require your business users to step out of their comfort zone and learn something that they shouldn’t need to for their day to day jobs (unless they are technical minded and do not mind the learning curve).

A Post by Elizabeth
Link :
http://www.pm4girls.elizabeth-harrin.com/2009/07/recovering-troubled-programmes-2/

Here’s the 5 step ESI process for getting out of trouble. The whole approach assumes you have been parachuted in to fix someone else’s flailing programme, which I suppose is what ESI do. You can adapt the steps if you are trying to turn your own programme around, or make the steps smaller to turn around a project instead of a whole programme.

Assessment Phase
Step 1: Define CharterDuration: 1-2 days
This formally sanctions the existence of an assessment and recovery effort. It provides the assessment and recovery lead with the proper authority to complete the activities necessary to develop an assessment plan.Define the charter with the sponsor and steering committee. The charter should cover:
Programme history and sensitivities (although I wouldn’t write all this down)
Assessment approach: how many people are you going to interview, in individual meetings or in group sessions etc.
An action plan with dates
Then get it all agreed – which is what the charter is for. In this step you would also initiate contact with the programme and project teams.

Step 2: Develop assessment plan
In this step you aim to achieve the objectives of the charter. This allows the assessment team to perform their assessment quickly, ensures accurate findings, and minimises distractions for the project team. After all, you want to keep going with things that are progressing well.
Establish a team
Review and analyse the assessment model (how are we going to review documents, how are we going to move forward with analysis)
Review critical documents
Develop assessment plan
This is a formal step, so get the plan signed off.

Step 3: Conduct assessment planDuration: 2-5 days
In this step you determine the true current status of the programme and constituent projects. You identify major threats, opportunities and problems. You begin to consider the recovery as well as who would be on your recovery team.
Establish a war room
Assemble the team
Implement the assessment plan (interviews and document review)
Aggregate and rank-order the findings from the most problematic to least problematic
Validate, update and finalise findings with programme team and sponsor

Recovery Phase
Step 4: Develop recovery plan
This step leads to a plan to get to a functioning programme. You establish a road map and process to achieve the goals, and continue to build confidence and morale.
Prepare a plan that everyone sees as realistic and achievable: this helps build confidence. There is no Plan B for this recovery plan: this is it! The goal is to save the programme from loss and restore it to usefulness, preventing total failure along the way.
Produce an achievable schedule
Re-establish customer management confidence
Negotiate a new baseline

Step 5: Conduct recovery plan
In this step you execute your recovery plan to return the programme to usefulness. You validate estimating methods and their accuracy. This allows you to produce an accurate forecast of programme completion. Begin with the end in mind: a programme that is no longer in recovery.