February 24, 2007
Presenting an Architecutre
We’ve nearing the end of the second iteration of the main project I am running this year (a multi-modal biometrics backend platform), and we're scheduled to do an architectural review (and demonstrate a working architectural skeleton).
So here I am again, preparing an architecture presentation. The first thing I do when I have to describe architecture is choose which views to present. This time I decided to build the views around the key quality attributes (those that were highlighted in the system’s utility tree).
So what’s the structure of this presentation?
The presentation begins with a system overview which includes the vision and key scenarios for the system.
The next view is an architecture overview which has a block diagram, major components (and sub-systems) and the major decisions (e.g. the leading architectural style for the system is SOA etc.)
Next I have a functional view where I’ll present how some flows go through the architecture. This can either use communication diagrams or maybe I'll present them on top of the block diagram.
The next views are performance and scalability, security and privacy, flexibility, adaptability and extensibility, compliance and standard, testability and maintainability. Each of these views has a main presentation and a set of decisions. For each decision I present the alternatives and why the decision was made
Lastly I am going to show some of the design highlights -- these are major design construct for each component that show how the architectural decisions have been translated into design
This structure is a little different from previous presentations I used. One view I usually have is what I call the "module blueprint" which shows how the design and call sequence for a nominal flow would look like when it is built in the system. However, for this project this is too early in the game for that we have a few flows but it as we will implement more we will finalize the design details. Also we plan to produce a software factory and more guidance as part of the release of the platform, since the platform itself is not an end product rather it is an infrastructure for building solutions.
Another view that is missing this time is deployment view -- this is included as part of the performance and scalability viewpoint. Again the main reason for this difference is that the system is a platform and not an end-product.
It is important to select appropriate views for the system you build. Granted there are some views that will be more common than others, but in the end each system is unique.
Posted by Arnon Rotem-Gal-Oz at 11:47 AM Permalink
|