Martin Bloor of Hurwitz gets the "I couldn't have said it better myself" award for his reflections on the capabilities of Cape Clear 7.5. I could only find one fault: He uses the term "SOA Realistic" to describe real-world SOA implementations - I like the term "Pragmatic SOA" (tm) ;-) better.

Let's talk about SaCS

Vinnie Mirchandani from the Deal Architect has coined a new term (well new-to-me anyway) called SaCS, Software as a Customisable Service. He describes it in this blog entry. I really like the term and plan to misuse it frequently.

I think that the idea of having a one-size-fits-all interface model is theoretically great but has NO chance (for Gartner fans that is 0% probability) of success. The history of IT teaches us that there are no such silver bullets.

In Cape Clear we have been speaking about the "Illusion of Uniqueness" where standard service interfaces can be facaded or re-purposed to meet the needs of the service consumer. Services can therefore be presented as multi-channel, independent of the transport infrastructure and of the native data structures used by the consumer. In this way service consumers who are capable of using the service interface directly are encouraged to do so; while those who are not yet ready to use service interfaces can still use the capabilities by adding a facade. We have seen this pattern in SaaS applications and also in traditional enterprise integration and business to business integration projects.

We are currently developing a new assembly framework in Cape Clear 7.5. This framework significantly reduces the complexity of adding the routing, validation, transformation, and QoS mapping capabilities required for a facade. You can read more about what we are doing here.

Software as a Customisable Service feels right to me - the idea that there is one true interface does not even survive the current SOA & SOAP vs REST & XML/HTTP debate. Diversity lives - vive la diversite!

I just read an article by Jeff Kaplan of Think Strategies called "SAAS Fault Lines". I think Jeff raises an issue that will resonate with all software product vendors - not just SaaS vendors. In all of the companies that I have worked for there is a tension between strategic product focus and customer-specific features. Whether hosted or not, software vendors constantly walk a product management tightrope between good, strategic, architecturally pure development; and tactical work with a high maintenance overhead which keeps the lights on.

I dont think we can set down hard and fast rules for SaaS vendors - each case will have to be taken on it's merit and there will be times when customisation will be preferred and where it will make good business sense.

I think the technical challenge for SaaS vendors is to build a multi-tenanted service platform where customisation/extension is a managed activity rather than an ad-hoc one. Many SaaS vendors already offer per-customer schemas and extension points as part of their service.

The key questions for me are:

Where one draws the line on customisation

Each customisation/extension should be considered using simple product management criteria like - will it cost more to develop/maintain that it will accrue? is there a possibility that the extension could be reused for other customers? etc.

WHO owns and supports the extension.

...or to be more precise - who pays?

Which technologies can assist SaaS vendors to be as agile and flexible as possible (without making them snap!)

My shortlist would include SOA, Spring and OSGI.

The capability to be flexible and extensible will be key differentiators for SaaS vendors going forward.

Integration Cubed

"Integration" is a many faceted term.

• The SOA/ESB/middleware business is all about "integrating" applications so they can share data and functionality - Integration Once.
• When delivering these integrated applications you need "Integrated" tools which work together to make you productive - Integration Twice.
  
• When deploying integrated applications you want a common platform for managing and monitoring the integrated apps - Integration 3 times.

It is important when you are choosing an integration platform that the platform delivers in all three aspects - Integration Cubed.

Too many integration solutions today offer a disjointed experience. They focus on one layer of the architecture without properly considering the end-to-end use-cases. In doing so they create solutions that dont quite fit together and are less than the sum of their parts.

Take for example BPEL orchestration in the SOA context - there are a number of vendors offering orchestration as a standalone offering. In some cases these products are quite sophisticated however they fail for the following reasons:

• BPEL engines are often combined with a Web Services stack and an ESB container to provide SOAP and transport/data integration capabilities respectively. The setup, configuration and support of these three can be quite difficult for simple applications - but for mission-critical applications with high availability, performance and resilience requirements the architecture becomes like a house of cards.
  

• BPEL processes are themselves Web services, and, just like other Web Services they must be managed and monitored. However if they are deployed to a separate engine then you probably need two consoles instead of one to manage them. If you want to apply security to your services then you probably need to specify policy for your services in different places for your BPEL Services and their children.

• BPEL Orchestrations are dependant on the underlying web services from which they are created. In a perfect world these services are complete when the orchestration is being authored. In this idyll the developer has access to everything they require in order to build their orchestrated service - the WSDL - and this does not change. Sadly the blue planet that we call earth is not perfect - the reality is that Web Service implementations and the BPEL which orchestrates them are often evolving in parallel. In this case it is important that changes in the WSDL get reflected in the BPEL. This does not happen when you have separate development environments for BPEL and Web Services.

At Cape Clear we work to deliver Integration Cubed - providing integration capabilities that are functionally, operationally, and from a development perspective coherent. We believe that a successful SOA framework must be verified top-down to mirror the applications that are built upon it. Solutions which take specific layers in the SOA and offer these in isolation provide little or no support for end-to-end capabilities required by SOA Applications like reliability, performance, management & monitoring.