How to Get Ahead in Architecture
Architecture Map
Implementing a system architecture in an existing technical and organisational environment must be done from the basis of knowledge. Members of the Core Team will without doubt be closely familiar with some of the structure and history of the current state of systems, having been involved in their development and deployment. But to share this knowledge it needs to be expressed consistently and at a suitable level of abstraction.
* * *
A large organisation will invariably host a complex system ecology. Knowledge of the history, purpose and state of this ecology are held at inconsistent levels of detail in different forms. In particular, the way the systems co-operate will not be clearly stated – indeed, this knowledge may be buried in the systems themselves and in the business procedures which have grown up around them.
Picture an organisation which has seen significant investment in computer systems for twenty years. The mix of systems will reflect several generations of technology, process, management and culture. Some systems will certainly have fallen by the wayside, but even earlier architectural initiatives will have failed to effect mass extinctions of previous technologies. Information on how and why these systems were built, and particularly information about how they co-operate, will be dispersed: in documents of different ages and forms, in the imperfect memories of staff who, even if they are still around, are now likely to have other responsibilities, in the systems themselves and in the manual procedures which surround them. Making any attempt to migrate from a situation of this sort requires accessible and regularised knowledge at a relevant level of detail about the way the system ecology works.
Therefore:
Make a map of existing systems. Identify system owners and experts. Capture a consistent set of information methodically by means of interviews, forms, questionnaires. Concentrate on existing integration technologies, whether manual, file-based, feed-based, database-centred or whatever.
Regard this initiative as providing a map of the current environment. Calling it an inventory or catalogue diminishes the importance of capturing the interactions of systems, and can make it seem as if the architect is merely a bean counter.
The sort of information asked for might include:
For each system:
For each interaction between systems:
Constrain the time spent doing this to no more than two months (after all, it is not an end in itself). Use the experience of earliest interviews and responses to fine-tune the process – indeed, make the process as a whole iterative. Make the information acquired from the exercise easily available.
Note that if a given system A provides data to a second system B, it is the owners of system B who are more likely to be able to tell you what you need to know about the interface between the systems.
* * *
While the architecture map serves as an essential starting-point for planning a coherent move to a new architecture (Migration Roadmap), the information gathered is likely to be of value in itself to many other parts of an organisation (Deliver Value). With careful definition of the information being requested helping to complete this exercise in a short time, it is feasible to produce an early deliverable from the architectural initiative (Frequent Delivery). By involving system owners and their managers the visibility of the initiative is enhanced (Visibility). This is also achieved by publishing the results in a readily accessible form (Website)
© 1998 David Harvey
Created 6 September 1998
Last updated 6 September 1998