Author: Bill Zoellick (Page 3 of 5)

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.

James McGovern, writing in his February 18th  IT
toolbox blog, asks for more analyst engagement and coverage regarding open
source options for users.  He suggests …

Maybe the next step is to get several analysts who blog to expose themselves to a vocal audience. Maybe they could ping this entry’s trackback and let the dialog begin. Online audiences routinely discuss, debate and refute industry analyst research.

I think that would be great.  Sign me up … I would be happy to
contribute.  But, what what would be even more useful, for me — certainly
more useful than discussions of industry analyst research — would be hearing
more about what open source platforms and tools are turning out to be most
valuable as companies implement compliance solutions.

In my own work as an analyst/writer over the last decade I have discovered
some things that match up–at least in a rough way–with McGovern’s
concerns.  I started out sizing markets, projecting growth, figuring up
market share, and so on.  I learned a couple of things after a few years of
this.  One is that it is hard to predict the future.  A second thing
was that the methodologies available for estimating current market size and
market share in markets that are relatively young and still emerging are subject
to a lot of error.  You can do it for toothpaste or cola, but there is a
lot of guesswork and making of assumptions when you are looking at something
like "content management" or, heaven forbid,
"compliance." 

But perhaps the most striking, humbling thing that I learned is that the
market sizes, growth projections, and so on that I worked so hard to create are
typically not useful to the people and firms that actually USE technology. 
It is critically important stuff for technology vendors … but
technology users are more concerned about what works than they are with
the size of the market. 

So, I don’t do market size estimates anymore.  I am much more interested
in finding out what people are doing and what works.

As I look at Sarbanes Oxley and other compliance issues, the question of
"what works?" seems more important than ever.

So, James, I really like the idea of using trackbacks and other tools to get
a discussion going that brings more open source tools to the forefront. 
But, rather than worrying about what the analysts think, I would be more
interested in finding out more about what companies are using, for what
applications, and what is working. 

I see that James
Governor of RedMonk is also interested in joining the conversation.  (I
will say a bit more about RedMonk’s interesting thinking about "Compliance
Oriented Architecture" in a separate post.)  With James on board,
along with some people who are using open source approaches to compliance, I
think we could have a conversation that would be both interesting and really
useful.

Yesterday I wrote about the new AeA
report on the problems companies are encountering with Sabanes-Oxley Section
404. Another concern raised in the report has to do with innovation and IT
spending.  Quoting from the report …

Instead of taking a principles-based approach, COSO and COBIT provide a super-checklist for all companies, set a cookie-cutter approach for how one must run a business, and they create a limitless necessity to document, document, document, rather than to do, do, do.

The external auditing firms also come in for criticism in the AeA report for
using "cookie-cutter" approaches.  One CFO quoted in the report
complains about armies of auditors in their mid-twenties who know nothing about
business and whose "judgment" is confined to whether or not they can
check off a box on some list.

The fact that Big Four firms are reporting a doubling of auditing revenues,
thanks to Sarbanes-Oxley, invites a cynical view of their situation.  But,
a "big picture" take on the issue needs to consider the risks and
incentives on the auditing side of the problem.  If something does go
wrong, auditors know that shareholders will be coming after them for
damages.  It is hard to see the upside for the auditor in being
"reasonable" and in trying to consider the special circumstances of
smaller companies.  (I am not arguing that the inability to deal with the
special needs of smaller firms is "right" — but simply that the
auditors, too, are constrained by the business and litigious realities
surrounding SOX.)

So … what are the consequences of this "cookie-cutter"
approach?  According to the AeA Report:

A specific example of the damage that this does relates to new IT productivity projects. The only way that U.S. companies successfully can compete with companies based in low-cost countries is to be more efficient. The key to greater efficiency is to invest in new and improved IT and automated systems. Because COSO requires an internal control to be ‘mature’ to be considered effective, it is not practical to implement major new IT systems in the third and fourth fiscal quarters because the control will not be mature.

Ouch!  Is this really happening?  Are readers finding that SOX
Section 404 is turning into a moratorium on IT systems implementation for half
the year?  Send me an email or add a
comment …

Last week, AeA, the high-tech trade association, released a report titled
"Sarbanes-Oxley Section 404: The ‘Section’ of Unintended Consequences and its Impact on Small
Business."  Most readers will find that this paper is worth a
look.  The paper argues that:

• Section 404 is more expensive than anyone anticipated — so much so that
  the costs far outweigh any possible benefits.
• The Section 404 compliance burden is disproportionately large for smaller
  companies.
• External auditors are taking a "one size fits all" approach to
  assessing the effectiveness of internal controls.

AeA’ assertions about the impact on small and mid-sized companies are really
striking.  For example …

What became clear during our companies’ discussions on Section 404 is that the cost burden for smaller companies as a percentage of revenue is far greater than for large companies. For multibillion dollar companies, the cost may run at approximately 0.05 percent of revenue, but
for small companies with revenues below $20 million, the costs can rapidly approach three percent of revenue.

This is a striking number.  I have no idea how precisely accurate these
results are — but the general thrust of the argument seems plausible: Smaller
companies typically start with less in the way of sophisticated internal control
systems, and the costs of creating such systems must come out of a
proportionately smaller pool of revenue.

Does this report match up with experiences that any of you are having? Send email
or post a comment …

Last night William Donaldson, chairman of the Securities and Exchange
Commission, said that he would work to reduce the cost of Sarbanes-Oxley
compliance.  His remarks are reported in today’s Financial Times.

Not surprisingly, the focus of the cost-saving effort will be on Section 404,
which requires testing and reporting on internal controls.  It is where
most companies have run into the most difficulty. The FT quotes Donaldson
as saying that he wants to make these rules more cost-effective.  He also
said that his commitment to the principles of Sarbanes-Oxley remains unchanged.

So … it seems possible that we will see some modification to the rules
implementing Section 404. 

Is this a problem?

I have already used these blog entries to argue that "compliance," per
se, should not be the central focus of a company’s Sarbanes-Oxley
effort.  The real focus should be on establishing internal controls that
will provide strong assurance that financial information is accurate, that
encourage efficient, effective use of resources, and that safeguard assets and
records. "Compliance" emerges as a result of putting such controls in
place.  Clearly, if a company is driven by these kinds of internal goals,
changes in SOX rules will not be a primary concern.

But, realistically, it is also clear that many companies are in the position
of just trying to comply with the rules.  Business doesn’t like
uncertainty, and potential rule changes introduce uncertainty.  Will this
uncertainty have an impact on your company’s compliance work?  Will it
affect your plans to create the kind of sustainable internal control framework
that I have been talking and asking about over the past few days?  Send
me an email or post some comments …