Gilbane Group Blog

A "compliance architecture" is an organized expression of the compliance concerns and objectives for a particular organization.  Think of it as a hierarchy of objectives, roles, requirements, and procedures that defines what an organization will do in its effort to govern its activities, manage risk, comply with regulations, and grow.

Compliance architectures are typically developed through application of a compliance and governance "framework."  There are a number of frameworks that can be fit together in different ways to address different areas of concern.  There is, for example, the COSO Internal Controls Framework, developed in the early 1990s, that focuses on controls related to operations and financial reporting.  More recently, COSO has also created an "Enterprise Risk Management" framework that, as the name implies, provides guidance for a broader view of compliance and controls.  For IT governance, there is the COBIT framework.  Moving the other direction, toward a broader view of concerns including ethics, there is the OCEG framework.  These different frameworks are not competing pictures of the world.  Instead, they allow you to focus in close or move back more broadly, like twisting the zoom lens on a camera, and allow you to focus on different governance problems.

Technology architectures, on the other hand, are particular ways of connecting the different repositories of information within an organization and the different systems available for retrieving, processing, analyzing, and presenting the information in those repositories.  Viewpoint and focus matter here, too.  Depending on what part of the problem a technology vendor is addressing, the technology architecture that the vendor describes will cover more or less of the problem, in more or less detail.  An organization's overall technology architecture should reflect the concerns and priorties in the compliance architecture.

One particular technology architecture that I have written about in the past is the "Compliance Oriented Architecture" -- a  services oriented approach to compliance suggested by RedMonk.  As I said in my earlier post, I think that the RedMonk work is important--but it also is a nice illustration of how confusing the nomenclature can be.

I don't think that newcomers are the only victims here.  At the conference I have listened to presentations by people who--if asked--would certainly understand the distinction that I am trying to make here between the compliance architecture (objectives, roles, priorities, procedures) and the technology architecture.  But as these speakers move between the two ideas, and blend them together, they end up obscuring an important requirement for success. 

Here is that requirement:  you need to begin with the compliance architecture.  It is the architecture that helps the organization understand what must be done.  Only then can you evaluate the technology architecture, which provides a part of the means to achieve that "what."

In real life, of course, the development of the two architectures is not strictly sequential.  Compliance and governance requirements change as an organization grows, as rules change, as the organization learns more.  The architectures evolve and adapt. The key is to remember, as the organization makes these changes, that you need to think carefully about the "what" before making decisions about "how." 

Thinking of each the two meanings of "architecture" as distinct, involving different frameworks and different contributors within the organization, will help keep "what" separate from "how."