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!

SaaS = Silo'ed Applications as Services?

I am just back after presenting at "SaaSie" which is an Irish conference on software as a service. I like the name and enjoyed the conference which was run by Enterprise Ireland and was well attended. Overall I found the sessions well balanced and informative - however I did find one thing a bit disturbing...

Integration does not appear to be high on the list of concerns for many of the SaaS vendors that I met...... In my opinion this is a significant oversight and one which goes against my experience in dealing with organisations looking to offer services to customers.

You see Cape Clear have been selling to organisations that offer "services" to their customers since we were founded - customers like JP Morgan and Alliance Trusts offering financial trading "services", organisations like Pearson Education offering outsourced college registration "services" and organisations like Workday or Mr Ted offering software as a "service". All of these organisations share a common challenge - making sure that their "service" is accessible to customers who wish to use it - and all of these organisations have identified the need for an integration platform to facilitate that access.

The reason is very simple - if your "service" is going to be more than a standalone information silo then it needs to get data to and from customers on-premise applications and external service providers. This necessity requires you to overcome challenges such as:

• Finding a common tranport for data communication
• Finding a common syntax for data exchange
• Ensuring that sensitive data remains secure
  
• Ensuring the integrity of business transactions
  
• etc...

Failure to overcome these challenges severely limits the reach of your service and thus it's revenue potential.

There are a number of strategies SaaS vendors have proposed to overcome these issues - the most common of which is the implementation of an API (e.g. Web Services interface) to the service - if a customer wishes to integrate with the SaaS application all they need to do is to conform to the defined API. I have also dubbed this the "Henry Ford" strategy because if the customer will not or indeed cannot conform to this interface then they cannot be a customer - to paraphrase "the customer can use any interface as long as it is WSDL".

Unfortunately conformance is not always an viable option available for SaaS users - there are various reasons why they may not be able to conform to the interface the SaaS vendor prescribes - these include:

• •Control - the economic buyer in the customer organisation may not have sufficient say in the development of the systems which need to be implemented - e.g. how much control does a purchasing manager have over the ERP system? Some of the systems which need to be integrated may be external to the customer in the first place!
  
• •Skills - the customer may not be very integration or WS-savvy. If the SaaS implementation looks complicated the customer may just make do.
  
• •Cost - The initial cost of integration may reduce or eliminate the ROI from using the SaaS software.•

If the value proposition for your SaaS offering is so compelling that your customers will overcome these reasons for inertia then please leave your number - my investment broker will be in touch. If, on the other hand you must walk on dry land like the rest of us the integration problem is not just an issue for your customers - it is an issue for you as a SaaS vendor and one which should be a core concern.

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.