If you are trying to implement any kind of architecture management you have to start documenting the architectural decisions you have made to keep future developers aware of the problems that were faced and why they where solved that way. But what information should be kept? One model I have used in the past is the Tyree-Akermann model (published in IEEE Software March/April 2005). This captures the issue, the alternative solutions considered and, of course, the decision itself. In addition, the model is extended with information that supports the decision (e.g. architectural principles, business factors).
This isn’t the only model that can be used. IBM have developed one in some detail and the ARC42 project has, as part of a software documentation template, developed an implicit model (only in German).
Now, one way to go, would be to consolidate the models to derive a "universal" architectural decision. However, since reading "Architectural Design Decisions as Reusable Design Assets” by Olaf Zimmermann (originally published in IEEE Software Jan/Feb 2001, but now available here), my thinking has been pushed into concentrating on using the decisions to provide a knowledge base for other architects, i.e. reference architectures.
Zimmermann’s paper proposes, that when creating a reference architecture, not only the component, connector, patterns etc. are documented, but also the issues that the architect has to solve together with the design alternatives available in applying the reference architecture to a real situation. These issues - complete with alternatives and recommendations - form a guidance model. This guidance model is then tailored to the project situation to produce a decision model and extended with the actual outcomes.The beauty of this simple scheme is that the guidance and decision models have the same structure making it easier to extract best practices from completed architectural documentation. Zimmermann goes into a lot of detail about this, but I have tried to summarize it with the following two diagrams:
1. The structure of the models. Although Zimmerman uses a SOA reference architecture as an example, the principle can be applied to any reference architecture as I’ve tried to show in the diagram.
This isn’t the only model that can be used. IBM have developed one in some detail and the ARC42 project has, as part of a software documentation template, developed an implicit model (only in German).
Now, one way to go, would be to consolidate the models to derive a "universal" architectural decision. However, since reading "Architectural Design Decisions as Reusable Design Assets” by Olaf Zimmermann (originally published in IEEE Software Jan/Feb 2001, but now available here), my thinking has been pushed into concentrating on using the decisions to provide a knowledge base for other architects, i.e. reference architectures.
Zimmermann’s paper proposes, that when creating a reference architecture, not only the component, connector, patterns etc. are documented, but also the issues that the architect has to solve together with the design alternatives available in applying the reference architecture to a real situation. These issues - complete with alternatives and recommendations - form a guidance model. This guidance model is then tailored to the project situation to produce a decision model and extended with the actual outcomes.The beauty of this simple scheme is that the guidance and decision models have the same structure making it easier to extract best practices from completed architectural documentation. Zimmermann goes into a lot of detail about this, but I have tried to summarize it with the following two diagrams:
1. The structure of the models. Although Zimmerman uses a SOA reference architecture as an example, the principle can be applied to any reference architecture as I’ve tried to show in the diagram.
2. A (simplified) process showing how the guidance and decision models are used in architectural design.
Two main challenges still remain though - getting your architects to document their decisions and setting up an organisation and processes that can actually extract and propagate architectural best practices.
No comments:
Post a Comment