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.
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.
Hello Steve.
ReplyDeleteFirst, a comment about this post.
In the practical side, not only Service Orientation but any actual decision in the architecture should be driven to achieve business value. In here I try to explain something similar, just I call it Stakeholder needs.
So, that sounds to me as something a little obvious. But actually, you are right that the contrary is not the common case.
About the second one, you mention distributed system. I usually keep away from distributed system concept when talking about services, since those are not good for distribution in my mind. Actually, I think they are good for integration, but there is one concept that fills even better: Collaborative systems.
It may not be obvious, but all three are different concepts. A system following the service metaphor will tend to be collaborative, and that means services are require to be "composable".
Now, from the InfoQ comments I suggested feedback on the manifesto. Well, I wrote a post with my two cents on definitions. Here I share, hope you agree with it.