Towards a methodology for SOA

I did say I would blog further on methodologies and WS-CDL and how they tie up.

I remember a while back being at SWIFT in Brussels and we (the SWIFT guys and myself) were talking about their use of UML tools which are the back bone of both their standards work and their implementation work. They are possibly unique and certainly very rare in that they truely use a methodology to derive applications (and I do mean derive). In conversation I said "it is the methodology first and the tooling to support it that is second". An obvious statement to many but certainly not all. The SWIFT guys certainly get it and practice it to great effect. I know some architects that do it (Matthew Rawlings first among them) but I know many more that do not. I try and I suppose doing the work I do does enable me to create tools to support methodologies and this is what we are doing at the Foundation - creating tools to support the creating of applications from requirements gathering to operations. Enough said .... here is a start.

A methodology is a set of measurable and repeatable steps by which some objective can be met. In the case of software systems this needs to reflect an understanding of the roles that are played out by people in the delivery of a system. A methodology needs to take into account all of the artefacts that are delivered by each role and ensure that each step is measurable so that it maybe said that a software system does what it is supposed to do, that is, it meets the requirements.

The roles that are played out in the delivery of a software system start at the business stake-holder and involve business analysts, architects, implementers, project managers and operations managers. These roles are a reflection of tried and tested methodologies that are used in construction projects. In a construction project there is also a business stake-holder, namely the person or persons that expressed a need. There is also an architect who captures those needs and writes them down as a set of drawings, there are structural engineers who add derived requirements for load bearing issues, there are builders who construct, there are project managers who manage the construction and report to the business stake-holders and there are the people who maintain the construction day to day. The roles for a methodology for software construction are analogous The aim being that what is delivered measurably meets the requirements.

The business stake holder and the business analyst work together to document the requirements. The business analysts role is to elicit requirements from the business stake holder and record them in a way that enables the business stake holder to agree to them and the enterprise architect to model them.

The enterprise architect liaises with the business analyst to model the requirements and fashion them into two key artefacts A dynamic model that describes the flow between services or applications and a static model that describes the data requirements that the dynamic model uses.

The technical architect liaises with the enterprise architect (often they are the same person but this is not always the case) to ensure that the technical constraints (e.g. what technologies can be employed, what the expected throughput might be and what the user response times should be) can be met.

The implementers liaise with both the technical and enterprise architects to construct the necessary pieces that make up the system be they services, applications and so on.

The project manager has to manage the way in which all of the roles above meet the requirements agreed with the business stake holders and esure that delivery is on time and on budget.

The operations manager provides further requirements that govern the day to day running of the system and liaises with the business analysts to do this.

What I shall do in the next posting is relate these roles to specific artefacts that can be measured and tested. This is the very essence of tooling support for any methodology. If we can measure it then we can manage it. We can ask questions of it that we cannot ask otherwise and receive answers. So next post I shall dive deeper still and show how it can all hang together and just what WS-CDL as a language for SOA blueprints can really do.