As any architect will attest, governance is not so much a question of 'why,'
but rather about 'how' and 'when.' More specifically, conversations and debates
usually focus on how much governance is really necessary, as well as when and
where to apply it.
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
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.
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,
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.