SOA: Debating our CTO

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 ( 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. 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 processes.

"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.


I'm going to side with John Crupi.

The "big deal" of an SOA architecture is to break down the barriers that have kept Business Analysts from being able to implement and updtae business processes. IT should not have to be directly involved in changes to business processes unless the change requires the addition of additional services.

Admittedly, this is an ambitious goal, but I would use the analogy of an Excel spreadsheet. Would it be reasonable to include IT when an Excell power-user needs to change a formula? Of course not.... and our goal for business process software should be the same.

Thanks for thoughtfully questioning "authority"... this helps everybody clarify their understanding (even if I do disagree with your conclusions).

Posted by John Reynolds on March 14, 2005 at 01:59 AM EST #

Thanks John! I hoped this thread would stimulate thought and valuable insights into this topic.

So if I understand you, BUs are going to orchestrate their own IT apps (or at least changes to those apps) to support their changing processes, based on a collection of integratable services available via an ITIL-driven Service Portfolio. SOA helps ensure these "service components" are easily understood and pieced together by non-IT types. Hmmmm. Interesting. That helps explain the exposed touch point for SOA. I was considering the implementation side of SOA.

Posted by Dave Brillhart on March 14, 2005 at 02:31 AM EST #

I have to side with Dave. SOA is an extension of existing ideas. As John points out, the fact that it is technically possible to leverage SOA to make a ubiquitous app where business users can make modifications which will help the app adopt more easily to business process changes is the goal. However, SOA itself is still just a tool to create a solution.

In and of itself, it does not drive the communication of the process, nor should it be used for all problems. Ideally, the process should be exactly for the business to define clearly the problem IT will need to solve. At that point, IT can decide the necessary tools to implement - and hopefully some day that will end up being a tool (or tools) which allows for business users to make modifications which don't allow major code changes (the Excel example). Regardless of top down SOA or bottom up, SOA can be implemented and be vastly successful or a huge failure - and rightly so a lot of that will depend on the communication between the business and the implementors - as well as whether or not IT chose the right tool for the job in the first place.

Posted by Darcy Price on March 19, 2005 at 12:51 PM EST #

Post a Comment:
Comments are closed for this entry.



« July 2016

No bookmarks in folder