SOA, a Business Facilitator
This might sound shocking coming from a CTO, but SOA isn’t about technology, it’s about facilitating business. Of course all of IT could be viewed that way. I go deep into SOA projects in financial institutions on a regular basis and I find many of them initiated and driven out of IT, but with little initiative, support, even awareness from the business of SOA. Most of the time it boils down to mere education, but whatever the case if an SOA project is purely IT, there will likely be a struggle.
I see metrics reported like “components reused” (don’t get me wrong, that’s a good metric, I report on that metric for SunGard internally as well) but there needs to be business context around it in order for the business to comprehend the value (for example, I include revenue generated, projected, etc. for each component, as well as some subjective attributes like revenue that wouldn’t have otherwise happened without SOA).
Last week I was with a customer whose SOA project is in trouble. My interpretation of their situation is very simple… IT has little to no involvement from the business in their SOA effort. They took the approach that the SOA “technology” could be inserted at a layer beneath what the business sees (i.e. the apps and functionality mapped to the business doesn’t change, and the SOA is inserted beneath, abstracted away). Requirements are written almost exclusively by system analysts and no benefits were exposed to the business. The project started failing when the business noticed service interruptions and other unexpected problems. That’s completely the wrong way to go about it.
I routinely state that the process is more important than the technology, and here I’m throwing business direction, support and even leadership into that category as well. The successful SOA’s have a core team working in a federated way with each business lead and their teams in an organized and collaborative manner, taking direction from the business and exposing value “chunks” little-by-little along the way.
December 5th, 2007 at 1:32 pm
Darren,
I can’t agree more. I’ve had similar experiences when working with financial service firms. One of the problems seems to be that everyone is used to having different applications doing different things, with data duplication, and application redundancy, and the organization has adapted to life as a “data bucket brigade”, fetching buckets of data (typically Excel spreadsheets) from one application, and then bringing them to the next one.
Operational processes have “hardened” around this way of doing business, and it’s difficult to get both the operations management, and their underlying personnel to see a different way of doing things. There has to be a means for getting everybody’s head up out of the computer screens, and clearly identify how the business is going to flow, before IT ever really gets involved. IT is the cart, the business process is the horse.
It _has_ to start with the business process, but somebody has to lead folks into believing that the technical people can get the applications (via SOA) to “talk amongst themselves”, once the true business processes have been clearly identified. It’s almost more of a people, culture problem then a technical one. The technology part is easy. It’s getting the folks to work as a unit (instead of independent silos) that’s hard.
Charlie Peppler
May 3rd, 2008 at 7:02 am
[…] Given that, it’s important to realize that the business domain (top-down) needs to weigh in heavier in the mix, at least as it relates to the prioritization of the SOA activities across the board (see my blog entry from last year here regarding the importance of a business focus on SOA). This fosters the energy required to accelerate the flexibility benefits early on. Meaningful reuse takes time anyway, in fact those that realize that sooner rather than later end up less trodden down by missed expectations. In a delicate balance, developers and architects need to deal with the shared architectures and components that both follow those priorities as well as deal with the lower-level technical aspects the business domain doesn’t need to engage in (stuff like which message caching approach to use, which object-relational mapping to adopt, what debugger to leverage, or which API to chose for a particular task, etc). […]