SOA Vendor survey - not very helpful?

Service Architecture - SOA: SOA Vendor Ratings - Q1 2007

I'm puzzled, how can you assess SOA vendors when SOA is not something you can buy? To be clear I don't believe buying any one of those products is going to give you SOA. A Service Oriented Architecture is an approach, an architectural style, not a product to be bought off the shelf. I worry people will read the article, buy a big expensive piece of technology and a year later wonder why they still have a load of integration spaghetti on their hands. Jim Webber's presentation(powerpoint) explains this danger very clearly.

Lets look at the categories used in the article:

* BSA - Business Service Architecture, the ability to model the enterprise as services

• The ability to model an enterprise as a collection of collaberating services is dependent on having people who understand how to model services, a tool may help but the people matter more.
  

* BSB - Business Service Bus

• I agree that a bus is a better network topology for a SOA style than a star topology. When I look at many vendors solutions I see complex 'brokers' sitting at the heart of their solutions, I believe we should ask 'Does the vendors solution contain any major performance bottlenecks or single points of failure'.
  

* BPM - Proper SOA and business centric Process Management

• We need to differentiate between the monitoring of individual business processes and the overall monitoring of orchestration between multiple services. The former probably lives behind the service boundary, the later sounds useful, although the attributes we need to measure often depend on business purpose of the service.
  

* Registry - A service registry

• Plus service discovery as well. In some cases a web page with a list of services is good enough, especially where relationships between service providers and consumers tend to be long lived, dynamic service discovery is often a nice to have.
  

* Management - Ability to manage and configure operational services

• We need to look long and hard at what aspects can be usefully configured or managed and how that can help us - there is a difference between managing services at a technical level (i.e. messaging queue names) and at the business level (i.e. prioritising a particular customers orders).
  

* Monitoring - SLA and monitoring of services and interactions, independent of the vendor

• So monitoring of services to alert me if an SLA is going to be breached? How about 'Not being locked into the vendors SLA monitoring solution'
  

* Testing - Testing of services at all stages of the lifecycle, especially async testing

• Yes, as long as I don't need a full deployment of the whole product in every environment, although vendors are always happy to sell extra licences. How about 'Does the vendor provide a way of automating the running of acceptance tests. Do they support unit tests for logic embedded within their tool?'

* App Design - Ability to develop applications that consist of multiple services

• Hire some people who know how to design apps, doddleware isn't likely to be that helpful.

* App Dev - Ability to develop services and applications that co-ordinate them

• For developing services see the above comments, as for applications that co-ordinate them - if I'm writing this myself I'd question if I really need an 'SOA' vendors solutions, maybe I just need some messaging middleware.
  

* App Process - Application level process models (where BPEL sits) and its ability to work in a proper SOA way

• Why not WS CDL instead of BPEL - although I've found drawing sequence diagrams is usually good enough.
  

* App Model - The overall conceptual model of SOA applications that the vendor pushes

• This is more like it, although I'd prefer something more like 'Does the conceptual model the vendor pushes limit the situations which their tool can be usefully used'.
  

* ISB - The integration service bus, getting things out of older systems

• Does this mean legacy integration? Puzzled.

* Adaptors - How easy is it to get things out of old systems

• Adaptors certainly help, as long as they don't expose internal application data models and then force you to do mapping in the vendors 'message broker' tool. Adapters can be used for 'new' systems as well.
  

* Int Model - Integration Model, the conceptual model that the vendor pushes for integration

• See comment above about the App Model

* Standards - How well does the vendor implement and support standards

• Yes - standards are good, how many support Open AMQ I wonder? That said standards are a means to an end - they should allow easy interoperability and help me avoid vendor lock in.
  

* SCA/SDO - How well is the vendor progressing down the SCA/SDO path

• Is this a path that helps? How do SCA/SDO add value?
  

* JBI - How well is the vendor progressing down the JBI path

• ditto

* WS-* - How well is the vendor at supporting WS-* (WS-TX excluded)

• I've posted about this before. Dan pointed me at this diagram, things are starting to look a little complex. BTW - Why is WS-TX excluded?
  

* J2EE - How well do they support J2EE (standardised operating environment = lower support costs, no matter how much people bleat)

• I'm more interested in support for multiple languages and platforms, for example c#, c++, Ruby etc. How about asking if their product has api's for multiple languages instead?

* Roadmap Honesty - How well (IMO) does the published roadmap reflect what will really happen

• How about going back and comparing press statements from 2 years ago with what the product does now? Not sure what we'd find, but could be interesting.
  

I really struggle to see value in measuring 'SOA' vendors on criteria that appear to assume we can buy SOA off the shelf, maybe I have misunderstood.

Look at how your business works, look at the services that different parts of the business provide each other with, think about the different QoS required, do all of these things and more - then think about whether a vendor has some technology to help you implement your architecture.