Can IT vendors deliver on SOA?

2006 has seen SOA move solidly into the mainstream as a way to deliver IT, most organisations (Capgemini SOA Survey) are looking at it as a the way forwards for their IT organisation. Now whether most of these are really looking at SOA, or practising one of the main SOA antipatterns, is a mute point. The key element though is that organisations are looking to SOA to deliver a consistent IT infrastructure and concentrating on the importance of architecture.

The vendors however are continuing to concentrate on the technical elements, which as Miko pointed out at the recent Oracle EA club are the low cost and low impact challenges, while businesses and systems integrators are focused on the human and governance challenges of SOA. Previous IT waves have concentrated hugely on improvements in technologies, the difference being ERP which started to concentrate on how business operated. SOA, when done well is focused hugely on the actual delivery of IT and projects rather than on the technology in that delivery. Which means the skills are not around technical considerations but the human ones.

SOA-RM and the SOA Adoption Blueprints both consist mainly of technology delivers rather than vendors, who are concentrating more on things like WS-Transaction et al. So without a focus on IT delivery can vendors ever hope to deliver on SOA?

When governance becomes an application

During a rather nice meal in London with Miko Matsumura of Infravio the service governance people he highlighted one area of the coming SOA challenge that I hadn't really thought about. Namely the challenge of governance rules becoming applications in themselves. Its one of those things that become obvious when you follow the trail down to the end but its still a different way of thinking about SOA.

Basically the point is that while Service governance is simple policy (e.g. WS-Security) or about protocol then its all nice and simple. When it becomes about rules of governance, e.g. only people with authority X can update this service or even "these fraud validation rules must be done on each inbound transaction" then it ceases to become simply about policy and more about actual business logic and function.

So the question basically is, when does policy become business logic and what is the best way to define, build, deploy and manage a governance centric service? Is "Payment" the functional service and "Payment with fraud-detection" the enterprise service?

Splitting up the ESB

Following up on an earlier post its worth going over the difference between a business service bus and an integration service bus. There are a whole different bunch of vendors out there selling "Enterprise" Service Bus products, in reality these are normally products aimed at creating services out of existing systems (Integration) or at providing accessibility and management to more business oriented services. The problem is that people are confusing the two areas, which is very dangerous if you want a successful project. Integration products are about adapters, transformation from multiple data format and generally trying to squeeze that damned external application into a shape that the rest of the world can use. These are about managing events to and from these systems, short life processes and a real concentration on shifting data, enrichment and all the trimmings.

The otherside of the story is the business side, this is about policy, management, control and business function. This is the XML centric part of the world, mediation and minimum transformation, versioning and of course enabling connection to be done in differing ways, to me this just means reliable v non-reliable and using queues v HTTP or email rather than trying to get it out of an ERP specific format or a database.

What isn't in ANY of this is business process, that is a different thing again, in fact business process is about BUILDING services, normally high level ones its true but services none the less. Business process is an application thing, not just a layer across the enterprise. As tools begin to enable more and more to be done its getting more and more important to be clear in your architecture what is done where, otherwise you end up having one almighty blob that you christen as you "SOA ESB" and two years later you curse as Project X which gives you no clarity as to what is being done where.

So basically don't buy one ESB to fit everywhere, make sure you think about the specific challenge you are facing and separate integration tasks from business service tasks, and keep business process out of both of them.

OASIS SOA RM releases its committee draft

The OASIS SOA Reference Model group has released its committee draft this is a fantastic achievement and the document is one of the best out there in describing what SOA is all about. Originally it was focused purely on the software side but the committee draft broadens this scope to enable the inclusion of non-software services, for instance those being developed in the OASIS SOA Blueprints group. The reference model has been developed primarily by people who actually do SOA on a day-to-day basis rather than by product vendors, hence its focus on the principles rather than a morbid fascination on Web Services technology.

This SOA reference model works therefore from a long term perspective with a good clarity on principles. Its fairly interesting to look at the membership list this is a specification created by people who deliver SOA.

(updated to include the right link for the PDF!)

Why is there no WS-Contract?

Bit of a self plug but... Macehiter Ward-Dutton: Blog on IT-business alignment and related things is by a co-presenter on an ESB Webinar, its got an interesting set of questions around the different vendors on the blog though, and a paticular pet peeve of mine, namely there is neither WS-Contract, or WS-SLA so in terms of defining the "ilities" of applications and the KPIs there is still nothing, its all focused on Transactions, reliability and a series of other elements that businesses don't care about.

Sun puts Tin as the only part of infrastructure

Reading SOA Best Practices: A Conversation With Sun Microsystems Distinguished Engineer Mark Hapner its interesting that only Sun appear to consider the infrastructure platform to include only hardware elements. Most of the other vendors would consider the software elements, such as ESB to be part of the SOI, with the applications being SOA.

Service Component Architecture

IBM's Service Component Architecture (SCA) is a cracking new solution to the issue of "what represents the service", a definate improvement over WS only technologies it starts from the basis of assuming that the container at invocation should be standardised, but that the implementation and container at the produce can be variable. This really helps from a conceptual and logical architecture perspective as it gives a level of consistency that WSDL, and even WS-IF struggled with. Most interestingly around SCA are the companies who have said that are going to adopt it. BEA, IBM, Oracle, SAP, IONA, Siebel and Sybase, now while the idea of SCA is not Java only, pretty much all of this camp is in the Java world, I guess its like how JCA isn't Java only as it connects to lots of external applications, it just "happens" to run in Java. Definately worth a look and something that I'd expect to gain rapid adoption. Its already in the wild in IBM's new Process Server and their Integration Developer.

SCA is in someways an extension of the work that BEA did with Beehive so I'd expect them to be able to move relatively quickly, as should Oracle as they are moving from a similar technique using WS-IF, which IBM used in the previous version of their product too.

Strong technology with a very devent future.