Thursday, July 20, 2006


The Joy of SOX

I'm writing about a book with this title… and there’s no misspelling here. It will help if I add that the subtitle is "Why Sarbanes-Oxley and Service-Oriented Architecture May Be the Best Thing That Ever Happened to You." Its author is Hugh Taylor, the VP of Marketing at SOA Software, whom I met a couple of months ago at the OASIS Interoperability Conference in San Francisco.

The Sarbanes-Oxley Act was enacted by the US Congress in 2002 to curb corrupt business activities and fraudulent accounting practices like those of Enron and WorldCom. SOX requires firms to implement adequate internal control structures and procedures and attest to their effectiveness. The essence of SOX for someone with my perspective is that a firm needs accurate information about anything that affects its financial statements, and the best way to capture and maintain that information is by automating business activities and internal operations. So that's why I talk about SOX in two of the courses I teach at UC Berkeley's School of Information: Information Organization and Retrieval and Document Engineering and Information Architecture.

Much of the writing about SOX is impenetrable, filled with accounting and business jargon. But "The Joy of SOX" reads almost like a novel, because Taylor has brilliantly written it as a comprehensive case study of a fictitious company’s efforts to deal with SOX. So Taylor's CFO character explains aspects of financial controls and reporting, his CEO and COO characters explain the interdependence of business strategy and controls, and his CIO character explains how computing infrastructure and software development practices shape and are shaped by the controls and strategy.

I especially enjoyed (and so will my students, because now my lectures on SOX will be more concrete) the many examples of how controls, business models, and information technology come together. For example, the case study firm doesn't have a uniform product coding standard, which makes it hard to track inventory and transactions, and this problem is made worse by its practice of buying closeout inventory from suppliers. Another example shows how a good policy for managing employee passwords and access privileges is worthless without policy enforcement and change management processes.

This book enabled me to finally understand some of the arcane details of compliance, just as accountants and business people who read this book will be able to understand service-oriented architecture, enterprise integration, and business process specification languages.

In addition to being hard to read, most of the writing about SOX presents it as a necessary evil to prevent worse evils from being done to unsuspecting investors or other stakeholders in a business. No question that SOX is causing increased spending (some say excessively so) in document and records management, security, business process management and document engineering as companies define, document, and automate the processes that are needed to run the company while enabling auditing and timely reporting. Some of my former students who are working for IT consulting firms are saying that SOX is like "Y2K that won’t go away" or a "full employment act" for them.

Again, here's where The Joy of SOX is unique. Taylor argues against the standard "lose-lose-lose" proposition that most people see in SOX:

If you comply, you may harm your ability to be agile and stay competitive

If you don't comply, you could go out of business (or go to jail)

If you make an empty effort at compliance, you may pass through the process but merely bury company-killing problems (and spend a lot doing so).

Instead, Taylor argues for "agile compliance," urging firms to treat their SOX efforts as an investment. This approach relies on service-oriented architecture, business process specification languages, and so on. He makes a very compelling case.

If you want SOX, buy this book.

-Bob Glushko

Ordered the book already! Sounds great. Using compliance, with SOX or Basel II or whatever, as the basis for needed changes in how you automate your business is going to be key. Agile compliance is a great buzzphrase and one I am sure we will hear more about.
I have blogged about how to use business rules technology to deliver agile compliance here.
It is also interesting to note that it is not business process technology alone that works here - you need control of the decision points too as many compliance issues are around showing why you did what you did. I blogged on this too here.
Two other posts that might interest folks are here and
Post a Comment

Links to this post:

Create a Link

<< Home

This page is powered by Blogger. Isn't yours?