SOA is a Business-Driven Architectural Style

SOA Shift #2 A few days ago, Dave Brillhart commented on my earlier blog on the SOA Shift for aligning IT and the business unit. This is a response/explanation to my thinking...

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.



I agree that top(business) down approach is needed, and what should be defined are business services, not technology or system services. Unfortunately, there has to be an enterprise architecture first that shows SOA is a means to an end, not the end goal itself. The following have been my observations over the last 20 years:</BR></BR> If it does not start at the very top(CXO), you have little chance from an IT perspective to introduce change of any kind into a business unit, weather you understand their day to day problems or not. Why? Because change, no matter how good, is disruptive, therefore has upfront cost. That upfront cost can be avoided by the status quo, so that is what we tend to do.
</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 02:10 MD EST #

Just to make the confusion total, lets rename SOA to BOA, Business Oriented Architecture :-) Another important aspect when looking at things from the top (i.e. as business services) is that the underlying technology is more or less unimportant. Whatever the can realize the business value works, file, ftp, SMTP, Web Services etc. Therefor JBI, which allows this, plays a \*really\* big role for SOA.

Posted by Rikard Thulin on mars 22, 2005 at 09:12 MD EST #

Excellent point about Business Oriented Archtiecture (BOA). I'm a staunch supporter of an enterprise embracing a Business Architecture that then feeds a Technical Architecture...together you have an Enterprise Architecture. SOA is just an approach that is an enabler to the Enterprise Architecture. I have been trying to get executive teams to understand the importance of BOA for a decade, and the message just never comes across in terms they can udnerstand. I like the term BOA!

Posted by Tom Rose on mars 23, 2005 at 12: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. :)


Posted by bill walker on prill 08, 2005 at 02:56 PD EDT #

[Trackback] Several days ago, I blogged about my first meeting with my mentor. During this discussion, he had asked me to think about what attributes am I missing. I not only thought about his question but came up with a revelation...

Posted by Thinking Out Loud: Thought Leadership from an Enterprise Architect on maj 13, 2005 at 11:30 MD EDT #

Post a Comment:
  • HTML Syntax: NOT allowed



« qershor 2016