Everware-CBDi Industry Analysis Report "In Search of a Common SOA Language": What is a Reference Model?

A few days ago, the January 2007 version of the CBDi journal dropped into my email inbox. This issue analyzed the Reference Model Landscape - including architectures, profiles and meta-models.

Let me be clear, the article does a good job of comparing various efforts that purport to be a reference model for SOA. There are a few key points of analysis with which I disagree. While I have a few moments of time over the next few days, I'd like to share my thoughts on these points of disagreement.

The SOA Reference Model is not a Reference Architecture

It was likely necessary to extend the boundary of analysis to reference architectures and meta-models so to identify enough efforts for a broad comparison. However,

A reference model is an abstract framework for understanding significant relationships among the entities of some environment. A reference model enables the development of specific reference (or concrete) architectures

The report posits that "the OASIS model, while adopted as a standard, is a rather fuzzy 'reference architecture' with many of the concepts deemed necessary by the authors of this article left clear or undefined."

Attempting to compare the relative merits of reference model with reference architectures is like trying to compare apples and carrots. With this analogy, we can compare the qualities of fruit vs. vegetables or the specific characteristics each food item. However, building a comparison of the relative strengths and weakness of each does not consider when the differences are intentional and appropriate.

Comments on Everware-CBDi Industry Analysis Report on "In Search of a Common SOA Language"

I receive the monthly newsletter from CBDi and usually find much useful and insightful information. I was disappointed to receive this month's newsletter with the following headline "in Search of a Common SOA Language." The article starts out with "we believe that a widely accepted reference model for SOA will accelerate the take up of SOA, since tool vendors and practitioners will have a more solid and common base to work from."

As part of the reference model landscape, the following sources were analyzed:
W3C Web Services Architecture
OASIS SOA-Reference Model
IBM UML 2.0 Profile for Software Services
OpenGroup Open SOA Ontology
UK Ministry of Defence Ministry of Defence Architectural Framework Metamodel
Everware-CBDi "A Meta Model for Service Architecture and Engineering"

I'm working through the article in a bit more depth today....but would welcome a discussion on this list on the validity of the strengths and weaknesses that were identified.


The full article can be found at: http://www.cbdiforum.com/bronze/journal/2007-01/in_search_common_soa_language.php

Hit in the pocketbook, governance and budget priorities

Found some notes from earlier this summer from some blog reading...I can no longer find the original reference...so if anyone can help me track down the original so I can attribute....

However, while these notes were originally captured because of their relevance to service granularity; they also suggest the some of the responsibilities of the enterprise from a SOA governance perspective.

"Some who have started down the SOA route have soon found that coming up with popular services that expose data – previously hidden away behind obscure stored procedures and SQL requests – hits the wrong departments in the budget. Services often prove to be too popular – and the people who like them are not, necessarily, the ones who have to foot the bill for them."

Is this indicative of a service approach that is overly granular? If these services are really functions, then yes, this is a problem at the outset. However, services should really be aligned and defined by business/mission functions. Perhaps this burden of popularity is really good market research that indicates where there is a competitive competency that is waiting to burst out from the organization who pulls the data together.

First, to note that the organization suggested by this 'burden of popularity' might not be the office who owns the data. Rather it is the data steward or the office that puts enough together to create value with the data.

From another perspective, it sounds as though there is a missing element in this scenario in which there is no clear understanding or organization of capabilities within the organization. Perhaps the switch to services, which reduce the barriers to interacting with services through standard interfaces and detailed specifications, is only emphasizing what is broken in the organization. This seems to resonate with me. It isn't that the technology is broken. Rather it magnifies problems, or lack of awareness, that exists in the organization already.

If individual groups offer services to other parts of the organization, they have to get away from the idea of throwing services out and seeing what happens. Experts in this area all insist that SOA needs an architectural overview in the first place. And it needs to commit to service delivery and financing that genuinely looks at departments or groups as providers of actual services, rather than lumps of code that happen to have been tagged with the name ‘service’...You need to educate people about what it means to expose services and look at the commitment it needs. Commitments have cost implications. Where you see that happening it has a more positive effect on IT in how it is governed

I think the distinction come into even clearer focus if we talk about brick and mortar capabilities. You don't just throw out retail products to 'see how they'll do', you don't just 'start focusing on a market segment without a well thought out strategy for addressing the needs of that market segment and a understanding of how the core competencies of the organization provide values to those customers.

Getting SOA done through governance...

According to the SOA-RM, the central focus of service-oriented architecture is getting something done at a business level. In fact, Michael Poulin recently published an excellent article to explore this theme.

Considering the SOA Reference Model
...The function is something the organization cannot exist without; the organization business model is the combination of such functions while the actual implementation of the function is the secondary category. Unfortunately, up 'til now, the majority of IT applications fit exactly into that category. Now SOA creates an opportunity for IT to become the business partner and perform as a function for its enterprise rather than just a support provider

The article rightly points out that the partnership between business and IT is a crucial aspect of a successful SOA. The same goes for SOA governance. This is a key point that Eric Marks and Michael Bell's emphasize in their discussion of governance in "Service-Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology."

Technology products, such as a UDDI registry, are the tools which enable a governance processes that fit the organization. The governance processes, frameworks, and policies defined by the enterprise determine the fit to be achieved. Technology, once again, serves as a key enabler, but ultimately should not define the SOA governance model.

Authoritative Services and the Money-Back Guarantee...

Earlier this evening, I came across Todd Biske's discussion on Choosing Appropriate SOA Governance. In it, he stated:

"...In addition to figuring out what SOA means to your company, you also need to figure out what SOA Governance means to your company. Should you be progressive about governance and focus on cutting edge concerns, or do you still need to cover the basics? What information do you need to provide as part of the governance process, and how much do you involve the people who will ultimately be governed by the policies being set? Ultimately, success will largely depend on how well your approach to these topics match your corporate culture."

How true. SOA is about aligning technology with business objectives. Managing this alignment must remain in harmony with the organization defining those objectives. Therefore, if an organization is built on a Command and Control Management style, governance is more likely to focus on ensuring only the 'right' services are made available by the appropriate service providers rather than waiting for market forces (survival of the fittest) to determine which services should remain. The governance policies appropriate to this type of organization would be heavily design and publication-oriented - and focused on preventing unsanctioned services from being offered. Emphasizing runtime policies in a SOA governance plan for this organization would run counter to the organization's strategies, objectives and processes.

The objective of any SOA governance plan to create an orderly information marketplace. Of course this includes a definition of what constitutes an orderly information marketplace, but I digress. Therefore, implementing SOA governance is about organizational savvy as much as it is about understanding the technical nuts and bolts of implementation.

As I wrote the paragraph, I mentally slapped my head - because it is glaringly obvious that SOA governance is equally about the organization as it is about the technology.

On a side note, I believe that understanding the management style of an organization also provides some insights into how it will approach its service portfolio, its service funding model and eventually settle upon a SOA reference architecture. I'll plan to work on this thread a bit more, but as an initial thought:

A Command and Control Organization will seek to designate 'authoritative services' as the way to control the risk of poor information quality in the enterprise. It also provides some interesting insight into what entities are considered capable of managing risk and suggests some business & technical principles that will drive SOA initiatives within the organization:

1. Providers of a services are emphasized about potential consumers of a services (and likely will reflect in the enteprise service funding model), and therefore
   
2. The primary responsibilities for data quality is assumed by the service provider (rather than caveat emptor), and therefore
   
3. The consumer assumes risk only of correctly authenticating the identity of the service provider (which sugggests that information is not quite considered a first-class object ).

I also need to think about the implications of these statements on the two-sided services market (see Harvard Business Review , October 2006 issue) that is inherent in SOA.