Is Governance Necessary in an SOA?

Untitled Document The issues that are cited for a failed or stalled SOA initiative are usually lack of executive support, inflexibility of proprietary technologies, or an unclear strategic vision.

Regardless of the reason for a sputtering SOA, it doesn't change the end result. Given the time, expense and fact that most SOA initiatives require a green light from the management team before they begin, you have to believe that a SOA journey often begins with the best intentions.



And since hindsight is often 20/20 in these cases, many of the more recent conversations are turning to the role that governance "coulda/woulda/shoulda" played in the SOA. Yet if you read all of the marketing material around governance, you may be led to believe that it's the panacea for all that ails SOA. If only it were that easy.

The goal of governance, to a large extent, is to help companies make the most of their SOA investments. In its simplest explanation, governance does this by overseeing the processes of identifying, assessing, building, and managing services. While governance may be one way to help proactively address potential SOA issues before they negatively affect the business, it's certainly not a magic bullet nor is it for every organization.

So how do you know if governance is worth the time and investment or whether it's going to add another layer of complexity into your architecture?

Five questions to determine if governance is right for your company

Determining whether governance is right for your company will depend on several variables regarding the culture and size of your organization as well as the nuances of the infrastructure.

With this in mind, following are five questions designed to help determine if governance is the right path for your company.

1. Do you have outsourcing partners that you depend on for development of key business services?
2. Are you finding inconsistencies and/or redundancies after a service is deployed?
3. Is the SOA designed to serve various business lines throughout the company including customers and partners?
4. Are you trying to migrate legacy applications off the mainframe?
5. Are you in a heavily regulated industry and/or need to adhere to compliance requirements?

If you answered yes to the questions above, then SOA governance may be worth a closer look.

Governance can support dispersed development teams and ensure code meets internal and external requirements before it moves too far down the development path. And for companies that will continue to rely on COBOL, C++ and other existing mainframe-based applications, governance can help protect those existing assets while introducing service orientation in an effort to make IT more agile to meet the needs of the business.

The SOA governance entry point

Yet a common question about SOA governance is, "Where do we start?" The specifics of where and when to start with SOA governance depends on how extensive and mature the company's SOA currently is as well as the strength of the existing infrastructure.

In many instances, for companies that are further along in their SOA journey, the IT organization already has some kind of systems development lifecycle methodology in place. What is likely missing is a consistent approach to creating and deploying services across different departments based on a common set of best practices, standards, policies, and patterns. Governance can help address this missing piece.

A reasonable entry point for SOA governance, therefore, is by gaining experience in using and enforcing best practices for the SOA service development lifecycle. In many cases, this additional governance focus is an extension of the discipline already involved in managing the lifecycle of systems development.

The danger, of course, is that many organizations view additional processes or governance as over-engineered, useless exercises that just get in the way of meeting project deadlines or detract from getting the 'real work' done.

As a result, governance processes simply aren't followed or they're followed in a less than enthusiastic manner. What is often overlooked is that governance doesn't need to be intrusive nor does it make extra work. In many instances, automated governance can run behind the scenes and is only visible in the event of a course redirection.

The impact of SOA governance on the organization

While governance is often linked with architects, it actually has an impact on developers and line of business managers as well. For example:

Developers: should be able to get real-time feedback on required and recommended changes that will save time and effort resulting in higher quality code.

Architects: should be able to accelerate SOA deployment through a level of transparency.

LOB Managers: should be able to see the progress IT is making and leverage this insight towards connecting the dots on how it impacts the business.

While governance can boost productivity, there are also some potholes to avoid. The wrong approach, technology or lack of business buy-in can set the SOA project back further than anticipated. To avoid these potential pitfalls, following are five key attributes to look for when evaluating and deploying SOA governance offerings.

1. Reinforces the company's system of checks and balances: by reducing the time previously allocated to more mundane tasks while also helping to cut costs and empower staff to work on more challenging assignments.
2. Greater visibility: into the real time status of all of the company's projects or services.
3. Complements the existing infrastructure: by extending and not inhibiting its capabilities and making sure that efforts continue according to plan.
4. Seamlessly integrates with your software development lifecycle methodology: to become part of the process without further burdening the development team.
5. Built using standards-based technology: to protect existing intellectual and technology investments as the SOA evolves.

Too much governance?

Yet can there ever be too much governance? Yes, actually. Too much governance can be worse than too little governance.

In the early phases of development, it's better to provide a more passive approach to governance. As you move closer to production, you can take a more active approach with enforcement of policies to stop users from checking in artifacts to the registry/repository unless they comply.

The level of governance will be determined, in large part, by the requirements and culture of the organization. For example, a financial services company may require more governance due to the nature of its business as well as regulatory compliance requirements such as ACCORD, IFX and SWIFT.

While governance can help address some potential issues associated with SOA deployments, it can't address them all. Further, governance isn't for every organization and requires a deeper understanding of its impact on the business before it can be deployed. However, if you determine that governance is the right path for your company, you'll find that it can help accelerate the return on SOA investments just as long as its surrounded by a sound infrastructure.

About the Author

Jaimin Patel is director of business development at WebLayers. He has more than 18 years of IT management and software development experience gained from the customer point of view at Fidelity and Bear Stearns as well as the vendor perspective from his roles at CA and Predictive.

More by Jaimin Patel