Opinions about 'Navigating the SOA Standards Landscape AroundArchitecture'

["Mike Poulin" <mpoulin@usa.com>]

Folks,
 I would like to copy you two posts I found in my SOA discussion group about the 'Navigating the SOA Standards Landscape Around Architecture' work. This might be interesting to know.


#1

<<You will have heard the joke before: “The nice thing about standards is that there are so many to choose from.” Sadly in SOA land this is reality.

The need for standards in SOA are multivarious including standard concepts so we all speak a common language, standard meta models that underpin profiles, repositories, deliverables, specifications etc. standard protocols that allow implementation and platform neutrality for service publication and consumption. In this note I am interested in concept standards that support architecture and the full life cycle.

In this area we all know we have three “horizontal standards” organizations (OASIS, The Open Group and OMG) that have each followed their own path, ignoring the blindingly obvious need to have consistency across their work. The situation is so ridiculous that the three organizations resorted recently to publishing a document to explain how to navigate around the SOA architecture standards. Curiously although the document is branded by the three organizations and acknowledges participation and contribution from all three organizations, the document is formally a joint OASIS and Open Group document. One might be forgiven for assuming they couldn’t agree the legalities of the collaboration. Also the document doesn’t address inconsistencies between standards and guidance produced by the same organization.

The document declares two goals – 1) to help users to understand the strengths of each body of work and select products appropriate for their needs. 2) to encourage consistency. But the latter is declared only as a secondary goal!

But inconsistency is only part of the problem. We must judge any standard in its support for the user community and crucially user adoption. The primary purpose of these standards under discussion is achieving common definitions of important concepts and simply put they have failed to achieve widespread adoption because of the competing efforts have confused the user community. Further individual efforts have in my opinion failed to meet user needs.

While TOGAF is getting considerable traction our experience is that the parts of TOGAF that get used are the ADM and the contracts. Not the concepts and meta model, because they are patently not based on real world experience. They are both too verbose for some purposes and insufficiently detailed for others. And the guidance for use is non existent.
Similarly the OASIS model is widely regarded as academic – not useful in practical application.
I have more respect for the OMG’s work in SoaML, because it is usable in support of code generation, but it suffers from over generalization, which makes it very hard to use by mere mortals.
I observe that in the referenced “navigating” document the nearest the authors come to agreements on core concepts is at the most superficial level. I see no evidence that there is any real intent to deliver real convergence at a meaningful (i.e detailed, defined) level of abstraction.

Over the years CBDI has encouraged standards efforts; we have consistently made the case that common concept standards are essential at all levels of abstraction. We didn’t just sit by; we developed our own meta model which actually predates most of the work referred to above, and made it available to standards bodies. Frankly we fully expected that our work would be superseded by the standards work and that we would progressively align our SAE models to a converged standard.

Well you won’t be surprised to hear that the complete opposite has happened. This month we are publishing V3 of the CBDI-SAE Meta Model for SOA. We have actively participated and contributed to the OMG SoaML work and we are pleased to announce a high level of alignment. This is possible because of the highly generic nature of the SoaML work.

The CBDI-SAE meta model has always been very different to the various standards bodies work. We have focused on what may be termed a detailed Business Type Model (DBTM). The goals of the DBTM are to provide consistency of concept for use across the life cycle at a level that can be implemented in tools and inform practical architecture and full life cycle deliverables. And of course users of the CBDI-SAE meta model tell us that is exactly what they use it for – populating architecture and service repository schemas, underpinning UML profiles and defining detailed of deliverables that can provide full life cycle traceability and governance.

What we didn’t anticipate at the outset was that our meta model would actually form the basis for a further purpose – to provide a mapping between the other concept standards such that users forced to work with multiple conceptual schemas (few of us live in a homogeneous world) would have a basis for coordination and possibly transformation.

So as a user what do you do? Currently we see minimal use of these concept standards because they are inadequate. We recommend that you continue (or commence if you are a late adopter) using the CBDI-SAE meta model. We will commit to map to the other standards and, if and when they ever get to a credible position of convergence, we will certainly plan model convergence also. But we will need more than alignment of the concepts, we will need to see practical abstraction and detail required for real work.

We will be announcing a user review of the V3 model very shortly and welcome all input.>>

You can find this blog at: http://davidsprotts blog.blogspot. com/2009/ 10/failure- of-soa-standards .html



#2

<<My Colleague David Sprott blogs this week on the Failure of SOA Standards
There is no need for me to repeat his comments.

In his blog, David comments on Navigating the SOA Standards Landscape Around Architecture, a paper recently published by OASIS and The Open Group. It seems to us and many others that this is an attempt on the part of the authors to gloss over the fact they have managed to produce three alternative SOA standards when the world really only needs one. Saying that OASIS SOA RA is ‘similar’ to the Open Group SOA Ontology is a bit like saying Cricket is similar to Baseball. Because they both involve similar concepts of bat and ball presumably this means a cricket team could play a baseball team?

It is only with a more detailed level of mapping of more precise meta models that anything useful can be done in the real world. Even then, the reality is it is difficult to mix two frameworks and meta models.

One of the intriguing things for me is the involvement of common participants in all three SOA standards efforts at OASIS, The Open Group and also at OMG. IBM in particular stands out as a vendor who appears to have put significant effort into them all, and with minimal visible consistency resulting. Why? How does it help IBM customers to provide them with a choice of three alternative SOA standards? Surely that only works to slow adoption of SOA, not to encourage it.

This was one of the major successes of Web Service Protocols – that there is only one standard for each requirement in the protocol ‘stack’. Even though the various protocols are administered by different bodies, they have managed to avoid competing. Well eventually anyway after some initial vendor-based alternatives fell by the wayside. And since then take up has been widespread. Partly this was achieved because vendors such as IBM together with Microsoft participated in only one activity per protocol and not three. Hence others were forced to make decisions to go one way or the other rather than sit on the fence and be endlessly compromised by choice.

And this is what the same groups now need to do with SOA standards. Combine their energies, put aside their differences and produce a set of unified standards – even if different elements within it are administered by different bodies, as with Web Service Protocols, so they can each retain some ownership. We only need one SOA Reference Model, one SOA meta model, one set of principles and so on. But once you have the common foundation, just like the Web services efforts, there can be parallelism. From our work on the CBDI SAE meta model we know that there are multiple views which can be modelled concurrently such as business, specification, implementation, deployment, testing etc.

That said, perhaps more of the competitive approach taken with Web Services would be apt. That is, I would rather see IBM back one SOA Meta Model standard for example, and not three. I am sure the competitive nature of early Web Service protocol standards activity really helped to force the pace – a sort of SOA ‘Space Race’. Now, rather like the pace of the space race today, I get the impression it will now be decades before we land on the SOA moon. Of course, if OASIS, The Open Group and OMG cut the stack up as I suggest and avoid overlap so much the better.

But why is this important? At runtime, clearly the vision of SOA wasn’t going to work without consensus on the interoperability standards. But I believe it would be a mistake to assume a similar consensus isn’t required at earlier stages in the life cycle. Time after time we see that the lack of a common SOA framework is hindering SOA adoption in organizations. Sure different projects can all agree to use Web Services at runtime, but the lack of any common standards before they even get to that point means that much of the SOA vision remains elusive when viewed from an enterprise perspective. It is pretty hard to have full life cycle asset management and governance over SOA deliverables if the concepts change for each phase. In most organizations, users have little choice but to pick a single vendor's proprietary solution to such requirements that complies with no relevant SOA standards.

I am reminded of object orientation pre UML. What is needed now is a Unified SOA.
SoaML, in which we have participated might be one step in that direction, at least at the modelling language level. Even so, TOGAF 9 has its own meta model, but so does Archimate, and there is one implied by the OASIS SOA RA, and so on. Then there are the differences even between The Open Group’s TOGAF 9’s coverage of SOA, and their own SOA Source Book. Do you know for example when you see a concept mentioned in one document it has the same meaning as in another? Often no definition of the concept or reference is even given so it is difficult to be sure. Clearly there is still a long way to go.

And let’s not forget that there is a large government and defence sector who are extending their own frameworks such as FEA, DODAF, and MODAF with yet more unique perspectives on SOA.

It is at least welcome though that OASIS, The Open Group and the OMG have seen the need to cooperate on Navigating the SOA Standards Landscape Around Architecture. Perhaps now they can move forward as I suggest and ensure greater collaboration and consistency between their efforts with a single purpose in mind.

We would be happy to participate in such a unified process. What we can’t afford to do unlike IBM is participate in three (even though they have all invited us to), and more to the point it would be counter productive! In the meantime we will continue to participate in SoaML and refine our own CBDI-SAE Meta model for SOA. To that end we have just published a draft V3 of our model which includes SoaML adoption.

Users shouldn't need to be shown how to navigate their way around multiple SOA standards. They just want to know "are we there yet?">>

You can find this blog at: http://lwsoa. blogspot. com/2009/ 10/unified- soa.html


Cheers,
- Michael


> ----- Original Message -----
> From: "Mike Poulin" <mpoulin@usa.com>
> To: Danny.Thornton@ngc.com, soa-rm-ra@lists.oasis-open.org
> Subject: Re: [soa-rm-ra] Groups - Authorization.png uploaded
> Date: Wed, 30 Sep 2009 15:12:26 -0500
> 
> 
> I would like to add one element to the digram next to the 'Role' 
> box - the 'Rule' box
> 
> When I designed an Entitlement System for JP Morgan's Credit Risk 
> Management, we could not address all needed authorisation 
> combinations via Roles only (RBAC has limits). The solutions was in 
> Rules. Combination of Roles and Rules can cover all cases of 
> Authorisation. Rules sound like Policies but authorisation rules 
> are not the same thing as Business Policies that lead to defining 
> certain access rules.
> 
> - Michael
> 
> 
> 
> > ----- Original Message -----
> > From: Danny.Thornton@ngc.com
> > To: soa-rm-ra@lists.oasis-open.org
> > Subject: [soa-rm-ra] Groups - Authorization.png uploaded
> > Date: 30 Sep 2009 16:09:45 -0000
> >
> > The document named Authorization.png has been submitted by Danny Thornton
> > to the SOA-RM Reference Architecture SC document repository.
> >
> > Document Description:
> > Update to Figure 55, Authorization
> >
> > View Document Details:
> > http://www.oasis-open.org/committees/document.php?document_id=34459
> >
> > Download Document:
> > http://www.oasis-open.org/committees/download.php/34459/Authorization.png
> >
> >
> > PLEASE NOTE:  If the above links do not work for you, your email application
> > may be breaking the link into two pieces.  You may be able to copy and paste
> > the entire link address into the address field of your web browser.
> >
> > -OASIS Open Administration
> 
> >
> 
> 
> --
> An Excellent Credit Score is 750
> See Yours in Just 2 Easy Steps!
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

>


-- 
An Excellent Credit Score is 750 
See Yours in Just 2 Easy Steps!