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...
