Ruminating on an Architecture Assessment...
Recently I got a chance to assess the IT architecture of a major Telco in the North Americas. Organisations, off late, have realized that Architecture is the sole guiding light, that ensures that the IT systems design and development stays in line with business strategy and business vision, and they also want to ensure that what they have built is, in line with what everyone is building, across the industry. Sound software architecture is the key ingredient in a business or an organization's technological success. But, It is one thing to come up with a good architecture and another, to assess it. It is often said that art is a tryst, for in the joy of it the maker and the beholder meet. But this is not entirely true for software architecture. The more you, as a reviewer, don't see the maker's point, the better chance you have, in judging it. Of course the fact that you should be an artist yourselves in order to appreciate or judge art applies to architecture as well.
The usual method that springs into mind when we
want to evaluate architecture is the Architecture Trade off Analysis Method
(ATAM). One aspect of ATAM, that makes it so widely accepted is that, it is
domain agnostic, focussing mainly on the Quality attributes. It is good in a
way that you are equipped with some ammunition when you are out there to assess
someone's architecture, but that's not good enough when you have to make a
functional assessment as well. And this is where you enter deep waters.
Domain specific industry standard bodies like
TM Forum, Automotive Industry Action Group (AIAG), Rosetta-net, HL7 (Health
Level Seven), OFX (Open Financial Exchange Consortium) provide the guiding
lights here, depending on which industry you are dealing with. For example, the
TM Forum spells out clearly suggestions on how your telecom applications could
look like with functionality mapped to each application in its Telecom
Applications Map. These suggestions carry well thought out ideas and experience
from leaders across the specific industry. These suggestions could be used as
benchmarks when reviewing an existing architecture.
Equipped with ATAM and knowledge of domain
specific Industry guidelines you are now reasonably well armed to start out on
your assessment exercise. Again that is still not enough. You still have to
know what you are assessing and what your architecture is aiming to achieve.
And these are uncharted waters for you.
This is where we need to understand what the architecture in question has been aimed at achieving in the first place. And this is when you need to stand in the architecture makers shoes. This will tell you to some extent on why certain aspects of the architecture have been built in specific way. This is when, you have to understand the business and IT objectives which the architecture was set to achieve. At this point it seems we are all set to validate the architecture aspects against the business and IT objectives at the enterprise level except that the business and IT objectives mean different things for different people. A "View" is the term that is used to describe exactly that. The TOGAF defines this concept as follows "A 'view' is a representation of a whole system from the perspective of a related set of concerns. A view is what is seen from a viewpoint. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture". It is worth noting that other frameworks like IAF & FEA have similarly recognized this concept of defining a set of related concerns in more or less similar terms. Thus it is evident that different stakeholders are interested in different aspects and areas of architecture. Here comes the most important aspect that is to be kept in mind, which is the plurality of goals which may be at odds with each other. Similar to this, is the related aspect of plurality of the means, each of which provides a varying degree of help or hindrance in achieving a given goal can also be reviewed.
So the knowledge of the following aspects which
contributes to the plurality of the goals and means is very important before
embarking on our review,
v Complex trade-offs that have been made while balancing objectives like
functional and extra (non) functional dimensions.
v Stakeholder
involvement
v Architectural
style followed and constraints
Armed with this information, we can now proceed
to review the architecture at hand. At this juncture a few words on
architecture representation will not be out of place. The 4+1 view of architecture
representation will be useful and handy, that can quickly give us a good view
on what is being served. The logical, process, development and the deployment
views combined with the use case view provide a complete representation of the
architecture. Whereas Views focus on the overall structure and behaviour of the
architecture, a Perspective is used to denote a term which builds on the core
views to highlight the way in which a particular quality-property is addressed
by the architecture. Thus perspectives could be Security perspective,
Performance perspective, Availability perspective etc. Finally it is customary
to serve out the review report to the interested parties spiced up with all the interesting ingredients. This takes the form a
report listing the positive as well as the negative aspects of the Architecture.
Yes, don't forget to serve the plus points of the architecture to start with...
