Enterprise Architecture

If you look up "Architecture Framework" on Wikipedia you will find that it is a "layered" approach to Enterprise Architecture. Referencing an American document, Wikipedia explains:

Contemporary federal guidance suggests thinking about “layers” of the enterprise architecture:^[9]

• Business processes and activities
• Applications such as custom or off-the-shelf software tools
• Data that must be collected, organized, safeguarded, and distributed
• Technology such as computer systems and telephone networks

I can however tell you from personal experience that whilst you can do enterprise architecture within such a framework, the results are neither pretty nor particularly illuminating (though I have to say that the sheer size and complexity of the resulting architecture can be pretty impressive); which is a pity because architecture done properly can be not only impressive to look at but also tremendously valuable.

The problem is that the layers (not to mention possible domains and sub-domains) are fuzzy, ill-defined and certainly not orthogonal, i.e. they are not mutually exclusive (suppose you are downloading an application... is it not also data?)

The impossible-to-overstate issue with this is that different modellers, constrained perhaps by the capabilities of different toolsets or pre-existing organisational perceptions, can — indeed usually will — model the same thing in completely different ways.

Such inconsistencies make it much more difficult, time-consuming and expensive to exploit models from diverse sources by combining them into a larger whole, and make interpretation by outsiders.

I discovered some of the problems when I began doing architectures for UK MoD (using ISSE). Try as I might I couldn't see how to divine the correct model element and layer. Certainly there were established practices and reasonable reasons for doing things in a certain way, but there were equally good reasons for doing things differently, nor could I see how the seemingly inevitable ambiguities could be resolved so that all the pieces would ultimately fit together and add significant "value".

When it became apparent that there was a genuine problem in the approach, rather than merely a problem with understanding and implementing a sound approach, there was at last a reason for throwing away the old "Reference Architecture" levels and doing things differently.

As the (habitual) iconoclast I had to persuade, nay demonstrate, to the senior and far more experienced members of that little team (Gary Davies in particular) that there was a better way. Eventually however there was a collective sigh of relief and things rapidly improved: we were soon able to create larger, more sophisticated and more meaningful models that could be quickly and easily joined up to make very large and complex architectures.

However, at some point UK MoD decided to create its own Architecture Framework (MoDAF), which was heavily influenced by the US DoD's architecture framework, DoDAF.

At that time, MoDAF, DoDAF and indeed every other formal system I looked at, whilst a great improvement upon their predecessors continued to suffer from the same general lack of orthogonality in classification as the layered approach. However, the interest in ontology (basically the science of classifying things) has steadily increased since then, and to judge by a cursory examination of some of the work of the IDEAS (International Defence Architectures Specification) Group, sense and logic is slowly prevailing; IDEAS Group thinking has significantly influenced DoDAF V2.

It is, I think, all heading in the right direction at last: arbitrary distinctions between "functions" and "services", "specifications" and "rules", etc. are slowly being transformed into nuanced yet logical and meaningful distinctions.

However, having just dipped into the latest MoDAF specification I can still find plenty of room for improvement — but don't the deficiencies of current approaches deter you from making use of architectures: executed with care they can be very, very useful... but don't ignore the caveats either.

Further Reading/Browsing

DoDAF Information (including manuals in PDF) is available at the DoD website here; or at Wikipedia here.
MoDAF At the UK MoD here;or at Wikipedia here.
IDEAS Group here.