SOA means a lot of things to a lot of people. And, now that the money
is flowing to SOA, even more of us are interested. The reality is that
SOA is much more than just a buzzword. It is an architectural style
which tends to be best realized using Web Service and open standards.
It's not the only way to implement SOA, but sure does seem to be the
most popular lately.
We're finding that there are some key "shifts" that have to take place
in an organization to be successful with SOA. Today, I'll talk about
the first of these "SOA Shifts".
- Shift #1 - SOA requires a combined effort between IT and the
Business Unit
The point of this shift is that we cannot do SOA without a mutual
effort between IT and the BU. Gone are the days of throwing the
requirements over the fence and hoping it hits. Not only do these two
groups have to work together, they have distinct roles and
responsibilities. Basically, the BU runs the show and owns the business
drivers, use-cases and processes. IT implements the BU requirements and
owns the service definitions. It's unfortunate that we really do
have to refer to this as a "shift", because we should be doing this
anyway. But, the reality is that IT and BU typical function as
disparate groups and rarely work together to have the business
use-cases drive the process and service definition. More about this
later, but if you get the gist of this shift, I think we can begin the
journey to SOA....
