In my opinion, one of the difficult tasks for a solution architect is to pick up a new project based on an existing solution landscape and not fall into the trap of reinforcing past mistakes.
This blog looks at what artefacts an architect should leave behind to help the architect that follows them and who doesn’t have the background to understand every detailed decision that was made. I would hope and expect that my fellow professional architect had left information on:
- The Project Background – This would explain why and when the solution was created and the key events that surrounded its development. This gives the historical context to explain critical design decisions. For example, the initial release for a major systems often has a large number of major architectural compromises. Typically, these are made due to rapid decision making driven by a need to drive early benefits realisation.
- Terminology – It is always worth clarifying the terminology being used. Industries, organizations and programmes all create their own languages. These may be acronyms, code words, system names, department names, nuances on standard industry terms, or specialized industry terms that newcomers to the industry will find opaque.
- Key Drivers, Design Principles, Standards and Constraints - A simple, easy to read set of business and IT drivers, principles and constraints that have shaped the solution are documented and form the rationale for the business and IT solution.
- The Business Problem – High level requirements, business process models showing the change from the current processes to the new. The changes in business volumes should be described e.g. forecast sales increases, faster case turn around times.
- An Information View – descriptions of the major data objects and their usage from a business perspective.
- A Risk View - Architectural decisions are often compromises and are often taken without full information. This creates risks that the solution may not be fit for purpose or may not be fit for the future. These risks should be articulated so they can be managed. When information does become available, e.g. new requirements, the original solution may not be ideal foundation – there is a business decision to be made – do we build on a weak foundation and create an expensive legacy but gain benefits earlier or do we re-engineer the solution or is there a middle route?
- An Application View – I look for at three levels. First, a high level conceptual view, this is something that I can discuss with senior business senior stakeholders and show how clearly purposed conceptual applications should meet the requirements at a logical level. Second, I want a more detailed logical view showing logical components of the applications and the logical services provided by each. This allows me to discuss specific functional areas with the business, it is also the key cross over point into the physical application world – it is where we translate business language into IT language. Third, a physical view that identifies specific physical components that map to the logical components, their functionality and services, whether they are bought, reused or built, their key non-functional characteristics, descriptions of any compromises made.
- A Data View – Again three levels, conceptual where the major data objects identified in the Information View are mapped against the conceptual applications. A logical view does this at a lower level and will include all data required. The physical view will consider the physical application boundaries, the capabilities and non-functional characteristics of application components to determine the correct distribution of data across the physical applications.
- An Integration View – Three levels again! At the conceptual level, I want to see a set of sequenced point to point links between conceptual applications that clearly show how business activities are supported. The integration view is where we see the solution brought to life, we see the applications interact and exchange data, we see them animated. This is where we convince the business that we really understand the requirements and have an IT solution to deliver it. It is also at this point that gaps in the business process and IT solution will become apparent. We must validate the end to end business solution at the conceptual level. Then again we must deep dive at the logical level. Physicalization of the interfaces will introduce interface technologies such as ESBs and ETL, it will rationalise the data content of interfaces, it will determine interface patterns to be used, it will reuse interfaces, it will describe and explain where deviations from the logical view have taken place.
- An Infrastructure View – Infrastructure generally seems to be practiced as a black art. The application architect chats to the infrastructure about non-functional requirements and by magic a recommended infrastructure specification is produced. The magic is in reality the experience of the infrastructure architect. What I would rather see is the expected volumetrics for each node and link in the Integration View that were used to derive the infrastructure specification. When I come to change the solution I can look at the actual volumetrics, the actual performance of the infrastructure, the proposed incremental changes and work with infrastructure architecture to specify any infrastructure changes.
These are ten things that I would like to see when I pick up a project. By following the disciplines that require you to create this information as part of the design activity you will almost inevitably create a design that has what we we used to call “conceptual integrity”:
- Functionality is grouped logically according to the age old rules of coupling and cohesion.
- Data is grouped logically according to the age old rules of coupling and cohesion.
- Data is sourced from one and only one place.
- Functionality resides in one and only one place.
Violating these sometimes idealistic rules makes the architecture more complex, increases costs, increases delivery times, increases error rates, and reduces the benefits of our work.
Do I think there should be masses of documentation? No! There should be just enough to maintain and support a solution for many years into the future. A solution will endure much longer if it has a clear conceptual architecture based on a clear understanding of business needs and the conceptual integrity of the solution is maintained.