Sunday 25 October 2009

The SOA Manifesto

Well we did it. We sat down for the best part of 3 days and turned around an SOA Manifesto. I shall blog further, as will my fellow signatories, but for now here are all of the authors blogs to make it easier for you to see what they have to say over and above the SOA Manifesto and of course for you to contribute too.

It is very flattering that the press have used the term "Industry Visionaries" to collectively name us. But we are really no different to many of you practitioners out there. What will make the SOA Manifesto valuable is use and feedback to hone it over time. So take a look comment away and keep us all in the loop. We shall be looking.....

The movie of the announcement is also available.

Cheers

Steve T

In no particular order ....

Anne Thomas Manes
Stefan Tilkov
Dave Chappell
Brian Loesgen
Paul Brown
Mark Little
John deVadoss
Clemens Utschig-Utschig
Joe McKendrick Analyst
Ali Arsanjani


The others I shall add when I have their coordinated.

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.