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
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. |
IE 7
Firefox 2.0
