RedMonk’s Look at Compliance Oriented Architecture

I will start with an analogy.

A long time ago, before XML had been invented and when SGML was a new, radical idea, I often found myself having to explain how SGML was different from the kinds of typesetting codes and other markup that were already familiar to people in publishing. The reason that I was in this spot was that my business partners and I had created a product that produced SGML markup. But nobody, as yet, knew why they would want SGML, much less our product.

The analogy that seemed to work best had to do with cakes and recipes for cakes.  If I give you a cake, all you can do is eat it.  But if I also give you the recipe for the cake, well, then you can bake one for yourself, or
make a bigger one, or a sweeter one, and so on.  SGML was like having the recipe.

Well, it is a wonder that anyone knew what I was talking about. Maybe the pitch worked  because people liked cakes. I suspect that some of them got stuck on the image of eating a cake and then came away with warm feelings about our product. Anyway, what I was trying to get after was the value of abstracting rules. You can deal with the thing (the cake), but you have a lot more power and  flexibility if you deal with the rules for making the thing.  Control of product is great, but control of process is even better.

Which leads, of course, to compliance.

James McGovern sent me a trackback ping from one of his blog entries in which he references a paper by Stephen O’Grady of RedMonk titled “SOA Meets Compliance: Compliance Oriented Architecture.”  The paper came out last summer, but was new to me, and may be new to you.  It is a good read.

You should read the whole paper (it is free), but here is the argument in a nutshell:

• Many companies are taking a “project” approach to compliance requirements.  So, SOX compliance becomes another Y2K problem. And HIPAA (Health Insurance Portability and Accountability Act) compliance becomes an entirely different project–yet another Y2K.  At least with the real Y2K, there was only one of them …
• This is bad news, since, unlike Y2K, SOX or HIPAA are never “over.”
• This is also bad news because each compliance “project” tends to stand alone–separate resources, costs, and headaches.
• But, in fact, many of the same kinds of information and views of that information are required for the different compliance efforts.

So, the RedMonk paper proposes a “Compliance Oriented Architecture” or “COA,” — a specific instance of a services oriented architecture — so that companies can address different compliance requirements with a single investment in compliance services.

The proposal is another instance of the importance of focusing on the recipe, not the cake.  Rather than rushing off to the store to get all the ingredients for one cake, and then heading out a second time to buy more ingredients for a second cake, you realize instead that there are common ingredients.  With a little planning, you can maybe even bake both cakes at the same time.  (I’m hungry already …)

O’Grady describes the COA as emerging from a “radical–even heretical–notion.”  The heresy is the assumption that there are services that are common to the different regulations with which companies must comply.  The heart of the paper is a table in which O’Grady sketches out a starting list of such core services along with vendors and products that offer these services.

He may be a heretic, but I am sure that O’Grady is right about his core assumption.  Using the old arguments for SGML as an analogy again, the key here is to enable “reuse.”  Companies must move toward
architectures that can support many compliance applications with from a single system.  As with SGML, the key to value is in looking at the process, not the product.

So, it is a good paper.  But I have a misgiving about the focus on “compliance” in “Compliance Oriented Architecture.”  I can see where O’Grady is going … wanting to get companies to stop thinking of SOX, HIPAA, and other compliance requirements as separate projects — seeing them instead as instances of one, bigger thing.  But I wonder whether we shouldn’t perhaps go for something even larger … “Governance?” “Internal Control?”   My discomfort is with “compliance” as a primary objective.

Another analogy:  When driving a night, I “comply” with the 45 mile an hour speed limit on the five miles of narrow road leading  down the peninsula to my house because I want to have the car under control when a moose steps out in front of me.  (So far, I have been able to stop.) Compliance is a good idea, but it is a side effect.  The primary goal is to be able to stop the car in time.

It seems that some of the same thinking applies here, and so I am not sure about “Compliance Oriented.”  But that is a small detail that does not subtract from the real value of O’Grady’s paper.