Business is in constant motion. Our operating environment is continuously morphing, competitors rise and fall, fashion changes, technologies emerge and become obsolete, laws and taxes are modified. Successful corporations must follow the trends and be agile. Change can come in many ways – sometime in the normal flow of evolution, other times as a radical revolution. In all cases, having accurate snapshots of the affected architecture and the targeted future state is rather beneficial. In this post we will look into how such snapshots can be made and maintained.
The nature of enterprise evolution and revolution is different:
| Evolution | Revolution |
| During evolution the business gradually (and usually slowly) catches up to the trends with incremental steps. | A revolution, in contrast, throws out the old in order to include something new. |
| Evolutional changes usually affect only a limited area of the organization. These are performed in projects, and it’s very common to run several of them in parallel. In most cases, the natural development of the different areas, guided by principles and standards, result in the constant evolution of the entire business and IT landscape. | Implementation of strategic initiatives many times result in revolutional changes, which turn a major part of the operation upside-down.In order to achieve the strategic goals, business process transformation, re-organization is often required, which also drags in the replacement of major IT systems as well. |
| People usually have more time to adapt and it often also happens in phases. Yet, clear communication and education are the key. | Revolutional changes have a substantial impact on a number of people through the involvement of the change itself, as well as the implementation of new processes and systems. Shift from the old to the new can be quite sharp and painful and therefore the human aspects must be considered. |
In terms of architecture there are at least two very important stages to be considered, which are relevant for both of these change types: the baseline (as-is) state and the target (to-be) state. The clear understanding of these states (where you are and where you want to be) are vital for any type of transformation.
Snapshots of architecture
There are many ways to represent your baseline and target states. The most convenient way to get started is by creating a snapshot of the current state. This snapshot can take the form of a digital workbook with several sheets, or a highly detailed design using a state-of-the-art modelling tool, or it can go as far as a bird’s eye view presentation showing a high-level layout of the architecture.
Whichever tool is used to contain and present the information, a snapshot is only a static model and it only represents the architecture at the time it was made.
Snapshots can be very useful when initiating a change, but can become inaccurate after some time. We’ve encountered several occasions, where the organisation created a snapshot of one of its states, and referenced it all the time even when it was so obsolete, it completely lost its relevance. As the project progresses the snapshot starts to deviate from the reality:
- As-Is snapshots become obsolete by the time you create them, due to the fact that the company will not remain motionless until you complete the initiative;
- To-be snapshots are threatened by the change requests, which are in fact quite natural. They may originate from gaining a better understanding of the needs during the project, re-prioritizing the requirements, the results of customer testing, changing business and environmental conditions and of course false scoping due to lack of knowledge.
In the lack of active maintenance they reflect the real life state less and less over time. It can soon become a thing of the past, and appear nowhere else but on management presentations. Why? Even though the content becomes obsolete, it looks sophisticated enough so it can be used as a backdrop to show how complex the systems are. The sad news is that, since you will make steering decisions based on a false image and inaccurate information, the gap between the desired To-be state and the one you are actually heading to will become continuously larger.
Interestingly enough, the creation of such snapshots take almost the same amount of time, regardless of the tool used to maintain them. Identifying the depth of data to be represented and the collection of the relevant data takes way more time, than entering it into any form of representation. The most important factors for this kind of survey are the number of component types to be examined, the number of possible connections among them and all of this is multiplied by the amount of instances you have. Please note that, this has to also be factored with the maturity of the target organization, which can speed up or slow down the data collection process.
Related to the time required for such a survey, I can give you some guidance from my experiences. In a relatively complex financial environment it took about four months and a two full-time seasoned experts to collect the data about the 300+ business systems. In a telecommunication environment approximately 200+ business application with cca. 1200 integrations, their mapping to eTOM and TAM, business objects and the underlying infrastructure took 3 months using 2.5 people. This means that it is a rather feasible endeavour.
Shifting to a dynamic and organic architecture model
The knowledge base you establish can and should be the basis of real work by turning it into a working model. Instead of freezing them, do yourself a favour and implement their usage into your daily processes:
- find out where architecture information is needed for decision making and make sure you provide it in an engaging, easy-to-use manner with relevant information. For example, impact analysis reports must be generated before changing any components, just like we detailed it here.
- information will only be relevant if maintained, therefore insert the update of data into the change processes. Eg. If a project is changing the architecture, mark those components from the knowledge base, which are being modified or withdrawn. Add those components that will be established.
Once you’ve established a snapshot it’s significantly less effort to maintain its changes and keep it updated for future use. In this way, you can build up a constantly up-to-date, “living” knowledge base of architecture.
Changes proposed and delivered in evolutional and revolutional programs should also be included in the knowledge base. By doing so, you can actually identify the potential conflicts among them. – But more on this in the next article coming soon. Stay tuned!
About the authors
Gergely Papp
Gergely is an IT Consultant and an Enterprise Software Architect. He ran his consulting company for seven years, now he’s working as an IT consultant. His main interests are IT Strategic planning, high-level architecture design. He’s hobby projects involve household electronics, Linux, Android, web development.
Peter Lakhegyi
Peter develops business and products in Atoll. He has a special interest in agile architecture control practices and therefore likes to get his hands dirty in projects with our tool, SAMU.