EA Voices

After an almost two-year hiatus from blogging here, I have decided to return to blogging and an internet presence devoted to enterprise & data architecture, with a good dose of project managment thrown in. As part of that process, I…

It has been noted many times that there are only two industries that refer to their customers as “users”: IT and illegal drugs. When you think about it – at some point both of them need a fix! (ba-dum-bump) Thank you! I’ll be he…

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.

What are 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:

• the BIAN service landscape for the banking industry;

• the ACORD Framework for the insurance industry;

• the eTOM business process framework for the telecommunications industry from the TMforum;

• various government reference architectures, for example the Dutch NORA and her ‘daughters’, the US FEAF or the Australian AGA;

• the defense architecture frameworks such as NAF, DODAF and MoDAF;

• reference architectures for manufacturing and supply chains such as ISA-95 and SCOR.

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.

eTOM framework in ArchiMate

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 helps 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 evermore standardized and mandated. This leads to business reporting standards, even down to the level of exchange standards such as XBRL.

Another example is given by the Wijffels committee on the structure of Dutch banks, installed by the Ministry of Finance and the Dutch National Bank at the request of the Dutch Parliament. They have published a report which explicitly recommends banks to use industry standards such as BIAN. The context of this report is the need for decommissioning and breaking up banks in case of financial disaster (the so-called ‘living wills’). Structuring a bank along the lines of a reference architecture such as BIAN’s may certainly help in such a case. These issues are also addressed by the Dodd-Frank Act in the US and the new ECB Resolution Mechanism in the EU, so we may expect similar guidance from those sources.

How to use reference architectures?

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 changes, and so should your reference architectures.

Such an active and open community process is ideally complemented by the use of open standards in describing the architectures. For example, the descriptions of the Dutch government reference architectures are largely based on the ArchiMate standard. BiZZdesign can provide 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!