Service-Oriented Architecture

Some of my key observations from the experience,

• As you might see from the outset, for someone unaccustomed to working with the IBM stack, it has a rather “elaborate” feel to it. At a high level it seems that modularity offered by providing layer-wise components is useful, but the associated complexity is a bit harder to digest.  IBM likely has a sound basis for configuring stack in this way. Possibly better suited to problems and projects of huge scale, where you can afford to dedicate teams to a particular application layer.  But, far more often development happens with small teams, and individual developers spanning the all layers of a development. Burdening then with 7 tools to manage their end to end isn’t a Project Manager’s productivity tip.
  

• The core Process server, ESB and App server is basically a Russian doll configuration of one tool built over the other.  But if you have to acquire BPM and ESB capability it seems that you have to buy each one separately.  Is it not possible for Websphere to be sold as a Core + Plugin configuration?  e.g.  1) Websphere standalone, 2) Websphere with ESB plug-in and 3) Websphere with ESB and Process Server plugins. Is it, that if it is done this way, clients will not need to buy all the three and then not need to buy some more hardware to stack them on top of each other? May be I am being too harsh, but my argument is that if I need a car with a sat-nav I don’t go a buy a new car; I buy a sat-nav. My feel of looking at the 3 products was that they all share a common framework and can possibly be bundled up as one.
  

In fact a question had been asked that Process server and ESB appear to be very similar products to the point of BPM looking like a rebadged version of ESB, so what is the distinction? One of the main answers was that Process Server should be used for Stateful orchestrations and ESB for stateless orchestrations. Well, is it then left to the user to define a distinction for himself while having paid extra licensing costs for each layer of the stack?

• Thirdly, is it not possible for business fabric, business monitor and business space functions to be woven into the business process server itself? Not just tool integration but inclusive in process server license as well.
  

Depending upon initial build requirements of a project one may may need a variable set of tools to start with from this list, chances are as requirements grow in complexity remaining ones will be needed as well.

In enterprise architecture, tools are enablers of implementation. When tools become too complex, the effort in adapting to the tools distracts from the core architecture itself and increases cost to business.

In meeting this premise better, I feel IBM  SOA stack needs to be configured or packaged in a way that makes it feel light, more integrated, easy to adapt to and cost effective.