Governance Is Key
Governance is key
Developers and architects alike agree that governance is the primary way that the industry can help stem many of these issues and proactively address them before they get out of hand. Still, even with the best development teams on board, many organizations fall into one of two traps when it comes to employing and enforcing governance to improve the quality of the code.
Trap No.1: The first trap is the belief that they have enough governance.
Oftentimes, governance is applied to separate IT projects that may not immediately have an impact beyond a specific team or division. Yet, with the rise in Web services, cloud computing and service-oriented architectures (SOAs), applications and services that were once dedicated to a small group of users are quickly proliferating throughout different parts of the company (and, in some instances, out to customers and partners).
Trap No. 2: The second trap is the misunderstanding that governance will further delay the software development process, causing product delays.
Upon closer examination, when governance is automated and introduced at the design stage of development, it acts as a background guide to proactively alert developers and architects to when policies are being compromised, as well as to the impact those policy violations and development errors have on the entire company. While a patch or a point release may seem like a quick fix for some of these issues, other issues can have far-reaching effects.
These are the types of errors that are becoming quite common in our daily news feeds. Headlines highlight such errors as the 23 quadrillion dollar debit card charge for a package of cigarettes, or the massive backup at O'Hare International Airport this past Fourth of July, or even the smaller yet equally annoying glitches that interrupt our ability to get our jobs done on time.
You can safely assume that most people have felt the ripple effect of a computer glitch either at work or in their personal lives. Even so, universal acknowledgement should not equate to acceptance on the part of the developer or the customer.