The Essential EA Toolkit Part 2 - A Reference Architecture and Standards Repository

The Essential EA Toolkit is a four-part blog on some recommended “tools” for Enterprise Architecture Teams. By “tools” I mean a few well-executed deliverables or processes that contribute enormous value to an organization. These are not technology focused, requiring only standard office productivity software and perhaps a collaboration application such as SharePoint.

The Essential EA Toolkit (Part 1) identified the following four items:

• A Business Capability Model 
• A Standards Repository based on a Reference Architecture 
• An Architecture Governance Process
• A Strategic Blue Print and an Enterprise Roadmap 

This post examines the second, which is actually two items that work together - a Reference Architecture and a Standards Repository. These tools facilitate both delivery of architecture and governance against it – both common functions of an EA Team.

 A Reference Architecture

 A Reference Architecture is an anchor for other architecture deliverables; the Business Capability model discussed in Part 1 is an example. If you read that post you already have a feel for what one can do.

To be more precise –

A Reference Architecture is one or more abstract models describing, organizing and showing the desired relationships between the capabilities of an organization from business, information systems and technical view points.

Physically, a Reference Architecture is a combination of models in the various Architecture Domains combined in such a way that they are all consistent, reflect organizational attitudes and are easily understood by the appropriate audiences.

The reference models create a common understanding of what an enterprise “can do” in terms of business, data, applications and technology; allowing EAs to connect the dots. This is not a new concept, there is a lot of reference architecture information available; the Common Reference Architecture or CORA model is one of my favorites:

The model provides a way to conceptualize and anchor on the components of an architecture so that “everyone sings off the same sheet of music”. Note that there are a limitless number of ways to model a Reference Architecture. Each model must be suited to a purpose.

The CORA model is really useful as a reference for creating Information System views of architecture; by that I mean descriptions that focus on high level data and application integration capabilities. The “top” of the model is light on business items (the Business Capability Model discussed in Part 1 is better suited for anchoring business architecture, for example) and the “bottom” is light on technology infrastructure (servers, storage, networking, etc.).

As an alternative to CORA, The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight from IBM provides an “information services” based Reference Architecture that focuses on describing architectures as composed of information services.

Reference Architectures are useful in two ways. First, and most obviously, its elements serve as a basis for other architecture deliverables. For example, one can create an Integration view of a solution architecture that includes specifics on how data flows between components via messaging protocols. The components in this application architecture model are lifted directly from or refer back to a Reference Architecture model. Using the same model, the Technology Architecture team can create an architecture describing how messaging services are implemented through various technology components. Since both use the same Reference Architecture, the application and infrastructure architects have a common basis for understanding the design.

Finally, Reference Architectures are a great way to identify and classify standards.

Standards and a Repository for Them

 Architecture Standards are necessary in order for decision makers to assess a potential investment or technology alternatives and make the right call. A Standards Repository stores the Standards such that they are organized logically and available for governance.

The term standard in many organizations is used ambiguously leading to churn. For example, I’ve been in meetings where the words, “that’s not our standard for ______” have been used as an argument against a solution’s approach. When questioned further, the objecting architect was only able to identify the standard based on the recollection of a PowerPoint – yet nobody seems to be able to produce the deck or any documentation that the deck was approved as the standard. Another common issue with standards is they tend to be “tribal knowledge”…the statement, “everybody knows that’s not our standard” is another rationale that I’ve heard in frequently.

My recommendation is to precisely define what a Standard is and what types your organization needs; then write them down and put them in a repository for all to access. Lastly, govern to these and only these. 


While this is easy for me to say, it is a lot of work. Furthermore it removes power from architects since they must commit to what they will and will not govern against – in other words, I recommend adopting the position that if it’s not documented, it’s not a standard.

In order to be effective therefore, standards must be:

• Typed – that is various levels of standards must be established according to types. Some common ones are technology product standards, architecture and design patterns, strategies and principals. Each of these can serve as a basis for comparison of a proposed solution or alternative, enabling better decision making at various levels.
• Classified – Due to the variety and complexity of technologies available, an organization of any size is likely to have quite a few standards. A classification scheme is necessary to enable users to narrow searches; a Reference Architecture is a natural for this purpose. For example, with the CORA model, a set of principles can be written for the entire application integration stack. Strategies can be defined for each major block (Channel Access, Presentation, Composition, Integration, etc.) while Technology/Product Standards (WAS, IIS, JMS, MQ, Sharepoint, IE, etc.) and patterns can be created for each sub-block. 
• Stored in a repository - this is the last and most vital step. Regardless of how well typed and classified standards are, if they are not stored in a single, known location, they are much less useful. It would be like the legislature passing laws documented on napkins stuffed in their coat pockets. While many organizations use an EA tool such as System Architect to document and publish standards, this is not necessary for many organizations. We use Sharepoint and it works just fine.

In Part 3, I will discuss the third “tool” – an Architecture Governance Process, which is the essential set of activities that enable effective architecture decision making using the tools we have discussed so far.