Common Misconceptions About Governance
Posted by Jeff Papows on Fri, Jul 08, 2011 @ 03:23 PM
There are many misconceptions surrounding the meaning of “software governance,” as well as how effective governance programs can/should be put into place. All of us here spend a fair amount of time examining and answering these questions.
We figured it deserved a post (actually, several posts). We’re tackling one now, and below that is a list of some of the more common misconceptions that we’ll be countering in the coming weeks.
“We have the best developers and airtight processes – we don’t need governance”
Even the best code is flawed. If someone believes that their team’s large-scale development efforts are truly beyond reproach, then we won’t quibble about what “airtight” means.
Instead, it may be more beneficial to focus on the fact that software development efforts often must pass muster with other business units. Architects frequently are challenged with proving to other departments the benefits of an initiative before implementation. This can lead to problems, oftentimes communications problems. “Management cares only about the bottom line,” “our devs design programs and services around the way that they would use them, not how our customers would use them,” etc., etc.
Business-side managers often will not understand an architect’s job. An effective governance solution enables architects to share progress, explain challenges with data and graphs, as well as demonstrate results against compliance mandates.
This provides a way of demonstrating the impact that development efforts have on the business, without needing to be fully versed in the esoterica of coding to understand it. Governance can give business units unwavering confidence in IT by assuring with more than just a promise that regulatory and internal needs are being met.
More to come:
“We only work in X language”
“Governance takes work out of the hands of developers”
“Developers are resistant to the idea”
“Governance is only needed for mature SOA initiatives”
“SOA governance can be done without policy enforcement”
“Automation is something to fear”
“I have testing tools, so I don’t need governance”
“I use registries, so I don’t need governance”
“Defining policies is risky”
“Architects and tech managers are too busy for another process”