SOA: Battle of the Titans

October 28, 2005

SOA: Battle of the Titans

SOA: Battle of the Titans

by Judith Hurwitz, CEO

It is indeed an interesting time in enterprise software.  Suddenly, the major enterprise vendors are all deciding that they will own SOA and make it the foundation of their own development and partner ecosystem.  In addition, each vendor hopes to win the hearts and minds of the customers and the partners at the same time.  Which vendors are positioning themselves for this leadership?  IBM, Microsoft, Oracle, SAP, Fujitsu (with its partner Software AG), BEA, Tibco, and a host of others.

Ironically, many industry observers were skeptical when IBM declared in the late 1990s that it would abandon the packaged applications market and focus instead on middleware to enable the business applications.  Now, of course, the application vendors are beginning to recognize that middleware infrastructure is critical to the success of a SOA environment. So the battle for supremacy has begun.

However, this is not sitting well with customers who don?t intend to support a single infrastructure ? as nearly all of them have very heterogeneous environment. Rather, customers want interoperability across middleware.  Instead of dwelling on the details of the battlefield, I thought it would be helpful here to take a step back and focus on the principles of SOA from the customer perspective.

SOA is an important and complex journey. When successfully addressed, SOA can enable business and IT to proceed from a common business model ? rather than talking different languages and focusing on different timeframes.  The following is what I believe are the ten top principles for SOA

The ten principles of SOA:

  1. SOA is real.  It is not a quick fix. It is a ten year journey (or longer) that requires considerable planning. It is also as profound and far reaching as, for example, e-commerce
  2. SOA is build upon 15 years of experiments in creating highly distributed computing environments that take into account everything from load balancing, software distribution, security, and data management including meta data management and registry. SOA embraces all these aspects of computing and takes them into account.
  3. SOA will only work if organizations lead with manageability. SOA by its very nature demands the aggregation of IP from many different sources.  Scalability within SOA will come from management ? not development
  4. SOA will only work if it is implemented within a business process context.
  5. SOA is predicated on leveraging business services that constitute the component parts of your business. 
  6. SOA requires a container that creates a composite application
  7. SOA requires standards that can be depended upon across all vendors? implementations of SOA
  8. SOA assumes that you will begin to write applications differently ? as a series of tightly defined services implemented in a loosely coupled manner
  9. SOA assumes that each component part is equipped with a clearly implemented web services interface based on standards
  10. SOA dictates that change is the norm since this approach to software mimics the way a business operates and evolves.  

Why did I feel compelled to give you my principals for SOA?  I am seeing too many vendors who put ?SOA? on their slide decks without really understanding what SOA is and what their responsibility is to customers.  Therefore, when a vendor states that they are providing a solution for solving the (fill in the blank?security, management, etc.) for SOA, make sure that they are in fact defining their terms.  For example, an SOA environment or offering must be componentized.  SOA offerings must provide clearly defined interfaces based on widely adopted standards.  Putting the word SOA in front of a product offering just isn?t enough.  It doesn?t make it SOA-ready.

 

Newsletters 2005
About Judith Hurwitz

Judith Hurwitz is an author, speaker and business technology consultant with decades of experience.

Leave a Reply

Your email address will not be published.