Saturday 20 October 2007

WS-CDL: It's all about methodologies

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.

Observations on Software Architecture

The term Service Oriented Architecture has been in vogue over recent years. There is a vague notion of what we may mean by a service, namely some software component that offers some business functionality as a service to one or more clients. There is some understanding of the term Oriented as being a system that is in the vein of. But the term Architecture is one that seems to be less understood.

If you ask 10 people what is meant by Architecture as it applies to the term SOA you will probably get 10 different answers and none of them will be precise. And yet if you ask the same 10 people what does Architecture mean when it is applied to buildings you are likely to get similar responses from all of them and in the main they will be precise enough to test.

So what is Architecture as applied to buildings. One way of explaining this is to understand what an Architect does and more specifically what do they deliver? What tangible artifact do they produce? They produce one or more drawings which outline a building. These plans show how the building will look and give some guidance as to the materials that will be needed in order to achieve that look. Sometimes the materials are chosen to achieve some style and sometimes they are load baring and so meet some mathematically calculated requirements. So an architecture in this sense is a something that is used to guide the construction of a building. The Architect may police the construction every day or may simply come and inspect at the end. In either situation the Architect is visually inspecting the building for conformance to the described architecture or indeed auditing the materials used to ensure that the mathematically calculated requirements have been met.

Where is the A in SOA? What can we use to help us build complex systems of services and is there anything we can do to inspect what is delivered against an architectural description?

There is something we can do to help. WS-CDL as a blueprint for software architectures is a start. What is needed in a addition is process or a methodology.

That I shall leave to another post.