The field of business strategy has looked at this issue of an uncertain future and come up with a number of approaches for managing considering it. One of these is called “Scenario Planning”, and basically consists of building a set of different future scenarios which are considered plausible. They are not attempts at predicting the future, only of painting plausible futures. It is then possible to consider how these scenarios may play out according to the decisions you are taking now. This allows a form of sensitivity analysis on the decisions that you are making.

A process for approaching this would be to:

1. State the architecture decisions that need to be made.

2. Identify the major environmental forces that impact on the architecture.

3. Build four scenarios based on the principal forces.

4. With the scenarios in hand, identify architecture opportunities within each scenario.

5. Examine the implications of the decisions across the range of scenarios.

As an example, lets assume that you need to decide between two architecture design patterns, A and B. For the example “A” provides a highly resilient and fault tolerant solution but involves significant additional hardware, operational administration and development costs over “B”. The decision that needs to be made is whether the extra capability of “A” is justified. If this is a new system then it may not initially require large processing volumes, and may be able to accept a system outage. The scenarios, however, could be used to examine under what circumstances the additional capability would be justified. If the system catches on, for example, how long might it take for the system to become business critical? Would you have time to re-engineer it? This may lead you to decide the additional capability is justified now, or would allow you to understand what changes in the environment might lead to the additional capability being needed.

In terms of the Architecture Roadmap then, the Scenarios developed and decisions taken may then be included in the roadmap. With this in mind a Planning Scenario is chosen. This defines the assumption set on which the roadmap has been built. In doing so, however, the other scenarios are not discounted but used as alternatives to which to architecture should be resilient. Where the architecture isn’t resilient to a scenario, then the roadmap will be able to indicate symptoms that will indicate that the architecture needs to be revisited. These then become business risks that must be managed based on the selected architecture.

All of this seems relatively complicated, so why bother? The answer is that architecture decisions are taken on a regular basis under the in the knowledge that the requirements of the system are known and understood. This may be true of the explicit requirements elicited from users, but these are based on assumptions about the future. In reality the future is generally much more surprising than we would like to believe, and so taking the time to consider what this might mean for the decisions you are taking can be worthwhile. An exercise like this can be considered surprisingly quickly, and may significantly help decision making.

The CMMi has been developed and integrated with other approaches and become the CMMi. This process has increased its apparent complexity, as well as its flexibility. The information on the SEI web site (link) has split into either detailed manuals of CMMi and presentations that primarily seem to say “Why you need to buy in our consultants…” The CMMi has been adopted by large players and so there is a strong consultancy market surrounding it, including training and appraisal of your organisational level. The manuals are reference material and not intended to be a thrilling read. The presentations do well at selling CMMi benefits but don’t offer much in the way of a “how to guide”.

The best links that I found to describe the CMMi to allow a quick “Is this for me assessment were:

Tutorials point:

http://www.tutorialspoint.com/cmmi/cmmi-process-areas.htm

Wikipedia:

http://en.wikipedia.org/wiki/Process_area_(CMMI)

These sites provide an overview of CMMi at a level more suitable for someone who needs simply to understand the core nuggets of wisdom contained in the CMMi. The still are quite long though, so here is a quick summary of the summary…

CMMi is structured to allow consideration of how an organisation does things, for simplicity I will assume it is software development that is being performed. The CMMi assumes that the road to improvement means ending up with a standardised approach for doing this which can be measured, optimised and customised to the situation in a controlled fashion. It has this in common with many “Quality” processes including the international quality standards. It asserts that there 5 levels of maturity:

• Level 0 – Incomplete – We can get there, we’re sure we can. Not sure how though, and sometimes it don’t quite work right.
• Level 1 – Performed – We can do it as long as it is about the same as the last time.
• Level 2 – Managed – We can do it, and we can manage the process.
• Level 3 – Defined – We can do it, and have a definition of how.
• Level 4 – Quantitatively Managed – We can do it, and can provide numbers about how well. After all what you don’t measure you can’t manage!
• Level 5 – Optimising – We can use the numbers as a basis for continual improvement of how well we do it.

The idea of CMMi is to move up between the levels, and the way to do this is to develop various process areas in your organisation at each level. The areas form a structure, so it is very hard to fully benefit from a higher level process until the lower level ones have been addressed.

The processes organised by level are:

Level 2:

• Requirements Management
• Project Planning
• Project Monitoring and Control
• Supplier Agreement Management
• Measurement and Analysis
• Process and Product Quality Assurance
• Configuration Management

Level 3:

• Requirements Development
• Technical Solution
• Product Integration
• Verification
• Validation
• Organizational Process Focus
• Organizational Process Definition
• Organizational Training
• Integrated Project Management
• Risk Management
• Decision Analysis and Resolution

Level 4:

• Organizational Process Performance
• Quantitative Project Management

Level 5:

• Organizational Innovation and Deployment
• Causal Analysis and Resolution

It is likely that if you are having quality or delivery problems that by looking at these process areas in turn and considering whether you “Do that” you can start to gradually improve. The CMMi manuals have a lot to say that can support you, or you can start looking on Google etc. for ideas that might help you improve.  If you need help then seek outside help – it can be value for money. If you need to be certified to a certain level then the game is very different and outside input becomes a necessity.