Gilda Radner as Emily Litella
The United States first came up with the Sarbanes–Oxley ACT of 2002. It was introduced as an attempt to prevent the type of financial fraud that occurred at a number of large publicly traded US and global companies. The headliners were, of course, Enron, Tyco and Worldcom but there were many others. The congressional act was immediately nicknamed SOX and proceeded to create havoc at publicly traded companies in the US and to a lesser extent, abroad. Then, because SOX exists (and for almost no other reason) it began to be adopted in other countries. And the nick-names just won’t quit – Japan has J-SOX, the EU has E-SOX. Meanwhile there has been some refinement back in the US. A seam loosened here, a nip and a tuck there. More importantly, with experience came some published guidelines. There is nothing to be done about the time and money wasted by the largest companies in the US which were first – but things have gotten better for those that are coming along later. Other government-specific and industry-specific regulations have followed SOX and still more are on their way.
In the US, IT organizations still run the gamut from companies with tightly controlled, highly automated IT governance initiatives to those companies that have their heads planted resolutely in the sand. That’s probably how it as always been. We can look back as far as 1989 when researchers at Carnegie Melon were busy developing the Capability Maturity Model or CMM. The CMM is a set of structured levels that describe how well the behaviors, practices and processes of an organization can reliably and sustainably produce required outcomes. The first step in CMM is to assess the organization’s “maturity” – how well do you do what you do – in terms of CMM’s five levels. We can take from this that there were, at the very least, five different levels of maturity in software organizations going back to the earliest days. It’s a well-known secret that there were no companies that qualified as level five when the CMM was first introduced and to this day it is a rare organization that distinguishes itself in this way.
Some companies do have better practices – even what we like to call “best practices”. For some companies it is because they have had to deal with oversight for longer than others – the health related industries, the auto industry and other manufacturing industries have always had certain privacy and safety standards that impacted IT. Still, other companies have more tightly controlled environments simply because they prefer it that way. The vast majority of us, however, are doing all we can to keep up with the rush of demand. To these hard-working folks, the whole idea of IT Governance strikes us as something between torture and a luxury. Those of us who develop software in the MultiValue (Pick-based) and U2 environments are even more impatient with “tom-foolery that just slows us down and gets in the way”. We have always seen ourselves as “agile” – long before that was touted as a good thing.
Is IT Governance an onerous burden that merely slows down production and frustrates developers? No. Does it slow things down? Yes, initially. There is no getting around the fact that in order to step back and assess how an organization is doing one must first, well, step back. That very first step takes time and commitment. For one reason or another, though, it is a step we are all going to have to take. The good news is that the work that an IT organization puts in to complying with regulations can also improve productivity and even morale. It’s all in information and attitude. Oh, and automation!
This series of articles are provided to help you prepare for future IT Governance initiatives or perhaps improve what is already in place. Our knowledge and experience comes from twenty years of providing a robust, automated solution called PRC. PRC is a full IT Governance / Software Development Life-Cycle management tool for U2/MultiValue.
The next article in this series will detail the various specific laws, their jurisdiction and their specific requirements for IT. It will also explore the difficulties – pitfalls that many have fallen into and the areas that give the most trouble and require the most resources.