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.
