The Value of Reference Architectures
Apr 28, 2014
In my previous blog post I wrote about value-driven enterprise architecture and its relations to different disciplines within the enterprise. In this blog, I want to focus on the added value of using reference architectures.
Reference architectures are standardized architectures that provide a frame of reference for a particular domain, sector or field of interest. Reference models or architectures provide a common vocabulary, reusable designs and industry best practices. They are not solution architectures, i.e. they are not implemented directly. Rather, they are used as a constraint for more concrete architectures. Typically, a reference architecture includes common architecture principles, patterns, building blocks and standards.
Many domains have defined their own reference architectures. Well-known examples include:
Most of these architectures include the common business functions/capabilities and business processes in a domain. Next to that, they may include for example common data models, communication standards and exchange formats, and sometimes even common software building blocks and other reusable assets.
Why use reference architectures?
So what is the value of using such reference architectures, and why and when should you employ them?
First of all, reference architectures provide a frame of reference that help you to get an overview of a particular domain and they provide a starting point for your own enterprise architecture effort. They provide you with basic structures so you do not have to reinvent the wheel (which often turns out to be square anyway). Reference architectures are most valuable for those aspects and elements of your organization on which you do not compete with others.
For example, the business functions of a typical insurance company are largely similar to those of its competitors, as are many of its business processes. Competitive differences will most likely be in its products, pricing, customer segments, and customer relationships. Reusing industry best practices provided by reference architectures ensures that you are not behind the curve on these non-competitive aspects. We also see this in the implementation of many IT systems, where vendors such as SAP provide reference processes for large parts of an organization. Your accounting process, for example, is seldom a competitive advantage.
A second reason for using reference architectures is interoperability. In our increasingly networked world, organizations need to connect and cooperate with all manner of other parties. The standards and building blocks provided by reference architectures facilitate these connections. A related benefit is that using standards improves flexibility, because it is easier to exchange building blocks that connect via standardized interfaces; vice versa, it is much easier to develop standards if the building blocks themselves are standardized. LEGO is a perfect example, as my colleague Bas van Gils described in his blog recently.
This then brings us to a third reason for using reference architectures: mergers & acquisitions and outsourcing. If two parties speak the same language, use the same standards, and recognize the same boundaries between functions, processes and/or systems, it will be much easier to recombine their elements in new ways.
A fourth reason for using reference architectures is to facilitate benchmarking within your industry. Often, the differences between companies are not in the design of e.g. their business processes, but in their execution. Using reference designs makes it much easier to compare those execution results.
Benchmarking leads us to a fifth reason why reference architectures are important: regulatory compliance. Often, reference architectures are prescribed (or at least strongly recommended) by regulators. Accounting principles, practices and processes, for example, are increasingly standardized and mandated. This leads to business reporting standards, even down to the level of exchange standards such as XBRL.
Before you decide to use a reference architecture, some conditions should be fulfilled. First of all, a reference architecture should be community-based. Users, not vendors, should decide on best practices, and the architecture should be actively maintained by the user community. The world is changing, and so too should your reference architectures.
Such an active and open community process is ideally complemented by the use of open standards in describing the architectures. BiZZdesign provides many such reference architecture models out-of-the box.
The use of a reference architecture in an organization also requires governance: the organization should really commit to its use and this should be ‘enforced’ in some way. Reference architectures are only of value if people are really using them as intended and actually follow their guidance, otherwise the whole idea of reusing industry best practices breaks down.
Finally, your reference architecture of choice should provide true, actionable guidance. General architecture principles are not enough. Actual structure, for example in terms of business functions or processes, building blocks and standards, is needed to provide you with a useful backbone for your own architecture efforts.
Using reference architectures does not imply that you lose all your design freedom. Rather, you focus that freedom on those aspects of your enterprise where you make a real difference. That is where you as an architect can add the most value!
