Posted by Tom Dwyer on Thursday, October 29, 2009 - 14:21
How do you define an SOA from the business perspective? Can you define a tops-down SOA without defining an enterprise business process model and architecture? In addition to a bottoms-up and a tops-down, is there a middle-out approach to defining SOA?
I agree with earlier responses. Although it does provide some value to define services bottom-up the results will be suboptimal. As a consequence, the service layer is seen as inflexible and costly and quickly becomes highly complex. Having a (reference) architecture would definitely help, but a committed and aware organization, clear strategy and governance are also a prerequisite for this. In my opinion, defining services should always start top-down but without diving too much into the details. Then, there will need to be compromises in how to implement them, taking into account the current IT architecture.
Hi Tom I agree with Steven. I think if business is not involved in scoping the SOA effort, the chances that the IT side will create services on a too-low granularity is almost a given. One has to be quite careful in what is deemed as a service because of the higher cost of development. What will also help with the scoping, and helping business to shape their thinking will be a good reference architecture. For example, in the Insurance industry it makes a lot of sense to use IBM's IAA (now donated to Acord) as reference architecture. Having said that, this strategy will also contribute to a higher cost since it requires a longer ramp up time to understand the reference architecture properly. However, services will tend to be a lot more future proof if based on a good model. A good reference architecture should aid in not only defining business services, but technical lower level services as well.
Tom, The title of your post caught my eye. About six years ago I started using the term "business-driven SOA" in presentations. I asked someone in my company if it might be worthwhile to trademark the phrase, and they looked at me as if I was nuts. Anyway to reply to the question you posited...I have always insisted that the business need should be the basis for scoping an SOA effort from the top-down perspective, while the enterprise architecture determines the authoritative sources/destinations for the underlying component technology services and data. I have seen clients take the bottom-up approach and develop hundreds of low-level technology services, not knowing which will actually be required by the business or what form they should take. The top-down approach determines exactly which business services are really needed to solve the problem. Decomposing these into technology services, as guided by the enterprise architecture, helps to keep the work effort focused strictly on business value-add activities. I have a hard time imagining what a middle-out approach would entail. Define a business service and try to find a process it supports?
|
||
|
