Sarquol Limited » architecture

Future Scenarios in Architecture…

admin — Thu, 25 Feb 2010 18:00:37 +0000

I recently needed to consider the state of a System Architecture and consider the changes likely to be needed over time. Thus, I was trying to produce a “Roadmap” for the architecture into the future. The challenge was that the future is uncertain. Some items can be planned for, and others are dependent on the way the business and technological environments develop. These developments can be considered to be the product of various “forces” playing out in the environment of the system. How then can you address this complexity?

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.

From the news… SOA – the next big performance problem

admin — Fri, 07 Apr 2006 10:20:42 +0000

It would seem that “Service Oriented Architecture” (SOA) is taking off as a technology in fashion. As usual, most of the news is generated by people wanting to sell it as the next big thing ready for the prime time. If followed as it is being sold at present, the concept is liable to lead to significant performance problems. SOA is sold on having a large number of “users” who are then often other systems. This is followed all the way back to the real users through an unknown number of tiers. The complexity of managing this sort of architecture increases significantly as the number of tiers increases. If this is then managed without due consideration for managing the system capacity and performance the result will be problems in the future. That is not to say that I don’t see a benefit in the overall technology – there is great potential. Just consider carefully how the performance of operational systems might be proven to be sufficient for the long term.

Governance of Capacity Management

admin — Fri, 07 Apr 2006 10:18:28 +0000

In a previous employment, the employer had an operational department who were responsible for signing off the performance of a system before it was allowed in to production. Their method for doing this was working with delivery projects to make sure that the project provided sufficient evidence that the system they were delivering would perform in the long term. They would also check that the operational managers had access to appropriate mechanisms to monitor that the systems were performing according to the evidence that had been provided. When requested to do so they would provide expertise to the delivery projects in the appropriate use of capacity management techniques, but they were primarily a gate keeping and monitoring function.

When working with the team I would acknowledge that their approach was effective, but thought it too “front heavy.” The team acted as a limiting factor on the timely delivery of system projects, and the rigour they required was sufficient to manage the system in the long term but seemed unnecessary for pilot delivery. Their assumption was that once a project was delivered to production then there would be no further capacity management applied unless there were production issues – which would then be their problem to see resolved. Thus the system had to be proven as fully suitable for production before it was allowed in. I now have experience of the full lifecycle of a number of projects. This includes being brought into projects when they have run into performance issues a number of years down the line. The governance approach that the employer took was definitely correct, even if they could have been a little more cooperative in letting the system into pilot.

To be clear: A project must plan to provide evidence that the system they are putting in will perform well in the long term. A project must have clearance for, and so sufficient business benefit to fund, the capacity that will be needed to run the system in the long term. A project is not complete until it is proven that it will perform correctly in the long term, and there are monitoring methods in place to make sure that it continues to perform. If a system is allowed into pilot before this point for expediency then the project still has to complete its evidence generation and sign-off before the system is accepted into full operation.