The challenge in using CDL is to understand what it describes and how it fits with today’s processes for creating systems. It fits in a simple methodology.
There are four key roles that a methodology has to take account of. The business stake holder, the business analyst, the enterprise architect and the application engineer. The business stake holder is the ultimate user and beneficiary of a system. The business analyst is responsible for gathering the requirements from the business stake holder and passing these on to the enterprise architect. The enterprise architect is responsible for creating a suitable data model that meets the data requirements and a suitable dynamic model that represents the flow of data between systems. The enterprise architect passes these models to the application engineer who uses them to guide the building of applications that meet both the data and flow requirements.
This way of building systems by separating out roles is typical for many organisations. The challenge is to be able to show that the static and dynamic models are a reflection of the requirements and that the applications conform to these models.
The introduction of UML and XMLSchema has enabled enterprise architects to take example messages and create a model that can be expressed as an XML Schema. Coupled with example messages that express data requirements and XML Schema can be validated against those requirements by ensuring that each example message is valid against the XML Schema. Here we have an effective proof that the model meets the requirements and because the proof is automated we can iterate many times between the business stake holder and business analyst and enterprise architect to ensure that we really do have a static data model that meets our data requirements.
The problem remains that we cannot do the same for a dynamic model and the flow requirements. This inability to capture a dynamic model in a neutral way so that it can be used to govern the building of a system is responsible for the lack or interoperability between services and is at the heart of the remit laid down by the World Wide Web Consortium for the Choreography Working Group. It is a gap that WS-CDL fills as an enabling technology.
Next time I shall present the bare bones of such a methodological approach to building systems. The key is to understand where the locus of control resides with respect to the roles that need to be played out. WS-CDL has an impact on all of these roles but none more so than the enterprise architect.