The nature of enterprise evolution and revolution is different:
|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.|
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.
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