There are many architectural methodologies, such as The Zachman Framework and The Open Group Architecture Framework (TOGAF), that provide a comprehensive framework for developing and governing an
Enterprise Architecture1 at all stages in its life cycle from conception through to retirement (or a significant subset of those stages).
Most of the artefacts in these frameworks are predominantly management activities and the traditional architect’s role of setting design patterns and drafting the application framework plays
only a small role in this.
However, an enterprise data architect shouldn’t be concerned with the operational monitoring of the environment once it becomes operational any more than a buildings architect is interested in the
procedures that should be followed to maintain a building once it has been built.
Everything else has its place, but it is the designers that govern implementation, operations managers that govern running the applications and the accountants that control the financing of the
application.
The enterprise architect may want to influence these areas, but they are not a core activity of the architectural function.
Given that, in the next couple of articles, we are going to focus on defining the minimum requirements for an architectural framework.
As many, many other people have previously noted, IT architecture is predominantly a collection of rules and patterns that the architect has applied to solve a particular problem. This is the real
architectural framework and at the highest level covers:
- The architectural principles that define what must be true (or what is assumed must be true) at the boundaries between different components of the domain.
- The architectural patterns that describe re-usable concepts underpinning significant parts of the architecture.
- The architectural component parts that describe how the domain is divided into sub-domains to reflect the business activities and, if we’re lucky, make it manageable.
A key point about a framework is that it should avoid making any mention of systems or applications that currently exist within the enterprise – its main purpose is to provide something that
the operational environment can be compared against once it is built.
The architectural framework is too large a subject area to be covered in a single article so this instalment covers the first item on the list – architectural principles – and explains
their purpose within an objective architectural framework along with an explanation of the underlying principles for defining them.
The Purpose of Architectural Principles
What They Are
Architectural principles mean different things in different contexts.
To a solutions architect, they may include statements about the technology that will be used. To a data architect, they may include statements about denormalisation or database organisation. To a
network architect, they may include statements about routing mechanisms or authentication and so on. Irrespective of what type of architecture is being produced, the reasons and principles
underpinning the architecture are pretty similar.
Architectural principles are critically important in any architecture (not just information technology) because the main purpose of an architectural principle is to set a policy for governing the
processes of developing, implementing and testing the architecture.
At the enterprise level, architectural principles are also about defining the rules that govern the behaviour between sub-domains within the overall environment whilst leaving as much wiggle-room
as possible for each sub-domain architect2 to define “fit for purpose” systems.
What They Are Not
In addition to describing what an architectural principle is, we should also mention what architectural principles shouldn’t be. They are not:
- Business requirements that are a result of business analysis and define the business processes that are to be supported. An architectural principle should not be tied to a particular business
process because obviously if the business re-organises itself (which happens frequently) and the process changes, then the architectural principle becomes invalidated as well. As with
morals and ethics, principles should not be that easily discarded. - Development approaches – some “architectures” such as a model-driven architecture (MDA) are really just describing the software development process, and this should always be left to
the implementers to decide how they want to do it. - Ambitions – architectural principles may be ambitious but should define intent not ambitions because ambitions (1) may not be realistic and (2) even if realistic are just “nice to do”
rather than “must do.” Ambitions are definitely design guidelines. - Service level agreements and other contractual obligations between the IT function and other parts of the business. Most of these are operational in nature, and it should be left to the people
who are going to run the systems to get agreement with the rest of the business. - Business mission statements – statements like “The systems must support the business requirements” or “The IT will be aligned with the business” are both
“bleeding obvious” and pointless statements. Every business area (accounting, human resources, sales & marketing) exists to support the business and information technology is no
different, so why bother saying it!
This isn’t to say that the enterprise architect should not be concerned with any of these areas (because they are all of interest and might inform the choices being made) but rather that none
of these things should be encapsulated in an architectural principle.
The Principles of Defining Principles
Just forming a statement of intent and calling it an architectural principle doesn’t generally lead to a good principle. Instead, like most things that require explanation, they have a clear
set of characteristics that can be objectively defined as being “good” rather than “bad.”
For want of a better phrase, these are the principles of defining principles, and those described here are the most significant traits.
Straightforward
There are many that would argue that if the core concept of each principle cannot be summarised in a single sentence, then it is probably too complicated to easily communicate to other people and
as a result will be unenforceable. If the principle is difficult to define, then how do we expect other people to understand and apply it?
A well-defined architectural principle should be summarised in a single sentence or phrase, although it may be defined in any amount of detail for those that would like to explore it further. (No
doubt using the glossary that everyone is now maintaining as a critical communication tool.)
Unambiguous
An architectural principle is for all intents and purposes a rule stipulating a design constraint that has been applied to the proposed architecture and must be true for all artefacts within the
architecture.
A memo generally referred to in many industry standards as RFC-2119 “Key words to Indicate Requirement Levels” by Scott
Bradner, March1997, defines a number of keywords that should be used to categorise requirements, assertions and rules. The (slightly edited) core of the memo defines the following:
The key words “MUST”, “MUST NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” … in this document are to be interpreted as…
- MUST – This word mean that the definition is an absolute requirement of the specification.
- MUST NOT – This phrase means that the definition is an absolute prohibition of the specification.
- SHOULD – This word means that there may exist valid reasons in particular circumstances to ignore a particular item.
- SHOULD NOT – This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful.
- MAY – This word means that an item is truly optional. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does
include the option. In the same vein, an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the
option.
These were originally intended to provide definitions for writing technical standards and work very well in that area but don’t cover the whole story when defining architectural principles.
When stating an architectural principle, the word “MAY” should never appear because it indicates something that is optional. It is, therefore, a design guideline, and the designer will decide
whether it will be implemented or not.
SHOULD and SHOULD NOT are a little more complex because, as stated in RFC-2119, they also appear to indicate conditions that a designer can subsequently ignore and decide not to adhere to the
requirements of the statement if they feel they have a good case not to.
However SHOULD logically translates into “MUST … EXCEPT WHERE…” and SHOULD NOT translates into “MUST NOT … EXCEPT WHERE …”. In both cases we have an absolute MUST
statement coupled with a set of documented “exceptions to the rule.” It is the exceptions that are important here and as they are identified must be incorporated into the rule and hence becomes
part of the rule.
The absence of the EXCEPT WHERE clause doesn’t mean that the principle must be blindly applied everywhere but does mean that, at the time of drafting the architectural principle, there are no
known exceptions… but one can always be defined later if and when one is identified.
Each architectural principle therefore translates into a Boolean assertion that is either true or false when applied to the design proposals and deployment plans.
That certainly meets our “unambiguous” criteria.
Given the above we can conclude that things that MUST be true are objective architectural principles because the do not give the designer any flexibility in approach, whereas things that MAY be
true are just subjective design guidelines.
Consistent
Hopefully the previous column on definition of terms will have provided sufficient reasons for why consistency is very
important, but it’s worth emphasising here. If definitions are not consistent, then they cause confusion and conflict which slows progress and in the worst cases will guarantee failure of the
architecture because the parts will not fit together properly.
Although it’s not a necessity, the number of principles imposed on a particular architecture should be kept to a minimum because the complexity of the resulting implementation will be
proportional to the number of principles. With complexity, we also have an increased probability that the principles will become inconsistent with each other.
However, even though the principles need to be consistent with each other, we do need to ensure that they are not overly prescriptive and allow some flexibility because strict adherence to one
principle may require a loose interpretation of another principle.
The set of principles must be expressed in a way that allows a range of non-conflicting interpretations. The words that define a principle also need to be carefully chosen so that there will not be
conflicting interpretations.
Finally, architectural principles should not be contradictory to the point that adherence to one principle will violate another.
Appropriate
In order to produce a set of usable architectural principles, it is also important to have an understanding of the activities of the business (both current and future plans) and a realistic
estimate of the resources that will be available. Defining an architectural principle without an understanding of how it will impact the business is a good way to pick a political fight with the
business stakeholders.
For example, stating that “all data-items MUST be maintained through a single database of record that will be the authoritative source for that data-item” is a sound architectural principle to
ensure that the minimum of manual effort is put into actual data maintenance and provide consistency across the entire organisation.
However, there may be many logistical and regulatory reasons why it is impractical to only have one copy of any data-item and, depending on the organisation, it may be necessary to replicate or
distribute some information. For example, consider the following scenarios:
Some countries may have data protection legislation that restricts what can be done with “personal” data and where it can be stored which, in a global organisation, may make it unfeasible to
gather all the personal data together in a single data repository.
Or:
The network latency of both New York, USA and Tokyo, Japan accessing high volatility information stored in the Bangalore, India data centre may cause some business activities to become
unsustainable.
Or:
Two business divisions want to maintain operational independence for some reason (e.g., one of them might be a non-core business and sold off in the future).
Or:
Transaction throughput requirements may require some applications with a high data usage to locally cache data.
Or:
Some applications may have a significantly different view of the data required for their operation and may want it stored in a transformed “ready to use” state rather than do the transformation
every time they access the information.
So, although we start with a single unambiguous architectural principle, we must always recognise that even the most desirable principles may not be appropriate to our particular business and
either ignore the principle or define any exceptions to the rule that may be required.
Robust
Trying to ensure that the selected principles are robust (i.e., unlikely to break or need to be rescinded later) is a key factor in their selection and definition because the “wrong”
principle that doesn’t withstand scrutiny can have a significant impact on the overall success of the project.
Questions we need to consider include:
How may technology changes impact the principle?
This might seem obvious but everything changes and things change faster in the IT industry than most other places – it’s the downside with using technology and employing creative
problem-solvers. Being a highly volatile industry, we seem to bring out paradigm changes in high-level IT architecture every 5 years or so.Unfortunately, as someone once opined3 (and I’m paraphrasing), enterprise architecture is also on a 5-year cycle from conception to final realisation so there will probably be
some sort of major IT shift emerge during that time with the potential to invalidate or make obsolete the architecture.Sometimes there is a foreseeable evolution path, such as from server-based systems (1-tier) to client / server systems (2-tier) to message-based systems (3-tier) to service-oriented
systems (N-tier) or from single processor to multi-processor to distributed processing to grid processing) and if we have a migration path, then the principle is supportable.Although it’s not possible to predict the next big change in IT architecture, we should still keep an eye on emerging technology and consider whether the desired principle would still be
sound.What are the assumptions that have been made in deciding on the principle?
A certain U.S. General Schwarzkopf once stated, “Assumption is the mother of all f**k-ups.” It is certainly the quality of the underlying assumptions that strengthen or weaken any assertion,
and a false assumption will almost certainly invalidate anything derived from it. Architectural principles are no different.Consequently assumptions MUST be documented and should be “tested to destruction” as much as possible in order to ensure that the resulting principle stands up to scrutiny.
What is the cost of applying the principle?
Cost can be measured in many ways other than just money4 – it can cover “availability of materials,” “effort to produce,” “time to produce” or any other quantifiable
measurement – but however we measure it, there is a cost to everything.There are many possible ambitions that look fine on paper but are unworkable once the bean-counters apply the cost / benefit analysis or become unimplementable due to an excessively high
start-up cost. This is always worth establishing before significant time and money is spent on producing the architecture.
Given that we are always dealing with an unclear future, it is not possible5 to be absolutely certain that any of our architectural principles will survive the test of time but applying
group thought and experience to developing them and asking the right questions can only help.
Quantifiable
Only define architectural principles that can be quantified (i.e., where the success criteria can be defined and compared to the actual deployment).
Too often principles are listed that, to say the least, are pretty wishy-washy. Statements like “the architecture must be flexible” are not good architectural principles because
flexibility is unquantifiable so success cannot be measured.
They also need to be “quantifiable” so that the people who have to meet the constraints of the principles know when they have achieved it.
I was once asked in an interview “How would you performance tune a database?” My answer was “What targets are you trying to achieve and in what order do you want to achieve
them?” I then explained that I could take years “tuning a database” and shaving fractions of a second off of different things. It’s a never-ending task; and without defined
success criteria, I would never know when the database was good enough.
The same applies to IT architecture and architectural principles – if the principle is not quantifiable, then how will the designers of each sub-domain know when they have done enough work to
meet the architectural requirements?
They could do it by negotiation with the enterprise architecture team, but that would just make compliance a subjective issue based on who you talk to and what they will agree with.
Even worse, the sub-domain architect could just decide that they meet the criteria, build the application and then have the arguments over compliance later.
I think most people would agree that this isn’t a good position to be in and that it’s much better is to know in advance that the design is “fit for purpose” and not
“subject to opinion” when later reviewed for architectural compliance.
Platform Independent
Enterprise architecture is probably the one area of IT architecture where platform independence is crucial because of how far up in the clouds it is. It needs to be that high-level in order to make
sense of the overall picture of the enterprise.
Being platform independent is a particularly difficult area to be objective about because like-minded people tend to gather together and, being like-minded, will have pretty similar views of the
enterprise6 so it may not always be obvious within the group that a particular assertion is platform specific.
For example, stating that “all transactional interactions between domains will be service-oriented” is a sound (if possibly undesirable) architectural principle, but stating that “all
transactional interactions between domains will be based on web services” is not so sound.
It takes inside knowledge of the IT standards industry to recognise that web services is not a generalised concept but a particular technology that will almost certainly become obsolete over time.
Often a principle can be identified as platform specific if it restricts the consumer of the principle to have only one way of solving a problem or forces them to adopt a particular niche
technology to the exclusion of any other.
Probably the simplest approach to ensuring that a principle is platform independent is to have it reviewed and challenged by external parties who have no vested interest in the outcome of the
review and don’t come from a similar background as the author of the architectural principles. Ideally, the author shouldn’t even know the reviewer but that might be unfeasible.
Handing Out “Architectural Waivers”
In an ideal world, each new architectural initiative would be a green-field project and everything that existed before could be ignored. Unfortunately, the opportunities to do that are few and far
between. For the majority of us, there will be a whole mess of existing business applications and systems that will either need to be integrated into the proposed architectural framework or
depreciated once a replacement is in place.
The choices we have are either (1) make the architectural framework flexible enough to accommodate what already exists; (2) carry out a planned migration so that the existing systems are conformant
with the target architecture; or (3) specifically allow just that component to be non-conformant.
The second option is always the desirable path but sometimes option three has to be taken because of other business pressures. If so, then we need a formal means of deferring conformance –
namely the architectural waiver.
There are only really three things to say about architectural waivers, which are:
-
Waivers should be handed out when an exception to the rule isn’t desirable. The problem with an exception to the rule is that it becomes part of the rule so it becomes acceptable practice
for every one else as well. This may not be what we want. -
Whenever a waiver is asked for, then a divergence / convergence plan should be produced to explain how the non-conformance will affect other components of the architecture and what will need to
be done in the future in order to conform to the architectural framework. -
Once convergence is achieved, there should never be a need for that component to ever diverge from the architectural framework again. Only legacy (pre-existing) functionality can ever be
non-conformant, and there is never a need for new functionality to not conform to the architectural framework. Hence, once convergence is achieved, architectural waivers are no longer required.
Conclusion
Hopefully this article has provided a useful overview of the architectural framework and architectural principles – what they are, what they are not and the principles that should underpin
defining them.
In my next column, we will consider architectural patterns and the value they add to the architectural framework.
End Notes:
-
As discussed in the previous article on Definition of Terms every item that is capitalised is the name of something and so will require a definition to be produced. Unfortunately I’m
going to break that rule in this article (and probably every subsequent one) in order to improve readability so I’ll assume that people have a general idea what each capitalised term
means. -
Enterprise domains are nearly always split into business areas or sub-domains in order to make the business manageable. Each of these sub-domains will probably have a separate architect (who
may or may not be one of the enterprise architects) responsible for designing the systems in that area. -
It was Andrew Preston, Senior Enterprise Architect at a global media & market data company that shall remain nameless .
-
Many heavyweight economists, including Karl Marx (Capital) , John Maynard Keynes (The General Theory of Employment, Interest & Money), Adam Smith (The Wealth of Nations) and Max Weber (The
Protestant Ethic and the Spirit of Capitalism), have written extensively on this point much better than I ever could so I’ll leave it at this. -
I worried about making this statement because it is possible to conceive of being “absolutely certain” which, philosophically, in a multi-verse where all possible outcomes must
eventually occur then makes it possible to achieve. However, for the foreseeable future, I think it’s safe to say that the future is neither certain nor knowable in advance. -
There’s been a lot of wasted effort in producing sociology studies to prove something that should be obvious. People tend to like other people with similar traits and given the choice
will congregate with people we like, and people we don’t like get excluded from the group or ignored. Groupings within a company work the same way with the same inevitable consequences.
It’s one of the reasons why frequent change and re-organisations are seen as a good thing by company management.
