So what's the big deal with making the business unit so prominent when talking about SOA. It's not about being one big happy family. It's about the organizational structure which needs to support what we really want to do; have business drive the requirements for SOA. That's what we mean when we say SOA is a business-driven architecture, not a IT driven architecture. If the business unit and the IT team don't work together to achieve a SOA, you will be very hard pressed to get the requirements necessary to drive the proper service granularity and process definitions.
What does this really mean? It means that for SOA to be successful, it must be a "top-down" approach. And top-down, means problem to architecture to solution. It does not mean, working from what we have and just wrapping it with new technologies just because we can. This bottom-up approach is quite natural and easy and is the perfect recipe for a SOA failure.
This isn't just me thinking aloud. This is based on many discussions with customers citing why their initial attempts to use webservices and create SOA solutions failed. Many of our customers cite the "just wrap it in a web service" approach as a simple and natural way to create a the SOA service layer. So simple (from a tools perspective), and natural (wrap what's there), they thought it was worth a try. The problem, is taking an existing asset/system and making it a web service is a completely bottom-up approach and creates an immediate mismatch between the new web service interaction style and the existing system. More about this in future blogs.,,
Below is a page from one of my presentations to help visualize these thoughts.
</BR> When introducing something like SOA, the bottom up approach was chosen because it was the least disruptive option. So to do a top-down approach you might get the business units and IT to nod their heads "yes" for the plan, however, when it becomes disruptive yes becomes no, and nothing actually gets done, unless the plan is coming from the top.</BR> </BR> Granted, that business operational vision should be coming from the senior executive management team, and the enterprise architecture should reflect the business plan, however, business operations just like IT tend to have their heads down in day-to-day fire fighting and never time to create an "actionable" strategic business operations plan. </BR> </BR> So when you say start with the business, it has to be at the very top. The CXO and Executive Senior VPs have to agree this is what my business wants to achieve, here is a strategic and tactical business operation plans from the business side. The CIO must partner with his executive peers to develop a technical service plan that is an enabler to the business objectives. I'm sure you are saying "Yes, yes, we have all heard this rhetoric before...</BR> </BR> What seems to be missing is neither can be created in a silo. The business executives have to be educated on what is possible and what the technical enablers "really" are, they need that background to effectively make business plans. Why...because technology and the use of it brings to the table possibilities that were 100% unthinkable 20 years ago, even 10 years ago. </BR> </BR> So it may seem like it all starts with the business, however, IT has to be there in front as well, because in reality it starts with both, otherwise we are all just chasing our tails. </BR> </BR> Cheers, </BR></BR> Tom
Posted by Tom Rose on mars 22, 2005 at 10:10 MD EST #
Posted by Rikard Thulin on mars 23, 2005 at 05:12 PD EST #
Posted by Tom Rose on mars 23, 2005 at 08:47 PD EST #
As I have written before, successful systems *enhance* business processes. In cases where bottom-up has worked, the underlying system was already modelling a business process, instead of the inverse. They were merely changing an implementation detail (adding a layer or some interface) to a well-defined "system".
Crupi rocks. :)
bill.
Posted by bill walker on prill 08, 2005 at 09:56 PD EDT #
Posted by Thinking Out Loud: Thought Leadership from an Enterprise Architect on maj 14, 2005 at 06:30 PD EDT #