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.