Architectures and Architectures

In the course of two days of sessions here at the Gilbane Conference it is
clear that, when it comes to compliance, we’ve overloaded the word
"architecture." We have had a fair amount of talk in some of the
conference sessions about "compliance architectures." We have also
seen different technology architectures used to support compliance systems.

It is easy to understand why at least some of the people in the audience
could get all of this confused.  Sometimes it seems that even the speakers
have the two "architectures" confused and wrapped around each
other.  The bad result that comes from this goes beyond a few confusing
conversations.  If there is enough confusion, the consequence is a
misdirected approach to addressing compliance issues in individual
organizations.

So… I’ll take a crack at getting the terms and ideas unwound from each
other.  Think of these as "first cut" definitions–aimed at
helping people who are just now coming to terms with compliance lingo to
understand what is going on.  If you can help out here–improving the
definitions–please add some comments.

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."