Book Review: The Joy of SOX
How can you resist a book with a title like "The Joy of SOX"? To give you some idea of the content it is sub-titled "Why Sarbanes-Oxley and Service-Oriented Architecture may be the best thing that ever happened to you" and it is by Hugh Taylor. I was pointed at the book by a fellow blogger (Robert Glushko who blogged about it here).
Like Robert, I liked the book. It was the first intelligible or helpful summary of Sarbanes-Oxley I have come across. Using an imaginary scenario it laid out both a plausible current state and accurately described the way in which business change might put the company's IT systems, and SOX compliance, at risk because they could not be changed quickly or accurately enough to respond. As Hugh says "The biggest problem with SOX and COSO...is that it[sic] assumes a relatively static mode of business operations, and today, to be static is to be dead". The book goes on to lay out how SOA is a key ingredient to building a profitable business that is also highly controlled and where processes are visible both to management and to regulators. Most of the chapters are very readable, even some dealing with an alphabet soup of standards and standards bodies. A couple were heavier going and a few seemed like they needed to be longer - there was a certain amount of "and then magic occurs" that I am sure Hugh could have addressed in a longer book.
The book does a good job of discussing how "The problem is that computers and the software that runs on them...are notoriously difficult to change with any speed or accuracy" but I did feel that Hugh only addressed part of this issue. He said "At the risk of oversimplifying, the major bugaboo that slows down IT projects is the prevalence of hard coding, or the necessity for expert software developers to write specialized programming code in specific programming languages to enable changes to take place in the systemic environment." and he is absolutely right. A flexible process, however, is only have the solution. What he did not discuss is how to develop services that are, themselves, easy to change. While an SOA can make it easier for new processes to be assembled and while it does isolate change in different parts of a complex environment, it will not necessarily make it easier to change a service. When the company wants to change its rules for exception flagging or management referral or when it changes its pricing algorithms, having them hard coded into a service in Java will not be much better than having them hard-coded into an ERP system. To deliver on the agile compliance story Hugh outlines, you need also to be able to develop services that are easy to change and that's where business rules come in. Only if the services can be evolved with accuracy and rapidity will you avoid a "perpetual state of unfinished IT initiatives" and be both agile and compliant.
The second, minor, issue I would take is Hugh's focus on reporting and dashboards as the only real issue for compliance and data. For instance, the"big solution" the book's fake company is using seems focused on data integration and dashboards. There are no real analytics in this, no discussion of how to make sure the analytic models you might use (to estimate credit for instance) must also be visible and compliant and agile, no discussion of how to feed analytic results into services (given that most services cannot read a graph or understand a dashboard the way a human can). The potential forputting analytics into services to make the services in your SOA as "well informed" as your staff is huge.
I also liked his heat-map idea for identifying top candidates for problems with compliance and will think about how it might apply to EDM.
These complaints are, however, minor. For those of you interested in Sarbanes-Oxley or COBIT but not willing to wade through a lot of material, this book is a nice introduction and you can buy it here.