« What do you call Smirnoff Ice, Skyy Blue and Mike's Hard Lemonade? | Main | My first press quote »

February 20, 2007

Building a business as an SOA

I was at a trade show about SOA on Wall Street the other day. There were a large number of vendors, belonging to various parts of the SOA 'ecosystem', exhibiting. The high degree of differentiation I saw in their offerings (ESBs, SOA testing, SOA acceleration, SOA/RIA etc.) convinced me that SOA concepts have finally become thoroughly mainstream.

I remember hearing what later became the SOA mantra for the first time perhaps 5 years ago, around when XML Web services on Microsoft .NET came out. I don't particularly care to go into the benefits of SOA in great detail in this post. The one sentence summary though is that a service-oriented architecture, built from a bag of loosely-coupled, interoperating services that can be composed together leads to higher flexibility and agility (both good things) in a business because the knowledge needed to answer business questions is all in services that can talk to each other instead of being locked up in siloed business units that don't. I started to wonder though--how would it be if, instead of being merely a technical implementation consideration in a business, an SOA lay at the core of the business itself?

I am a strong believer in the software engineering maxim that software written by any company carries the footprint of the organizational structure of the company. A recurring theme I saw in the experience of the many banks represented at the show was the difficulty of grafting an SOA onto an already functioning business. Apparently, finding the right SOA vendor is relatively easy. But transforming internal business processes so that business logic is separated out into independent service units is much harder. If the many high-stakes technology end users on Wall St are serious about reaping the benefits of SOA, they should construct their businesses as an SOA and let that leave its organizational imprint on their technology stacks. How might they go about doing this?

  1. Everyone in a managerial role, all the way down to the lowest rung, defines say five business questions that they and their reports can answer. They might be long questions, possibly involving scenarios or set-ups, but they must NOT be open-ended questions. Examples could be, "How many accounts does Fidelity Investments hold with us?", or "What will the budget be for the upcoming financial year?"
  2. Enter these questions into one company wide, searchable full-text database. This database will make it really easy to find which manager is responsible for a given business question. Knowledge will no longer be locked up in silos, because instead of reimplementing some business functionality in your own group's software, you can reuse such knowledge from someone else.
  3. Work with technologists to develop services that answer these business questions.
  4. ???
  5. Profit

Essentially, this database would be the plain-English, business equivalent of a service registry. Software requirements should always flow from the business questions expressed in this central database, which should be the authoritative source. The ??? in step 4 above, aside from being a throwback to the old Slashdot chestnut, is actually intended seriously. There are a number of unknowns to be taken into account: what if I need a valuation algorithm, but I don't like the depreciation and cash flow methods that Bob from accounting uses? What if Jane from payroll doesn't give me answers in the way I like? To a lot of these questions, I don't necessarily know the answer. I do believe though that this scheme could work as more than just a thought experiment. Any thoughts from my readers?

Posted by Vishy at February 20, 2007 08:21 PM

Comments

I will continue to visit enjoyed the reading thanks

Posted by: Alena at March 8, 2007 06:26 AM