So what I'm thinking is it time to bring clarity to all of this and admit that the techies and vendors have "won" the battle for the SOA name? Time to give up on the SOA name as something that has been co-opted purely to the technology and which is sometimes more focused on selling products than on delivering solutions?
My proposal is that we should start being clear when we mean business SOA by calling it a Business Service Architecture. The goal is to clearly differentiate business SOA from technical SOA and help move the debate on from the current technology centric debate towards one that is about changing how IT works to make it focused more on business solutions than technical implementations.
Business Service Architecture - Business problems solved, no matter what the technology.
Technorati Tags: SOA, Service Architecture
4 comments:
Sounds like you're finally sucumbbing to the (enterprise architecture) Dark side... ;-)
1. There is no such thing as BUSINESS LEVEL SOA.
2. There is a BUSINESS COMPONENT ARCHITECTURE on an enterprise and LOB level.
3. services are abstractions composing a business component.
4. services emmit business event which create a set of business effect which engage other business components(ie services)
5. business strategy is expresed in a cohirent business component architecture.
6. rest/pox or ws* are implementation options for the business strategy
7. rest is by far a domain friendly and tco effitiant option.
Yo
A great set of seven points there, only let down by a lack of definition on any of the terms used. I assume by Business Component you are talking about IBM's Business Component Model. In three you are saying that a service composes (I assume therefore consumers, therefore is higher level) components... meaning that clearly there are business services.
On points 6 and 7, the first implementation point is IT, which then can be implemented using REST/POX/WS*/CORBA/ERP etc, it isn't really true to say that Business Strategy is then directly implemented by technology as there is pretty much always people/process/IT combined to deliver against a piece of business strategy.
On 7 as well its a good statement but unfortunately not backed up by actual facts (e.g. REST v ERP for core manufacturing or Finance).
Nice post, Steve. Kudos. Is this any more useful? http://wanderingbarque.com/nonintersecting/2007/10/08/towards-a-better-network-programming-taxonomy/
-- Pete
Post a Comment