Now, three initiatives are bringing a lot of these conversations to the forefront: cloud computing, SOA and mainframe modernization. There are similarities in the way governance is approached in each of these categories. Each is intended to break down silos, protect and preserve the integrity of information, and provide IT with more agility to create business value.

As more applications and services are exposed and potentially proliferate throughout the Web and across composite applications and services, the greater the risk associated with access and reuse of these technology assets. This gap will continue to widen as more products and services are introduced and integrated. As the infrastructure continues to evolve, there will be a demand for improved transparency due to the higher likelihood of policy violations and coding errors.

Yet, governing those assets as they evolve with the infrastructure can be tricky in terms of responsibility and ownership. That’s because it’s hard to clearly define the boundaries of an application or service once its used by different teams. This becomes increasingly more complex once an application or service is tweaked to address a specific business need; more changes to the software increase the vulnerability of coding errors if governance is not appropriately applied.

Applying governance after the horse has left the barn can often be difficult and somewhat ineffective. In this context, governance is regarded as a tactical effort focused on tools and functions within the infrastructure, as opposed to a more strategic initiative designed to align technology with the company’s larger business goals.

There are several reasons, or excuses, as to why governance sometimes takes a back seat in the overall IT strategy. It usually takes a combination of culture and software development processes that view governance as the step to take when things go awry or to be applied to only the most critical applications and services. While governance may be a priority for certain departments and controls may be in place with regard to how much of an application or service is shared, inconsistent governance practices will eventually make themselves known in unexpected ways.

When to Start

The specifics of where and when to start with governance depends on the existing infrastructure, and its maturity and reach. The simple answer to where and when to apply governance is at the onset of an IT initiative. Lack of governance from the earliest stages has a cost. The cost of fixing software code after it’s been deployed can be from 30 to 200 times higher than if the issues were addressed as the code was being written.

In an ideal situation, governance is part of the planning and design phases and carried out throughout the software development life cycle. Unfortunately, going back in time and retracing steps is usually not an option, especially for larger organizations with multiple IT balls in the air. When new initiatives such as cloud or SOA are being mapped out, they present the opportunity to insert governance as part of the overall technology strategy.

But what if there isn’t an immediate and new opportunity to extend governance policies and practices beyond their initial scope? This brings up the question of allowing governance efforts to simply remain the same. Why fix it if it’s not broken? While a company may choose to keep its IT infrastructure status quo for many sound business and architectural reasons, the reality is that there will come a time when they’ll need to interact and exchange information with a partner, customer or other outside organizations who have exposed part of their infrastructure to the Web. To mitigate the associated risks and increase transparency will require more stringent governance by both parties.

Culture

Governance is most effective when introduced through the combination of culture and technology. This requires raising awareness of its relevance and importance to the organization in a manner that’s in step with the company culture and existing processes. Engaging developers, encouraging the sharing of best practices and creation of policies and attaching rewards are some ways to achieve this.

From a technology standpoint, the use of existing policies and best practices can accelerate governance efforts significantly reducing the hours required to create these tools from scratch. The concept of policies and best practices are usually not foreign to development teams. However, consistent enforcement in the form of a real governance initiative typically is. In fact, many of them are widely available from architects and developers who realize the value to the industry as whole by paying it forward.

Can there ever be too much governance? Yes – too much governance can be worse than too little governance if it hinders productivity. Start off with a more passive approach to governance in the early stages of development, notifying project teams of issues and their potential impact. As you move closer to production, you can take a more active approach, such as blocking users from checking in artifacts to the registry/repository unless they comply with established policies.

An important point to keep in mind is when organizations are instituting governance for the first time it is a new effort and will require additional costs in the short term but ultimately will reduce overall development costs.

Making governance worthwhile requires a consistent approach to developing and deploying applications and services. It also means enforcing policies across different departments based on a common set of best practices, standards, policies, and patterns.

Finally, it stands to reason that if the services and applications are going to be distributed throughout the infrastructure, so should governance. This way, enterprises can put into place the policies and best practices that should be followed as the software continues to evolve and serve different parts of the organization whether it’s an SOA, cloud or any major IT architecture.