Providing a Clear Point of Reference

Is reference architecture an ivory tower activity with little relevance to software development projects? Or, is it rather like a compass that keeps projects on track and pointing toward their destination?

To answer these questions, you’ll first ground yourself with an industry accepted definition of reference architecture and understand how reference architecture builds upon architecture standards. Then, you’ll review the types of reference architecture artifacts used by different project stakeholders. Finally, you’ll observe how reference architecture is closely related to knowledge management and outline a repeatable process for capturing and leveraging organizational knowledge through reference architecture.

Through this overview, you’ll find that reference architecture provides a clear point of reference for projects and that it helps them improve quality, accelerate delivery, and lower the total cost of ownership of the IT assets being developed over time.

Reference Architecture Defined

You should begin with an industry accepted definition of reference architecture. The Rational Unified Process defines reference architecture as a pre-defined architecture pattern, proven for use in a particular business context, together with supporting artifacts to enable its use. Often, these artifacts are harvested from previous projects. A closer examination of this definition is helpful.

Pre-defined architecture pattern

A reference architecture captures a solution architecture that solves a particular recurring problem. It is “pre-defined” so that it can be used again the next time a project encounters a similar problem. The solution patterns that may be captured in a reference architecture includes the architecture patterns to build:

• An n-tier transactional application for thousands of concurrent users
• A business intelligence application for a large data warehouse
• A business-to-business transaction gateway that exposes services to external partners
• A web content management system that allows business users to publish content to a business-to-consumer portal

Proven for use in a particular business context

A reference architecture is not just “a” solution. It is a solution thatch has been “proven for use” to solve a particular business problem. It is important to remember that architecture patterns are not invented, but rather recognized.

Together with supporting artifacts to enable its use

For a reference architecture to be leveraged, artifacts that explain what it is, when to use it, and how to use it are essential. These artifacts must be tailored to the needs of the consumers of the reference architecture that include architects, developers, and project managers.

Often, these artifacts are harvested from previous projects

Because a reference architecture is proven for use before being promoted, it is often harvested from a previous project’s success.

Reference Architecture and Standards

In my previous article on architecture standards, titled “Maturity through Standards,” I discussed the benefits of architecture standards that define the products, patterns, or practices to be used in developing or acquiring software in an organization. You may be wondering, “what is the difference between architecture standards and reference architecture?”

Whereas standards identify enterprise “building blocks,” including vendor and open source products, reference architecture explains how the “building blocks” are constructed to solve a particular business problem. For example, the reference architecture for publishing content to a consumer portal would show how the organization’s standard content management product, portal framework, and security standards would be used to solve this set of functional and non-functional business requirements.

Reference Architecture Artifacts

A reference architecture may have several artifacts to document what it is, when to use it, and how to use it. These artifacts include the Reference Guide, Reference Models, Reference Implementations, Factory Setup Guide, and Project Planning Aids. You will examine each type of artifact, its purpose, and audience.

Reference Guide

A reference guide provides an overview of a problem space and a guide to proven solutions. The problem is described by a particular set of functional and non-functional requirements. The solutions may be described by a conceptual diagram of how to architect a solution to meet those requirements. The solution also might leverage a set of organizational architecture standards. The reference guide may contain a set of solutions and the criteria to choose among them. The primary user of a reference guide is an architect. A reference guide is not the only artifact used to describe a reference architecture. However, it is probably the most important because it broadly defines the problem and proven solutions.

Reference Models

Whereas the reference guide will tell you “what to build” given a set of requirements, reference models describe “how to build” the solution. A reference guide may provide context for multiple reference models.

In a previous article, titled “Achieving 20/20 Vision with Architecture Viewpoints,” I described seven architecture viewpoints that may be used to articulate a solution. A reference model may use a number of viewpoints such as use cases, domain models, conceptual diagrams, sequence diagrams, or deployment diagrams to describe the solution. A reference model is a design asset that may be used on subsequent projects by architects and developers.

Reference Implementations

Reference models are much more valuable if they document proven reference implementations. Reference implementations are actual working code examples of the solution. A reference implementation provides code assets that developers may leverage on subsequent projects.

Factory Setup Guide

People, processes, tools, and environments are needed to implement a solution. The factory setup guide artifact describes what is needed to develop and deliver a solution using the reference architecture. The factory setup describes the development, testing, staging, and production environments; how code is migrated through environments, the roles and responsibilities of development and support personnel; and so on. The primary users of the factory setup guide are the project manager and architect.

Project Planning Aids

Project planning aids are a key reference architecture artifact because they assist project managers with successfully utilizing a reference architecture. Planning aids might include project templates, resource allocation guides, estimating templates, staff training recommendations, and so forth.

Reference Architecture Artifacts

Table 1 summarizes the reference architecture artifacts discussed above:

Table 1: Reference Architecture Artifacts

Collectively, these artifacts create a meta model for documenting a reference architecture.

Artifacts by Problem Domain

A set of reference architecture artifacts may be used to document the reference architecture of a particular problem domain; for example, a n-tier transactional application architecture. Note that a domain’s reference architecture need not include all of the artifacts mentioned here. A reference guide is generally the best place to begin. Over time, additional artifacts such as reference models, reference implementations, factory setup guides, and project planning aids can be used to mature the reference architecture. By using a common meta model, all relevant domains can be documented in a consistent manner.

Reference Architecture and Knowledge Management

The field of knowledge management provides tremendous insight into reference architecture.

Knowledge management is the explicit and systematic management of vital knowledge and its associated processes of creation, organization, diffusion, use, and exploitation. As you did with the definition of reference architecture, you can examine this definition in further detail.

Explicit

Knowledge management encompasses both tacit knowledge (in people’s heads) and explicit knowledge (codified and expressed in databases, documents, and the like.). By making knowledge explicit, it can be broadly communicated and leveraged. This is exactly what reference architecture does when it articulates proven solutions to common problems by using the artifacts described above.

One of my colleagues coined the phrase “living architecture” to describe the reliance upon the experience and judgment of certain key architects. Living architecture is not sustainable. By codifying the knowledge of these individuals and making it explicit, a reference architecture can leverage their knowledge more broadly.

Systematic

Leaving things to chance won’t achieve the benefits of knowledge management. There must be a process to create, organize, communicate, use, and exploit knowledge. The same applies to reference architecture. A reference architecture shouldn’t be a one-time activity. There needs to be a process to create, store, communicate, use, govern, and refine reference architecture artifacts.

Vital Knowledge

Certain knowledge is essential to an organization’s mission. Knowledge management focuses on capturing this vital knowledge. In a similar way, a reference architecture focuses on the common solutions that are leveraged on the greatest number of projects. There should be a justifiable benefit to capturing a reference architecture for a given problem domain.

From the parallels, you can see that reference architecture is really a type of knowledge management. It makes vital architecture knowledge explicit, and requires a systematic process to build and leverage this knowledge.

Reference Architecture Lifecycle

I call the systematic process to build and leverage vital architecture knowledge the reference architecture lifecycle. This lifecycle occurs in three phases: reference architecture creation, project initiation, and project delivery.

Phase 1: Reference Architecture Creation

The process of reference architecture creation begins with identifying problem domains that need well-articulated solutions. There should be key projects dependent upon this work.

The first place to look for reference architecture assets are from existing projects that have successfully delivered IT assets within a problem domain. When new technology is introduced into a domain, existing assets may not exist. The initial reference architecture may be developed from industry models. However, imposing externally developed reference architectures on an organization may not work. Ideally, a reference architecture should be customized to suit a particular organization’s culture, mission, existing assets, skill sets, principles, standards, vendor relationships, and other factors.

A determination of what reference architecture assets are needed should be made and chosen from the set of artifacts described in the reference architecture meta model. When these assets are created, they need to be validated and stored in a reference architecture repository. There should be a taxonomy for organizing the reference architecture artifacts of the relevant architecture domains.

Phase 2: Project Initiation

The project initiation phase assumes that reference architectures have been created and a general knowledge of them has been communicated. When a project is initiated, the appropriate domain reference guides are consulted to determine the solutions appropriate to the project. The reference models to be used are identified. One of the benefits of reference architecture is a more robust solution delivered in a shorter timeframe. The knowledge stored in the reference architecture is leveraged. It is important that there be a governance mechanism to ensure that project architectures are in accordance with and leverage the relevant reference architectures.

Phase 3: Project Delivery

Once the reference guide has been consulted, reference models chosen, and the candidate architecture is approved, a project moves into the delivery phase. At this point, several reference architecture artifacts are leveraged to accelerate delivery. The project planning aids assist the project manager in identifying all the roles and responsibilities needed and in estimating the work to be done. The factory setup guide defines the environments that will be needed throughout the software development lifecycle. Reference implementations assist in the development of code.

Repeat

At the conclusion of a project, new IT assets are developed and there are new learnings to be leveraged. This work is harvested to update the reference architecture and the reference architecture lifecycle repeats itself.

Summary

In this article, you reviewed an industry-accepted definition of reference architecture. You expounded upon this definition, and reviewed the types of reference architecture artifacts used by project stakeholders. These artifacts included reference guides, reference models, reference implementations, factory setup guides, and planning aids.

You learned how reference architecture is a type of knowledge management activity. Through reference architecture, vital knowledge is captured and leveraged. Like knowledge management, reference architecture requires a systematic process. You reviewed the reference architecture lifecycle and a repeatable process for creating reference architecture artifacts that are leveraged in project initiation and delivery.

Through your overview of reference architecture, you’ve learned that it is not an ivory tower activity, but it is essential to delivering quality IT assets (better), more quickly (faster), and with a lower total cost of ownership (cheaper).

Has your organization identified the architecture domains vital to its mission? Are these domains documented through reference architecture? Is there a standard set of reference architecture artifacts designed for project stakeholders? Is there a systematic process for managing the reference architecture lifecycle? If not, consider starting or maturing the reference architecture practice in your organization. The rest is up to you!

References

• Reference Architecture: The Best of Best Practices, Paul Reed, September 15, 2002
• Knowledge Management – The Basics, Dr. David J. Skyrme, 1999

About the Author

Jeff Ryan is an enterprise architect with over twenty years experience architecting and implementing thoughtful solutions to business problems. Jeff led a reference architecture team in a large organization using the concepts described in this article. He has published over twenty articles on enterprise architecture, SOA, XML, XSLT, Java, and other subjects.