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.
Subscribe to:
Post Comments (Atom)
1 comment:
This approach is novel and in my opinion is a critical component of Web 2.0 as architecture. CDL enables the business stake holder, the business analyst, the enterprise architect and the application engineer to share their views of the same system in a synchronised fashion, by providing the means for each level of detail for each stake holder to be captured without that detail being necessarily exposed to the others. Also CDL provides the necessary provenance to enforce requirements at each level.
In this fashion, CDL also enables the A in SOA, since it provides the manner in which architecture can be modelled, described and implemented. This is quite important to other methodology stakeholders - the ones who do not necessarily want to see the inner workings of the architecture yet need to be assured that certain rules will be applied. CDL makes the provenance of such rules and their usage possible.
I look forward verily to your next post on this topic - this most relevant to anyone involved with Web 2.0 and SOA.
Post a Comment