Updates
Latest Tweet
What's New?
Check out for latest innovation, a computer based training video collection
Like this Page
The Joy of SOX: Why Sarbanes-Oxley and Services Oriented Architecture May Be the Best Thing That Ever Happened to You Review by Earl Beede
Little Joy in SOX, but Helpful Understanding
I make a living leading seminars discussing topics on software project estimation, requirements, and project management. It is not uncommon during one of these seminars to have a participant ask how the practice under discussion would impact or aid Sarbanes-Oxley compliance. What I wanted out of Hugh Taylor's book was a deeper understanding of SOX and some pointers I could give my students.
The Joy of SOX delivered on the first half of my quest. While not an accountant, Taylor did a good job explaining the key points of the act, focusing on section 404. I grew in my understanding of the role software systems play in acting as a "control" and the impact of changes to those systems. A simple definition of a "control" is that it is a device (practice, checkpoint, division of roles) inserted by a company to assist in the determent and detection of fraud.
Taylor, after painting a very bleak picture of what it means to comply to SOX (i.e. insert and maintain all the necessary controls), goes on to propose a solution that allows a company to react as necessary in business while keeping compliant. His solution, using a web based Service-Oriented Architecture. For those who are not buzzword compliant, that means using non-proprietary methods over the internet to communicate between different computer systems. Most of the time today, companies have to pay software development professionals to write a proprietary method. That takes a lot of time.
It is on the second point of my quest that I felt a little let down. Being a software development person, the word "agile" has a lot of baggage with it. He uses the word to mean the fundamental fluidity of the business to engage in new business practices. We software people want to enable that but we use the word an approach to software development. The two don't quite mean the same thing. So when I got to his prescription, I was into an alphabetic soup of software development acronyms that I have never quite liked, even being in the field. Perhaps his way would work, but I think the hype machine is still on over XML, SOAP, SOBA and the like. Hey, given the alternatives he paints in the first half of the book, it is probably worth considering.
So, who should read this book? Well, if you want a decent way of understanding what SOX means to a public business, then the first half is worth reading. The use of the case study makes it a little HBR like and I enjoyed that. If you are a software development professional like me, well, the first half is worth knowing and you can skim the second half. If you are a business professional, you better know the first half. The second half? You can read it but this is what my friends and I would call "beer discussion" topics. There is no "right" answer, only answers that are better given the situation. Maybe bring your favorite IT person along for the beer.