SOA for the Right Reasons

I've just recently returned from a set of engagements in Sydney and Brisbane. The Australian National e-Health Transition Authority (http://www.nehta.gov.au) has recently published a set of papers indicating a national direction toward service-oriented architecture as their to-be architectural direction. NeHTA is responsible for connecting state healthcare systems together so as to provide seemless e-Health across the whole of Australia. I was asked to participate in a set of conferences to help stimulate the dialogue about the topic of SOA in Healthcare.

Prominent from the set of discussions (not with NeHTA, but with representatives from vendors, providers, universities, and so on) were a lot of technical questions about SOA: tooling, middleware, architecture, and so on, but not as many about the rationale behind why SOA would or would not make sense.

The selection of a service-oriented architecture must be made for (what I'll call) the right reasons. SOA needs to help address business challenges, or it may not be the right target platform. So, what are the right reasons?

1) Establish authoritative responsibility sources within an organization or enterprise. Large organizations often have multiple different systems, some of which overlap in responsibility. In these cases, it is difficult to know "which system is right", especially if data conflicts between systems that house the same information. Establishing authoritative services solves this business challenge.

2) Address unplanned redundancy. Redundancy itself is not bad. In fact, redundancy is a very good answer/approach to improve system response time, support distributed continuity-of-operations, and so on. The unplanned redundancy is problemmatic though. It means that multiple systems are performing the same function. That means that multiple teams are supporting these systems, and that monies are being wasted. Worse still, it is likely that each different team does things a little differently, meaning that business rules are inconsistently enforced and ultimately problemmatic for the organization.

3) Faciliate technology migration. Heathcare IT systems are often deployed for a very long time, significantly outliving the technologies upon which they are architected and designed. There is a significant need to be able to adopt and embrace new and emerging technologies as they evolve, bringing them into the fabric of the enterprise as they mature and add business value. SOA promotes this integration, since one can "wrap" the new capability as a service, and provide an interface in whatever the protocol de jour happens to be.

You'll notice that in the examples above, there is no mention of whiz-bang tooling, leading-edge technology, or of reuse (per se). Although tooling and reuse are real benefits to SOA, I find them much less compelling than the business reasons. Re-use is not a winning arguement as the basis for migration to SOA. Improving mission-crtitical data quality is. The fact that we can also reap reuse benefits is icing on the cake.

SOA is not a silver bullet, and it must be selected as a target architecture for the right reasons. SOA offers some wonderful advantages, both functionally and technically. That said, if the rationale for your interest in SOA isn't well grounded in your business challenges, you may be looking in the wrong place.