SOA is Definitely *Not* About the Technology

There were a few threads about whether SOA is about the technology or not.

In my opinion, SOA and architecture in general are never about the technology -- technology is important but it is just one variable in the equation. What we are looking for is a way to satisfy as many of the business needs as we can under all the constraints we face.

For instance, a few days ago I got a question in my email box from someone calling himself "coldplay". While I don't think the band has somehow got interested in event-driven architecture, the question itself looked interesting enough. Here is the situation:

Current Setup Let's take a e.g of a Inventory Stock Reorder point exception with in heterogeneous apps environment (No-SOA and integrations)...

The exception definition was built into the source apps and when the stock dropped below reorder....event registered and led to a exception. Exception was further handled by a rules based engine and a workflow
notification raised ...

Planned Setup
Same e.g as above ... Post SOA implementation.. Inventory management is composite service built by orchestrating collaborative services from SAP and Oracle...which have different data model supporting them...

The exception definition requires to be defined outside the native Oracle apps and might have to get some event related information from SAP web service also ... to arrive to a conclusion as to whether this really is
an exception or not ...

Possible Technical approaches:

• Data Persists somewhere in the processing the exception.
  
• Data doesn't persist
  
• In mem database used...
  

My question now:
1. What do you advise to be used in EDA? which would reduce network round trips, decrease apps server loads from the above 3 technical outlooks.
2. What is diff between in-mem db and usual processing of apps logic by an apps server.

I feel:

• Data persistence would lead to larger commit times and reduce operational efficiency
  
• If the data doesnt persist... and all validations are executed on the fly... don't you think the current apps servers would die processing ... or if its processing capacity is increased .. is it going to be
  economically viable alternative.
  

To be quite honest I can't really answer the questioned asked because the question lacks the business context -- what are the implications if events are missed or lost? What's the acceptable latency that would allow the business to operate properly ? If the Oracle bits and SAP bits need a lot of data from each other, then maybe the whole service partitioning is wrong and the services are not cohesive enough? How many business events are expected anyway? How often? and the list goes on.

Once you answer the business questions you can look at the available technology portfolio and ask whether you would want a in-memory database or maybe a datagrid would be a better option? and even then
the decision is not just technology driven since when you do cost/benefit analysis you need to take into account purchasing costs, operational costs, skillset of the dev team, time to implementation etc.

This is not to say that if you choose a technology that isn't aligned with your architecture you should reconsider the architecture (or technology). Also since each technology product brings into the table
its own architecture (with its own constraints and decisions) you probably need to verify the architecture once you make technology choices. but still, at the end of the day it is the business needs that sits in the driver sit, the rest is just tagging along for the ride.

Edit 09/27: in case you are wondering, I am not the only one who thinks this. for instance, I would urge you to also check out Sam Gentile's post SOA it's the business stupid and Steve Jones's SOA is a change programme, not just technology

Posted by Arnon Rotem-Gal-Oz at 04:48 PM  Permalink