What is the Abstraction Level of Reference Architecture

 Reference architectures are useful because they are a tool to break down the complexity of an enterprise architecture.

From Wikipedia: A reference architecture in the field of  enterprise architecture provides a template solution for an architecture for a particular domain. It also provides a common vocabulary with which to discuss implementations, often with the aim to stress commonality.

But what should be the level of abstraction of reference architectures?

Enterprise Architects often create reference architectures, from which solution architectures are derived.  The reference architecture is a foundation activity that allows EAs and others outside EA to collect and manage the information about enterprise architecture: current state and future state. Many EA teams populate the reference architecture with just definitions of the domains, capabilities and building blocks, place in a centrally accessible place.

The level of Reference Architecture abstraction should be high enough to serve its scope as for instance a business domain, industry or any industry. Reference architectures at various abstraction levels are part of a continuum. Ideally, the architect should be able to take the Reference Architecture, provide some details, and have a complaint, compatible solution architecture. This implies:
* The Reference Architecture is an Architecture, not a "how to ..." list.
* The Reference Architecture contains a reasonable level of detail specific to the Enterprise. Some details include organizational constraints and architectural decisions made at the Enterprise level. 

Reference Architecture design takes both the top-down and bottom-up approaching joining up in a consistent, coherent whole. Reference architectures, like all architectures (as opposed to designs) should be developed top-down -wise. On one side, Reference Architecture should start at the very highest levels of abstraction, be completely lacking in detail, be totally generic and very wide scope. Think big picture done very quickly - no detail. And then push down towards solution specifics - as driven by local needs; what are the burning issues in the solution design community? Where do they need framework and guidance? On the other side, the bottom-up approach is complimentary. Once in a while you might have to take an existing or proposed solution and extract from it, by abstraction and generalization, generic and abstract patterns to be included in your reference architecture. You should push as high up the abstraction chain as you can go - away from any specifics and details. This is a good way to identify the gaps in your high-level reference architectures. 

Creating a Reference Architecture is about front-loading the effort so that capability development is much more agile and timely. The right level of abstraction is that level when you can "very clearly" identify solution components in Reference Architecture, these solution components can be executed in tandem or in parallel. The checkpoint for its effects may include:

-Do you build a reference architecture for organizations to follow or build generic architecture for domains?

-How easy/difficult it is to translate an abstract/generic reference architecture into something which is implementable?

-How easy/difficult it is to translate an abstract/generic reference architecture into something which is implementable?

Reference architectures are useful because they are a tool to break down the complexity of an enterprise architecture. Each reference architecture can be broken down into domains and building blocks. Not all capabilities had building blocks and not all domains had capabilities but where you needed it you could go down into lower levels of detail. There might be some impression that EA reference architectures are only about IT! Of course, it is not, EA reference architectures show business process architectures & business capabilities, business value systems, etc. and the various IT architectures.

Reference Architectures can be created for many aspects of business and technology. The reference architecture is employed to create a customized architecture for your domain or enterprise. Some reference architectures include the human aspects in the design of the enterprise business entity. They show the distinction between
(1) the 'management and control' activities and technologies, and
(2) the 'product & service' activities and technologies; and show where to design the human aspects into each.

Typically the Reference The architecture provides a generic template that fits many specialized contexts. It usually does this by separating domains that are easier and better to analyze separately - for example, a Reference Architecture might focus on data or application layering. Or it separates information that is industry or geography-specific from information that is enterprise-specific. 

So the right level of abstraction of the reference architecture is situation driven: Don't be arbitrarily constrained to just three levels of abstraction - Physical, Logical, Conceptual. Each of those categories can have levels within it. Use as many abstraction/generalization levels as it takes. The main criteria to evaluate whether the next level should be created will include some tenets of EA objectives namely,
• Is there the need for a global (enterprise) perspective on the layer in question?
• Do you need to standardize any of the concepts within the layer?
• Can you institutionalize the maintenance of the details entailed in the reference layer to ensure their continuing value to the enterprise?

Still, the purpose of any type of Enterprise Architecture is to breakdown and optimize enterprise complexity, not to adding another layer of unnecessary complication, and Reference Architecture can be a navigation point to vary EA domains or business aspects.

Posted in: EA