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.

BCS London - Euan Semple on the "Next Generation Web"

I attended a very interesting talk by Euan Semple at the BCS last night. I've seen a lot of people speak about web 2.0 and the like in the last year but Euan's presentation was interesting because it focused on the organisational and social changes the technology can bring about rather than the joys of AJAX programming. I think he is spot on when he talks about this technology as disruptive, for many organisations having employees able to answer each others questions or join in the debate about a new policy is something new, and for some company's quite frightening. Simple things like wiki's, forums and blogs can change the way you run your business.

I know some of my friends remain skeptical about the BCS, seeing it as somewhat irrelevant and 'old fashioned', interesting topics such as last nights go some way to addressing that.

QCon - EBay, Amazon & Yahoo - 3 different architectures

I was lucky enough to attend QCon last week, having been to JAOO I had very high expectations and I wasn't disappointed.

During the conference Amazon, EBay and Yahoo all spoke about their architectures. Martin has already noted the lack of transactions and 2 phase commits, I guess I was not as surprised as some having worked on high throughput equity trading systems. My big take from these talks was slightly different, what struck me was the high degree of alignment they had with their different business models and the modifiability they'd achieved.

All too often architecture is an activity disconnected from the needs of the business, both the current and future needs. Many architects spend their time arguing why the current architecture meets all needs and how it doesn't need to change. This is the architect as policeman. You certainly could not accuse Amazon, EBay or Yahoo of that, each time they explained a technical choice it was always justified by their understanding of how their business works. They also all saw their architecture as something that changes as the business changes, this is the architect as enabler.

So if your architecture has become something that gets in the way of projects or that you spend time 'working around' then maybe it's time to question the alignment and ask if the architect knows how the business works? If architecture is not making your life easier then something just ain't right.

Charles Simonyi Interview in MIT Technology Review

I saw Charles talk about Intentional Software last year at JAOO, I'd kind of hoped he'd be at QCON, maybe next year? Anyway fascinating article.

who is the 'you' in 'yagni'

A term I sometimes hear used is YAGNI, its one of those ones thats very popular: short, punchy, seemingly profound. It stands for 'You Ain't Gonna Need It', and is often used by developers to avoid or challenge additions to a piece of code, but who is the 'You' in this statement? Is it the developer, the customer or the support staff?

I'd rather ask 'When are they going to need it', the answer might be never, or it might be 'at the end of month when the peak load is on the system', or 'after go live when someone tries to hack into the web site' So the 'they' are the customers, both those who use a system and those who maintain it. For me YAGNI simplifies things a little too much.

The One Thing You Need to Know about Quantum Computers

The One Thing You Need to Know about Quantum Computers

Tackles some of the myths that exist around this fascinating area.