Reference Architecture: A Practical Example

6 min readApr 23, 2020

Introduction

This article is the first in a two part series that examines a simple example of how the principles of reference architecture relate to a fictional business. We will focus on the reference architecture here, and then the solution architecture in a later post. The example used to illustrate is a staffing company, Demo Staff Company Inc., and we will detail how directions set at the executive management level map down into the technology stack. But first, let’s set some baselines.

Reference Architecture

Reference architecture is a discipline of enterprise architecture intended to provide a common vocabulary to express implementations. A common vocabulary can be further expressed as a repository of architecture artifacts that practitioners across a large enterprise can use to develop designs. An extension of the common vocabulary is the metamodel that articulates how artifacts are intended to interact through relationships. Both the architecture repository and content metamodel are parts of The Open Group Architecture Framework (TOGAF). TOGAF is a methodology and framework for efficiently delivering implementations of enterprise architecture. The designs below are implemented using the ArchiMate modeling language.

So why should you care about reference architecture? The benefit is, of course, a standards based approach to architecture with architects having unified messaging among peers. Your business gains velocity and efficiency if there is a common language. There will simply be less time spent trying to convey complex ideas than if every architect, developer, scientist, or engineer had their own dialect when collaborating on projects. Perhaps even more importantly is having unified messaging from architects to business leaders. Enterprise architects can connect business goals and objectives to implementations down the technology stack in ways that are clear, concise, and above all else, consistent.

The rest of this article will examine the motivation, strategy, business, and data and application layers of a fictional business, Demo Staffing Company Inc., to illustrate the concepts broached above.

Motivation Layer

For the purposes of this exercise we will walk through our design from the motivation layer through to the data and application layers. The motivation layer provides the reasons, or motivations, for particular courses of action in a business. This example shows drivers, a goal, expected outcomes, and requirements. Demo Staffing Company Inc. has four (4) drivers at the very top level:

Deliver client satisfaction
Deliver candidate satisfaction
Deliver employee satisfaction
Deliver client, candidate, and employee satisfaction in a cost-effective way

Demo Staffing Company Inc.’s business model is based on providing talented candidates to large corporate clients. Clients would approach the company with their needs and the company would leverage its network to match those needs with candidates. For its business to grow, the company must deliver utmost satisfaction to its clients to solidify its brand in a highly competitive industry. The second driver speaks to the candidate experience in the placement process. The company must delight candidates by ensuring that they are placed in roles that are best suited to their talents and interests. The third and fourth drivers speak to the company’s internal goals. Employee satisfaction is paramount, and so is driving costs down to satisfy stakeholders such as investors.

The four (4) drivers above neatly tie into the stated goal of delighting both clients and candidates with an optimal staffing experience.

Now that we have defined drivers and goals, there must be some prescribed way of understanding if and when the company has achieved them. This is what outcomes are for, and we can see where the company has an outcome for each of its four (4) drivers. Notice that outcomes are measurable and time-bound:

Client satisfaction must improve by 10% in one year
Candidate satisfaction must improve by 10% in one year
Employee satisfaction must improve by 10% in one year
Operating costs must be reduced by 5% in one year

Outcomes provide the baseline for the final element shown in this example, requirements. Requirements explicitly define what needs to be done to realize an outcome. That realization relationship is explicitly shown in the connection between the requirement and outcome above it. Notice as well that the requirement relating to placing candidates helps to realize two (2) outcomes. It affects both client and candidate satisfaction. Requirements for internal outcomes speak to enabling self-service tools for employees, and pushing into the public cloud as an approach to reducing operating costs.

Strategy Layer

The strategy layer shows the courses of action the business must take to realize the requirements of the motivation layer. For example, there are three (3) courses of action shown above, namely leveraging artificial intelligence (AI), leveraging automation, and driving cloud adoption. These have one-to-one relationships with the three (3) requirements in the motivation layer. There are business capabilities that help to realize the courses of action. Notice that there are only two (2) business capabilities mapped to three (3) courses of action. There is a one-to-one mapping between matching candidates using machine learning and action of leveraging AI, but the DevOps-driven development capability supports both the process automation and cloud adoption courses of action. The message in the latter scenario is that DevOps can drive automation in the cloud.

Both the machine learning and DevOps business capabilities will be owned by the Information Technology (IT) organization.

Business Layer

The business layer is associated with the resources in the strategy layer above it. That is, the business process of machine learning and data analytics, infrastructure management, information security, and software development are all associated with the IT organization resource in the strategy layer. The business processes are in turn associated with one-to-one relationships with the business roles that perform them.

Before examining the final layer in this design, perhaps now is a good time to quickly recap the journey so far.

As of now, the complete stack is that the company has explicit drivers that map to an encompassing goal of delighting clients and candidates. The goal will be reached when we have achieved four (4) measurable and time-boxed outcomes. To realize the outcomes we need to meet three (3) requirements. Requirements in turn are realized by applying a strategy comprising three (3) courses of action performed by the capabilities assigned to the IT organization. The IT organization resource has four (4) business processes performed by four (4) roles that are related to the business capabilities above it in the strategy layer.

Data and Application Layer

The data and application layer offers services to the business layer above it. The services have, in this case, a one-to-one serving relationship to the matching business processes. Services are comprised of either application collaborations, for example, automatically matching candidates to client roles, or functions. Examples of the latter are install and deploy infrastructure, or respond to security incidents. Application collaborations are made up of components. The aforementioned automatically matching collaboration is comprised of a component that analyses job role data, and another that predicts the optimal job role match. These two specific components also have an accessing relationship with two (2) data objects that store job roles that need to be staffed, and candidates to be placed respectively.

Note that this design does not feature a technology layer. This will be included in the solution architecture. The focus for the reference architecture is in the motivation and strategy layers, with some treatment of the business and data and application layers.

Putting It All Together

Now that we have examined all the constituent parts of each layer in the reference architecture, we can present the final product that shows the relationships that exist between the layers themselves.