Dec 16, 2008

To SOA or Not to SOA

A major utility customer called and requested to meet with a SOA expert. I was called to meet with the customer and determine what they needed.

The customer's fancy new headquarters is an architectural masterpiece. Pleasant and interestng to look at on the outside, neat "smart building" features on the inside.

On entering the meeting, the customer team got right to the point, "We aren't doing SOA and want to know if we should be." They explained they had a high reliability requirement and an existing high reliability environment. Taking it a step further, they have an OLD high reliabilty environment... majority IBM mainframe, MQ for messaging between apps when they're not on the same environment.

I explained the advantages and goals of SOA, such as:

- Ease Integration
- Flexibility
- Enable Real Time Processing
- Enable Real Time Data Accessibility
- Reuse
--- Single Service Instance
--- Single Installation
--- Single “System” for Single Business Function
- SOA Nirvana:
--- Application Assembly
--- Wide Ranging BPM

Or in an elevator pitch, Build it Fast, Change it Easily, Build it Once, Install it Once, Adjust as Needed.

I explained the SOA big picture is an IT mentality change much like the move from procedural programming to object oriented programming. A different model of thinkng about how to build business functions into applications (if the word application even has meaning in the full SOA context). At which point they stopped me...

"We still do procedural programming." Ok, I responded, everyone still has plenty of legacy code they are supporting and the major challenge of SOA is how to integrate the new pattern into large existing IT environments without being overly disruptive (yet still getting the value proposition).

"No, we develop our NEW applications using procedural programming. We know it well, it meets our reliability requirements, we're happy with it and see no reason to move to object oriented development or newer methodologies."

Did I mention the customer was a public utility?

Speed of development or integration was not an issue. Needing double or triple the effort (or 10x) to create a project was not an issue. Project cost was not an issue. Speed to market, no, flexibility, no. Their only business driver is reliablity and stability, and their IT managers were rewarded or penalized on that basis.

They got what they wanted from that meeting, information that SOA requires significant change and carries risk. They don't do risk and won't be doing SOA.