Integration Tomorrow, Part 2: SOA Architecture

Part 1 of the two-part series described the past and current integration approaches. This second part, takes a practical approach on how technology is going to change business landscape and the potential infrastructure changes required to integrate the business both at business and IT levels.



Read more about this here.

Vendors need to incorporate SOA infrastructure in legay applications

The majority of the IT budget (over 80%) is typically committed to supporting the existing infrastructure and applications. Even though adopting SOA brings substantial value over the long term, the short-term impact actually increases the support cost in two ways.

First, IT organizations will need to procure additions infrastructure components such as the Enterprise Service Bus, Registry/Repository, SOA Manager, SOA Governance tools, etc. Products like these not only requires upfront initial investment, it also adds one more layer of abstraction (hop) in the existing environment impacting the end-to-end performance.

Second, the support organization shall need to increase headcount and hardware infrastructure to support this next generation of infrastructure.

Even though most of the existing packaged applications are re-architecting their solution to run on the SOA platform, we are still years aways from wide deployment of these next generation applications.

It for this reason, it may make sense for the packaged application vendors to actually focus on retrofitting their previous versions of applications with the SOA infrastructure such as replace proprietary work flow by BPEL or XPDL, service enable (better) some of the business processes/services. It should be done in such a manner that the developers could still use the existing (proprietary) tools, keep the current functionality as is, limit functionality changes and roll this out as a patch release for the existing ERP, CRM applications.

This approach shall accelerate the adoption of SOA within and enterprise. In addition, enterprises shall be willing to pay incremental support to get this capability, a win-win for both the vendors and their customers.

SOA real-life case studies

The SOA Consortium today published real-life SOA Case studies which are available here. These case studies are categories by types of projects (proof-of-concept, Business led projects, IT led projects and Mega projects) and industries.

The entire set is also available as a pdf, if required.

Defining Business Agility

There has and continues to be a lot of discussion around Business Agility and following is how I would define Business Agility

Business Agility = Business Alignment + IT Flexibility

Business Alignment: Alignment between the various business units
IT Flexibility: Alignment between Business and IT + ability to rapidly deploy new business capability

My observation has been that business is pretty flexible and has the capability to create a new business model effectively, if required (of course under the right leadership). The real challenges are IT's ability to integrating the new business model with the existing infrastructure. My experience has been that adopting SOA enables IT flexible to adapt to these changing business models.

Business Agility could also be defined as:

Business Agility = Business Intuition + IT * (Business Alignment + Flexibility)

Business Intuition: A common sense approach for aligning the various business unit

Business Agility = Business Intuition + IT * (BPM + SOA)

BPM: for aligning IT with the Business (yes! the business defined the business process but it is the business analyst - typically from IT captures this. Very rarely have I seen business actualy use a BPM tool for modeling business processes)
SOA: for providing flexibility

SOA Postulates, Theorems & Corollaries

Similar to the mathematics, I felt that there is a need to define the laws for Service Oriented Architecture based on facts, observations and technology roadmaps and have termed tham as SOA Postulates, SOA Theorems and SOA Corollaries.

SOA Postulates:

1. A service is an indivisible unit of work
2. A service is independent of the protocol or implementation
3. There will be one and only one service producer
4. There can be multiple instances of the same service
5. An entity that utilized the service is called the service consumer
6. There can be one or more service consumers for a given service
7. A line between the services is the agreement between the producer and the consumer
8. A service can invoke other services, thereby, creating a hierarchy of services
9. A service not consumed by any producer is an orphan service

SOA Theorems:

• SOA Theorem #1 SOA Governance observers Newton's laws of motion
• SOA Theorem #2 IT Funding observers Archimedes' principles
• SOA Theorem #3 The need to Enterprise Service Bus shall diminish over time
• SOA Theorem #4 Service hierarchy should not exceed more than three levels

SOA Corollaries:

• SOA Corollary #1 Dynamic Service Discovery does not require centralized repository (Corollary to SOA Theorem #3)
• SOA Corollary #2 All service containers need to count and limit service hops (Coroloary to SOA Theorem #4)

For those not familiar with these tersm following are the Wikipedia defintions

Postulates: The term postulate, or axiom, indicates a starting assumption from which other statements are logically derived. It does not have to be self-evident (constancy of the speed of light in a vacuum is not self-evident, however it was used as a postulate in the special theory of relativity). Some axioms are experimental facts, but some are just assumptions not based on anything.

Theorems: In mathematics, a theorem is a statement, often stated in natural language, that can be proved on the basis of explicitly stated or previously agreed assumptions. In logic, a theorem is a statement in a formal language that can be derived by applying rules and axioms from a deductive system. This definition in logic is crucial in fields such as proof theory that study the general properties of provable and unprovable statements.

Corollary: A corollary is a mathematical statement which follows easily from a previously proven statement, typically a mathematical theorem. The use of the name corollary in place of proposition or theorem is usually subjective: proposition A is a corollary of proposition B if A can be deduced quickly and easily from B, but the meaning of "quickly and easily" varies depending upon the author and context. Sometimes a corollary has a proof which explains the derivation; sometimes the derivation is considered to be self-evident.

Integration: Then and Now, Part 1 - SOA Architecture

Integration of business systems is one of the key capabilities that should be provided by IT to enable business agility. This has been the primary objective of all integration effort to date; however, due to various factors most of the integration efforts have not achieved the expected business benefit. Of course, projects with the right executive backing have been successful but have never reached their full potential. The objective of this column is to demonstrate how adopting a service-oriented architecture (SOA) enables a company to achieve business agility and flexibility. This is a two-part column; this first installment deals with high-level integration architecture based on SOA and the second will focus on SOA governance.

Read more about the first column here.

SOA Consortium Reaches 50 Member Mark in Less than Six Months

The SOA Consortium was launched earlier this year and now has 50+ members and read more about it in their press release.