Of course, there's the SOA audience that believes governance is about creating a more efficient and more easily integrated applications and web services.

For mainframe professionals, governance usually conjures images of security and for those closer to the business, it typically refers to compliance.

As you can imagine, applying the definition that suits your current business needs can be a slippery slope and will inevitably lead to serious issues when a company invests in governance.

For example, consider a financial services firm that has decades' worth of data located on a mainframe. Given the sector's focus on compliance and high adoption rates of SOA, you can imagine how quickly a governance conversation with different department heads could turn into something like the Abbott and Costello's 'Who's on First' bit.

This is just one of the many reasons why we need come to a consensus on the meaning of governance as it refers to software development and as those development efforts extend to different environments including SOA and the cloud. 
Sidenote: Dana Gardner's Briefings Direct podcast series actually touched upon the need for governance and the cloud in the episode titled, "Where is Cloud Computing going?"

I propose that governance is about better managing the processes within the software development life cycle - and across data, infrastructures and processes - so that policy violations and errors are identified well in advance of their affecting the performance of technology that supports the business.

And while most people have already joined SOA and governance at the hip, it's important to separate the two. Yes, they're complementary but clearly they can exist without each other. In fact, governance goes far beyond SOA and can be applied to many facets of IT. 

I'd even argue that nearly every keystroke could benefit from governance running behind the scenes. Not as an extra set of eyes but more as a way to ensure that the technology really does adhere to established policies so that the finished software product is not littered with bugs or policy violations that will make their presence known in the form of $23 quadrillion cigarette charges, trading floor outages or credit card security breaches.

I'd love to hear from anybody out there who has a non-SOA related IT challenge that governance helped to address.

Interesting point and the reuse discussion has been, well, 'reused' by SOA proponents and opponents alike. The reality is that reuse became a bit of an amorphous term and more of an ideal once IT realized that the concept was stronger than the execution in a lot of instances.

However, I take issue with the way that Woods continues, 'what will save SOA is to split the process of creating services into two stages. In the first, you just use or build whatever services you need to support a new application. You don't worry about governance or reusability. You just get the users what they need.'

To me, this approach could be one of the keys to a stalled or failed SOA initiative. Think about it. If you subscribe to 'get er done' tactics, this approach may seem reasonable. However, it may not take into account the longer-term impact of how that application or parts of it will inevitably extend beyond the original team it was intended for. 

Actually, not worrying about governance or reusability strikes me as a bit counter-intuitive to the whole SOA value proposition. After all, reusability was one of the most often uttered phrases in the SOA pitch. Yet the lack of reusability is often due to inconsistent and erroneous development approaches. Approaches that may have never been put in place, nor would they have reached the deployment phase, had governance been in place at the get go to alert the architects and developers that something may be awry in the code.

In fairness, the opinion article takes into account the second stage where 'you look at the portfolio of applications and services you created and attempt to identify patterns and opportunities to collapse several of the stage-one applications and services into reusable service and common applications.' 

This is a sound strategy though perhaps cancels out phase one? Further, it brings up the somewhat circular conversation that's happening these days about services ownership, creation and cost. Who, in fact, does own the original service and can they charge a colleague to use parts of it as part of a reuse strategy? While that is a discussion for another day, what the industry can agree on by and large is the incremental approach to SOA. 

What I believe, however, is that agreement on design and architecture in accordance to business goals before services are created is a critical first step. And, of course, I'm going to tell you that this is where governance has the most impact on the longer-term benefits of the SOA project.

Agree or disagree with the Forbes's piece on 'SOA Revival?' Drop me a line and let me know as I don't think this one is truly black or white.

-Jeff

What's important to note and good to see is that federal SOA projects are making traction and agencies are seeing results. Results that the private sector should take a closer look at from a best practices and benchmarking perspective. 

David Linthicum pointed out the success of the government SOA efforts not long ago. In his post, he writes that 'a clear pattern of success with the U.S. government when leveraging SOA is around the governance that typically exists within and between U.S. government agencies.'

The government's approach to SOA reflects its approach to business in general. While there are agreed upon standards, protocols and processes, the biggest differentiator is not in the way these requirements frame the agency's day-to-day operations. Rather, it's in the way that they are adhered to by all the different functions throughout the agency. This is governance from a business perspective that is carried through in the IT architecture. 

Of course, many commercial businesses have been talking about standards, best practices and reuse for quite some time. However, making it all come together still presents a stumbling block due to a variables such as redundant services, different architectural approaches and a general lack of visibility. These issues are largely the result of a lack of governance or worse, spotty applications of it.

While many IT vendors have been working with the government for decades, there are a host of others that are just now knocking on agency doors in hopes of tapping into some of the stimulus funds allocated to technology. Who can blame them? But applying commercial practices to federal SOA efforts may not be the best approach especially when comparing the success rates. However, the opportunity is still very ripe in the following three areas: 

1. SOA expertise: while the processes and best practices may be further along, there is still a tremendous need for systems integrators and consultants with in-depth knowledge of industry standards and integration that can help accelerate the deployment.
2. Governance: okay, this is not just a WebLayers thing. Think about the massive undertaking that is required by the agencies to make SOA a reality. Without governance in place, individual agencies will see hiccups and will be unable to connect to other agencies and a larger federal SOA initiative.
3. Mainframe modernization: it's no secret that the government still relies on legacy data and mainframes. Since there's no sense in throwing the baby out with the bath water, expertise and technology that can support a SOA that encompasses the entire infrastructure including the hardware will continue to prove valuable to agencies.

-Jeff