Thursday 15 October 2009

More on the SOA Manifesto

I have been thinking ever more about the SOA Manifesto. In part fuelled by the proximity of the WG meeting and in part by comments that have been made.

I take on board the comments on the need for "boldness" I have never been shy about dealing with that. But we need to ensure that the manifesto has use today that is practical and very business focused - something I have picked up from the many comments made at infoQ. And we need to map out what is missing and look deeper into a brave new world that builds upon our current available SOA platforms and methods of constructing solutions.

One thing stands out for me on the practical usage side and one on the future.

On the practical side:
  • The use of Service Orientation is underpinned by delivering continuous business value. Business value MUST always be aligned to business goals and needs.

In the future:
  • It MUST be possible to express the information model(s), the static service model and the dynamic model of service collaboration such that the first describes the data needs of services, the second describes the service usage across peers of a specific service and the third describes the common collaborative behavior of peers collectively. All of which MUST be founded upon one or more business requirements.
I think these two and refinements of them will stand us in good stead. The devil is always in the detail.

The former is really motherhood and apple pie. Easy to say but how do we bake it?

The latter is more of challenge because it requires a better understanding of what underpins a distributed system in terms of behavior and information that drives that behavior and these, at the end of the day, are complex mathematical topics. We must be careful and ensure that we do not go into too much detail but provide the right syntactic sugar that allows formalism to deliver to us in a way that we can all understand and use.

Let us not forget that without mathematics we would have no computing. In fact without it we would have no engineering. They are all based on mathematics but we rarely see the models that are used to underpin engineering but in the case of computing we use those models all the time. They have syntactic sugar we call them programming languages.

1 comment:

Integral ):( Reporting said...

Steve:

Boldness does not always rhymes with useless. Today, in the SOA context, Boldness is really about looking at what has been built and the little bit that might be missing and explain to people how to use it. This is where the value to the business resides.

I see every day that the concepts of SOA never made it to IT. The pundits, the analysts and the vendors have failed to deliver the knowledge to make IT successful. Please consider the SOA manifesto as a way to fix this.

The first principle, IMHO, has to deal with Forwards Compatible Versioning Schemes. How can you bring agility to the enterprise without it? SOA and Web Services were invented to that, because every other middleware before was too brittle. And what have we done? we baked in the brittleness into SOA. Every IT asset MUST be designed to evolve (to a certain degree) without impacting IT assets that consume/rely on it.

If you build something that is not designed to be forwards compatible, you have just poured a bit more concrete in your IT organization.

Your comment on math is interesting. I would actually that Math is nothing more than modeling. Each time I need to understand a math paper (I am too old to remember the content of the 16 hours/week math classes I had to do in France) I actually create a UML model. I even started to teach this to my children. So ultimately, all that SOA needs is a comprehensive (programming) model.

Good luck !