I have the utmost respect for our CTO of Enterprise Web Services,
John Crupi. He is a great guy and one of our sharpest arrows. If you
get a chance to hear him speak, you will enjoy the time and take away
valuable insights. John recently joined the BSC community
(blogs.sun.com) and posted a brief intro to SOA. Welcome John! I look forward to future updates on this topic on your blog.
Me, I'm a Lead Architect with a background built on consulting and
systems engineering primarily at the IT
Infrastructure level, focused on most of the solution stack - up to
but not generally into the functional business logic or S/W app
design space. Prior to Sun I spent years as a programmer translating
business requirements into S/W solutions... but that's been a while.
With that context (the fact that I come to the table with certain
biases and experiences that color my perceptions, and I suspect John
does as well, to some degree) I'm going to suggest that maybe John is slightly off-base w.r.t. his premise about SOA
and IT / Business Unit (BU) alignment. In the spirit of extracting
deeper insights and clarifying positions, I'm going to challenge John
with an alternate view (a debate), and ask him to either agree with me
or defend his position. Hmmm...is this a Career Limiting Move
- publicly challenging one of our Chief Technology Officers? No... not
at Sun. We encourage our folks to question assumptions and even our
leaders, resolve/align, and then move forward in unity. Okay, with that:
John, you suggest that: one of the critical success factors for SOA is a tighter relationship/alignment between Business Units and IT. In fact you say we can not even do SOA without effort on the part of the Business Unit.
Now I could not agree more that Business/IT alignment is absolutely
paramount. The lack of business focus and alignment is one of the
top reasons why so many IT initiatives fail to deliver or meet
expectations or provide a higher return to the business than its cost.
I've blogged about that very topic.
However, that alignment, IMHO, is not related to SOA. In fact, I believe there
are benefits to isolating service construction techniques from the
consumers and owners of those services. To reuse the power utility metaphor:
You don't care how S&L built
the power plants that deliver your electric service, or how
power distribution provisioning logic taps into multiple grid suppliers
and peak-load gas turbines. You simply have specific service level and
financial demands, and expect a quality experience when/if you have to
interact with the service desk to resolve a dispute, request a change
in your service, or report an incident.
There are two primary components to IT... the design/development of services, and the opertaion/delivery of services.
"Business - IT Development" alignment
is driven by business requirements (functional, service level, cost,
time-to-market, etc). SOA isn't a "requirement", but a technique that
helps IT achieve the desires of the business to support their business
"Business/IT Operations" alignment is properly performed as
defined by ITSM/ITIL Best Practices, and as illustrated in my graphic
below. Business and IT need to work as a intimate partnership to
define, implement, deliver, and continually refine an
optimized Service Portfolio at contracted service levels and an
established and predictable cost point. Again, SOA is simply a technique that helps IT achieve operational excellence.
All other functions are internal to IT. The fact that requirements are fleshed out in an Agile fashion and
constructed/deployed using a SOA strategy is meaningless to the
Business Unit. They simply want IT to build the capability they need,
adjust it when asked, and deliver it as expected.
As a consumer and purchaser
of various utilities (electricity, gas, cable, phone, water, etc) you
don't need nor want to know the details of how the utility achieves
scale economy or service resiliency or security or
efficiency/utilization or adaptability or regulatory compliance. Well,
okay, you and I by nature might be curious and like to know how these
things work. But, in general, exposing the internal details of how a
Service Delivery Platform is constructed is,
IMHO, counter-productive to the Business/IT conversation and
partnership. Some curious BU stakeholders will likely want to
understand and even attempt to influence your model (eg: buy EMC, use
.NET, etc). But that kind of inquiry can expose dysfunction and
introduce inefficiency in the model. You don't tell Pacific Power to
buy GE turbines or supply power at 62 hertz, unless you want to pay
extraordinary fees for your own custom power plant.
I strongly believe in the principles of Agile development and
architecture. Clearly the days of throwing a fixed requirements
document over the wall are over. Business Units, IT Operations, and IT
Development all must work together in a healthy partnership focused on
continuous business process optimization and refinement. However, in my
opinion, the true value of SOA is in the benefits it delivers to the internal
IT function w.r.t. scale economy, resiliency, efficiency, adaptability,
etc. Business Units don't need nor want to know about SOA... they
simply have (frequently changing) requirements and expectations.
Bottom line: SOA is a architectural style/technique that IT Shops
will employ to quickly respond to changing service level demands, while
operating IT as an efficient adaptable business with an ability to tap
into (integrate with) external/outsourced partners (blog on Coase's Law).
John - I respectfully invite a reply.