This is a topic that is of key interest to me in my role as an Enterprise Architect and IT Strategist.
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.
Presently, I’m serving as the Enterprise Architect for Aer Lingus (Dublin, Ireland) and tasked with introducing IT Governance and the role of the Technical Design Authority (TDA) with a view of installing quality assurance disciplines to improve Business/IT alignment. I am also keen to ensure that IT has the correct controls and structures in place to avoid being “pushed around” by the Business.
Governance is not a new topic by any means. In this day and age, where end-users are fast becoming used to more responsive, agile and scalable IT solutions, governance is required to ensure that “demand and supply” between Business and IT are managed respectfully and properly.
Read on …
Why Governance? And Why Now?
By Ron Karas , 08/05/2010
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.
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.
I think this is an excellent description of the why and when of governance related to IT changes.
Governance related to IT changes is a very important part of IT governance.
I think the most dificult part of implementing IT governance is to create consistency between the governance of IT changes and the governance of the “un-changed” portfolio of IT assets.
Many thanks Erik. You make an equally excellent point about the role (and challenge) of IT Governance in relation to the over-arching IT Portfolio which is often neglected. From an Enterprise Architecture perspective this is indeed something that should be taken into consideration when looking at an organisation holistically. However, this seldom happens (based on my experiences) due to the narrow focus organisations typically take when considering ways in which they can change (and improve) their enterprise. Would welcome any other comments/thoughts you may have regarding this topic.