On June 21st, I was a panelist at the Mass Technology Leadership Council’s SOA Governance Event, representing the SOA Consortium. There were approximately 35 participants at this round-table like event.

Some key concerns and efforts of the audience about SOA Governance were:

Creating a Center of Excellence

Establishing a SOA repository

Incurring costs

Managing application level services

Degree of SOA competency by seekers of venture funds

Designing a governance model

Promoting interoperability

Organization of services and their granularity

Transition to target architecture

We focused on the following topics

Standards. State of the standards in the SOA space and their governance

PMO. Challenges in project management in SOA Governance

Predictions. What is the 2 year outlook for SOA Governance

Standards

I gave a brief review of SOA consortium and its efforts to harmonize the landscape of standards, specifications, and recommendations. I mentioned that Consortium has brought multiple standards bodies together and working to create dialogue. I also explained the efforts to establish a Standards repository by the OMG SOA SIG. I had to wait till the afternoon to see the very first SOA Standards Repository built using MDA at our OMG SOA SIG meeting. So, I could not tell about this fantastic tool.

Other comments from the panelists and participants were:

Open source is yet another de facto standard

There is constant vigilance on the user side to keep up with the versions of the standards

Product and user environments often has a mismatch in the standard version

Standards are another set of tools

Defining corporate policy to clear out this mess is crucial

Establish re-use early and create funding of the efforts

There is mandate internally on the standards but this breaks down with the vendors supporting different version of standards

Inward and outward facing standards—in some cases there is a distinction; in other cases the line disappears

Governance for Standards is necessary: which standards for what Purpose, exceptions, documentation

Look at Governance early

PMO

On PMO challenges the panel and the participants talked about:

Transparency

standard design

compliance

aligning business properties

governance for IT/Delivery/Operations

put controls around services about its reuse to prevent from increase in usage volume—think scalability

Incubation period may be necessary for services to be reused

“When silos come down, there will be a hurrah!”

Cannot guess how a service will be reused, so put processes around reuse

Governance requires a significant cultural change

Reuse but not so blindly

Consumption behavior needs to be regulated

Who owns the service? Creator or operator? We may have to establish a stewardship similar to data. Data model owners and the database base owners are different

Predictions

There was no agreement on the timeline for organizations fully establish SOA Governance. The panelists did not see a two-year time frame plausible. A five-year horizon seemed to be more achievable. We all agreed on the importance of Governance and that it will require significant business transformation. This, in turn, will require business process management practices pervasively established in the organizations.

I remarked that while some countries have democracy as their governance model others have despots or kings. Better yet, there are several flavors of democracy. Alas, the world is still spinning. Just like the governance models of sovereign nations across the globe dynamically vary, there will be multiple SOA Governance models. There are already several of them out there. Just like governments change, models for SOA Governance will transform into newer ones. As we embrace this diversity, it is up to each enterprise to choose a SOA Governance model which they feel comfortable but without any further delay.

Posteriori Observations

“It is a jungle out there” says the opening song in the TV series Monk. Whether we like it or not we are deep in the SOA jungle and earlier we start easier it becomes to navigate through obstacles. We need to keep reminding ourselves that SOA is not about technology but about business strategy and SOA Governance, a subset of overall governance, is all about order. Implementing SOA as a business strategy in an orderly fashion calls for business transformation and organizational change.

Ready and willing will clear out of the jungle and will climb Mount SOA. No climb is a solo journey, however. The rise of Web 2.0 and social networking stand as an excellent reminder for the wisdom of crowds. Increasing number of businesses and government agencies are choosing the SOA Consortium as a medium to collaborate to their mutual benefit in SOA, and specifically in SOA Governance (e.g., measuring effectiveness, controlling for compliance, communication to inform all parties, guiding with policies empowering for better decision making).

Comments

You can follow this conversation by subscribing to the comment feed for this post.

Talking about standards in IT governance, I feel less is more.

To keep an organization moving in a consistent direction, high-level and general principles are needed. The creation of software ultimately is an intellectual enterprise in a space entirely of our own imagination and creation. The rules put into place are our own and very loosely bound by physical rules and realities. It is better to have a few guiding principles rather than a number of constraining rules and "standards". In Communications of the ACM, a statement was made that, “Software seems to be subject to fewer such rules [than hard sciences] and is therefore perhaps more like math itself. How does math do design? It provides a few super principles (such as ‘all work must be based on a rigorous proof’), discovering the rest as it goes along”.

Governance needs to be about "super principles” that we expect our IT personnel to abide by when creating solutions to business problems.

These general principles would something like:

• Adherence to a Service oriented Architecture (SOA)
• Adherence to an Event Driven Architecture (EDA) that supports the SOA
• Adherence to a Real-time Processing Model that supports the SOA
• Adherence to a Customer-Centric Business Model that supports the SOA

Within each of these principles, additional guidance can be given, but these major points should drive IT development efforts.