Chief Architect - Enterprise Architecture Blog

Solution architecture is a compromise between desire and possibility. The project stakeholders want everything instantly, even those things they haven’t thought of yet, at zero cost with zero defects. We are not there so we have to trade-offs We make compromises over:

Involvement – we do not consult all stakeholders, we accept that some users may not get the features they want, we accept that we may create mis-alignment between business processes, we accept that we may make another stakeholder’s job more difficult, we accept that we may not capture all requirements
Requirements – some requirements are de-scoped, some tasks are not automated, we accept a less than 100% solution, we work on the Pareto principle
Future proofing – we accept that there is not always time or resources to identify the best long term solution, we accept that we may create problems for other projects later, we accept that our solution may have a shorter life than necessary
Timescales – I wrote about how important the time dimension in the Zachman framework is when scheduling delivery and the need to take it into account in the solution architecture. Business cycles and business events shape the delivery slots available to a project, we must aim to construct projects that start streams of benefits realisation in these slots. This time based project shaping compromises requirements and solution design.
Costs – we choose not buy a software module, we choose cheaper suppliers, we cajole project teams to be quicker, we force code through testing, we skimp on user training, we are less than thorough on defining operational procedures, we delay building redundancy into the infrastructure, we “deliver” to budget.
Quality is defined as “fit for purpose”. Often, we fail to clearly define the purpose of a solution. Who are the stakeholders? What are the objectives and constraints? Unless we know these then measures such as number of outstanding bugs, defect density, number of requirements met find their own context and skew decision making.

Before I take an existing architecture forward I want to understand the compromises made and why. I want to understand:

The architecture and design short cuts taken and whether they pose risk to the next and future releases of the solution. Should my solution lay a roadmap for unpicking these compromises?
The pressures and constraints that have shaped decisions that will either form ongoing influences on the solution or will create risk or will need to be addressed in this release.
If there are political traps that I may fall into when I uncover a major constraint?

In my last blog, I described what documentation that I would like to find when I join a new project to develop the solution architecture. The key c0ntextual information to understand the compromises made are:

The Project Background – To provide the historical context to explain critical design decisions.
Key Drivers, Design Principles, Standards and Constraints – The business and IT drivers, principles and constraints that shaped the solution.
A Risk View – Documentation of architectural decisions that were made without full information and create a risk that the solution may not be fit for purpose or may not be fit for the future.

If this information exists, then it should be reviewed and an initial set of project risks drawn up from it. In the absence of this information, it is diligent to find out what compromises were made in each of the areas above and develop the risk assessment based on this information.