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.
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.
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 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.
Page 1 of 3