Vertical SOA Solutions – I

Okay, at this point of time, each one of software vendors and consulting firms is embracing SOA in their product platform to be more politically correct in the process of enterprise strategy formulation and etc. – we have seen this happen from time to time with all types of marketing pitch all over the web.

What would be the essential in terms of getting SOA introduced to various companies in vertical industries? Here comes Vertical SOA Solutions – this is what we are currently building and implementing in healthcare/insurance industry.

First off, to start with the essential backbone of the overall SOA enablement platform – Enterprise Service Bus (ESB). There is quite a bit of hype around both SOA and ESB. Conceptually, ESB is actually one of the major implementation of SOA. As the base platform for SOA, ESB provides the fundamental enterprise messaging backbone, which consists of hub and spoke based message brokers/integration servers or distributed message bus – they are essentially product implementation of JMS specifications plus vendor specific messaging features and enhancements. Features like guaranteed delivery and once and only once, etc., would sound familiar to you at this point. However, having said all of this, that is at a very high level. The overall capability of ESB is to provide a common enterprise service fabric where enterprise level connectivity and message visibility and delivery can be easily facilitated, and enterprise service end points can virtually reside anywhere on this service fabric. One of many misconceptions is to consider a J2EE application server as the ESB platform, including those market leaders. For those with such understanding, thinking outside of the box would be the first step. J2EE itself is a stack of technologies and the application server has limited capabilities to provide enterprise-class messaging functionality. The lack of real-world experiences and skills in traditional EAI/B2Bi could be one of the main contributors to such misconception. Without the overall direction on SOA/ESB, it would pose tremendous risk in terms of SOA application development and implementation at enterprise level.

So far we have, I hope, achieved a SOLID understanding of SOA and ESB at conceptual level. Therefore, the SOA conceptual architecture is the foundation of the overall enterprise architecture driving increasing ROI with enterprise service reusability and value creation through existing IT assets.

Second, to take this conceptual understanding to the next level, you would want to have a critical path or roadmap in front of you for the whole enterprise.  Here comes SOA lifecycle management and governance processes. Through initial SOA assessment, the enterprise has the opportunity to gain a fresh understanding through the gap analysis. From there, a real-world SOA roadmap is on its way. We will talk about this in another post.

Third, I understand that it is more interesting to discuss the vendor product mapping to the conceptual architecture to deliver logical and physical architecture blueprints. With all those experienced professionals (not including trained only) who possess sigificant large complex project implementation experiences, it would be no brainer for them to narrow down from the tier-1 players in this field:

  • webMethods: Fabric is a well integrated platform for ESB with both EAI and B2Bi well proven in the marketplace, with recent acquisition of Infravio.
  • Sun Microsystems/SeeBeyond: JCAPS, the latest release of SeeBeyond product suite after ICAN, delivers much improvement in both architecture and development.
  • TIBCO: BusinessWorks is still a young product compared to the rest and the performance and stability are the main areas for improvement.
  • IBM: WebSphere Business Integration (WBI) product family has a wide range of products through acquisition – the product integration itself remains to be proven.

These vendors are thriving very hard to maintain the market leadership in existing and emerging markets as well as invest heavily in overall product suite through both in-house product development and merger and acquisition. Each of them has distinctive product components, however, it would be fairly straightforward to map physical product components to the conceptual architecture.

Next, we will continue on some important architectural components such as BPM, BAM, EAI, B2Bi, Service Registry and so on.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: