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.
Wednesday, 5 December 2007
Tuesday, 27 November 2007
Another CDL tool suite is born
At last, Christmas has come early. Congratulations to Hongbing Wang and his team in China. A new WS-CDL tools suite is born and we at Pi4 Tech are no longer out on our own.
I feel every more sure that others will join the fray.
http://wscomposition.seu.edu.cn/index.html
I feel every more sure that others will join the fray.
http://wscomposition.seu.edu.cn/index.html
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.
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.
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.
Subscribe to:
Posts (Atom)