SOA: Debating our CTO
By dcb on Mar 13, 2005
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.