In the first half of this decade there was big push on Web services standards, with a (fairly) good convergence around a core set of standards. However the state of SOA conceptstandards – that is standards underlying the architecture and engineering concepts - is a very different matter.
There are at least four international bodies currently developing standards around SOA - OASIS, OMG, Open Group and W3C, plus some important national bodies (US Federal Government, DoD, MOD).
The key standardsbodies have several relevant artefacts.
-The OASIS SOA Reference Model TC has approved an SOA reference model – OASIS-RM.
-The Open Group is working on an SOA reference architecture and has published an SOA Ontology.
-The OMG has recently released a draft specification of SoaML, the SOA Modeling Language, a UML profile previously UPMS.
The DoD and MoD are looking to use UPDM (UML Profile for DoDAF and MoDAF) from OMG.This profile is relatively close to SoaML and shows that these three groups seem to be coming closer together.This is likely due to the fact that DoD/MoD needs to use standard tools to do their modelling and the OMG is the organization that develops the specs used by most of those tools. The Open Group have based their Ontology on the OASIS-RM. However beyond this it is hard to see much convergence between the bodies.
In addition to lack of convergence between the bodies, it is also obvious that there is widespread inconsistency between parallel groups within standards organizations. As ever multiple, incomplete standards is nothing new. As “users or advisors” we have to assess what value each candidate standard brings and whether it is fit for purpose.
In the context of SOA there are several considerations:
What value do (specific) standards bring? Common vocabulary, high quality, reusable concepts, standard artefacts that can be both reused and shared?
And conversely what is the cost of inconsistency?
And crucially is the standard providing the right level of detail in a manner that supports practical use?
CBDI has pioneered many aspects of SOA standards. The CBDI Frameworks, meta model and UML profile pre-date the work of the standards bodies working on defining SOA structural standards. The CBDI frameworks have been made widely available; the CBDI SAE Meta model and related UML Profile have thousands of downloads and are widely used. Some industry groups have based their work on it. (Notably HL7). Many CBDI Forum members have used the SAE meta model as a basis for their asset management schemas, and the UML Profile as a basis for SOA architecture and design deliverable formats.
For CBDI and our Forum member users the question is how do the CBDI models compare and should they move to adopt one or moreemerging standards and when?
CBDI SAE is an SOA methodology which provides considerable depth in practice guidance based on therigorous underlying meta model. The OASIS-RM is a conceptual model of SOA and there is significant alignment between the CBDI work and OASIS-RM. However CBDI has focused it’s efforts differently to OASIS – The CBDI Meta Model is not purely a conceptual model, rather it is a working level, detailed meta type model that provides the basis for life cycle meta data that will be managed in registries and repositories. In contrast the OASIS-RM and Open Group concept models provide either no or limited cardinality or optionality rules, and are therefore open to interpretation, leading to inconsistencies in implementation.
CBDI is monitoring the work of OASIS-RM and may a) contribute to certain areas and b) consider alignment of the CBDI meta model as appropriate.
CBDI is also monitoring the work of the Open Group and plans to assess potential for alignment when the current SOA work is published. The Open Group SOA Ontology is a derivation of the OASIS-RM, and is a similar concept level model. We have discussed with the Open Group the possibility of donating the CBDI Meta Model as a way to deliverfurther detail.
CBDI has supported and contributed to the UPMS work, now renamed SoaML. There is significant alignment between key areas of the CBDI meta model and UPMS. The SoaML is somewhat more comparable to the CBDI models insofar as it is fully detailed. Where it diverges is that the SoaML is a UML profile – and therefore its purpose is to support tool design; the CBDI models provide richer metadata whereas SoaML simply provides a means to represent the basic elements in a model.
You may well ask the question, so what’s the difference between the SAE UML Profile and the SoaML? First the SAE Profile is broader in coverage that the SoaML – it spans the entire service life cycle; we would be the first to say, the leaf node detail is not necessarily fully consistent and detailed, but that’s the intent, whereas SoaML is focused purely on the service modeling domain. Second the SAE Profile supports the SAE methodology.
For end users the question is how these various standards should be used. The conceptual models (OASIS-RM and the Open Group Ontology) are useful in providing conceptual consistency. But they do not provide the necessary detail that informs repository and deliverable design. In contrast the SAE meta model and UML Profile are being widely used to define asset schemas and deliverables, and the SoaML will of course be used by tool vendors to develop same.
We are currently engaged in a detailed assessment of the SoaML and SAE profile and anticipate we will report in February. Following this we will canvas our Forum members’ opinion on the level of convergence that is desirable.
To summarize, it seems to us that higher level conceptual standards have their place while the industry is learning. But as the industry and its customers demand production strength support, the requirement is for standards that guide deliverable creation and tooling. This has been the objective guiding CBDI work for some years, and while we see some merit in alignment with the higher level conceptual models, we believe alignment with SoaML is a priority because of its comparable rigour. The levels of inconsistency observed in the purely conceptual models will be extremely difficult to resolve at that level. For that reason we believe the standards will evolve from the CBDI SAE and OMG SoaML models because they are at the level users will require.
The CBDI models are organized into packages because the breadth of SOA clearly indicates multiple domains. It seems likely that standards will evolve at different rates in each of the domains. Alignment around SoaML is clearly going to happen in the Modeling domain. We envisage a plug and play approach where different standards bodies will develop strengths in different domains. In this process CBDI will continue to influence events and to provide a detailed Business Type Model “view” that helps real users make sense of it all.
Finally, we can all see the Web services standards were hugely successful because IBM and Microsoft drove the process. Similarly today we note IBM is a big supporter of the OMG, and specifically SoaML, and significantly Microsoft joined the OMG last September.
-This discussion is focused on SOA Concept standards. I will return to the topic of framework standards in due course.
-The comparison report between SoaML and SAE is planned for the February CBDI Journal.
Every year CBDI attempts to make an assessment of where we are at, and the key drivers for our next years R & D program. Last year (2008) we identified “make it real” as a theme, and in many respects we have delivered on this. Clearly the major achievement this year has been the huge advance in the CBDI Knowledgebase. With Release 2.0 now launched we now have a body of guidance that is now getting used in earnest by early adopters and ready for widespread usage. In addition the tooling and profile work we did earlier in the year, plus detailed modeling and a strong emphasis on practices. More recently we have been focused on addressing “real world” topics which has spawned M&A, Multi-channel, etc.
Looking forward to 2009 the macroeconomic situation is of great concern, but my reading is that SOA is moving out of the hype phase which has been characterized by tactical application to becoming business as usual (BAU). Larger enterprises, governments and consultancies are now acting to put in place high quality, repeatable practices. So while the credit crunch will have a temporary effect by reducing overall demand, there is evident and increasing demand for methods and guidance in the area of quality, repeatability and productivity.
For CBDI research I see five primary areas of demand for our R & D:
Productivity, cost reduction, business value. – Survival in recessionary times. Focus on key cost and headcount reduction strategies including Testing, Offshore and Outsourcing, Managed Services. Estimation. M&A.
SOA as Business as Usual. We have already started articulating this message, but in 2009 we need to make a major transition where we go beyond SOA to BAU. For example:- develop resources such as templates to the next level of detail (XML schema).- work with industry providers to create tool specific reference implementations- refine service specification and other deliverables by life cycle stage - export task lists to Project Management tools- reference architectures for technology platforms (e.g SCA)
Standardization. CBDI has blazed a trail where others are following. Our meta model and profile, SOA process and life cycle have been widely adopted, cloned and copied. We have donated our core concepts and models to various groups including the OMG, HL7 and TM Forum. We have also participated in the OMG’s UPMS. In 2009 we will look to influence more rigorous concept models and align our work with emerging standards. We will look to integrate or align with de facto Project Management approaches, ITIL, and other frameworks (possibly TOGAF as it matures).
Better Business Model. CBDI believe that de facto business modeling and requirements approaches are woefully inadequate for purpose. Lots of the individual components (techniques, languages etc) are fine for a narrow purpose, but they are all predicated on yesterday’s world in which we abstracted away from the real business problem in order to make realization with the limitations imposed by technology. Today many of these technology limitations are removed, yet we still draw line and box diagrams, and never give a thought about a richer conceptual model that underpins a loose coupled world that is in constant evolution.
Evolving SOA Architecture for Cloud, SaaS, IaaS and Virtualization. SOA architecture is an integral component of the emerging technology environment. There is a need to move our reference framework forward to provide initially, the conceptual Framework for SOA in these emerging domains.