Are the lessons of SOA being ignored with the cloud?

Many of the lessons of SOA have been lost in terms of what SOA originally endeavoured to achieve from a technology perspective. SOA originally promised the ability to choose and use best of breed technologies from different vendors inter operating using a number of standards. This was watered down to being able to use SOA software stack from vendor a, b or c.

The Cloud providers have now done the same by locking people into their particular Cloud so that if you go with Cloud provider a, b or c, you are simply locking yourself into yet another proprietary architecture.

Ideally what would be nice would be to have a generic Cloud image and run it in whatever Cloud you wish. Perhaps for a given workload, the day will even come you can choose your Cloud provider on a daily basis depending on what are you key criteria (e.g. cost) and then deploy your image to that Cloud......however, this wont happen anytime soon.

In the mean, the use of interoperability standards can help to allow you to black box your Cloud providers to move workload from one to the other. You can find more on this topic here if you are interested.

Can SOA deliver on integration promises ?

Much of what SOA was related to in the early days were the Web Services standards that enabled much quicker, cost effective integration of data and business logic.

One of the goals of 'SOA' was the concept of using best of breed technologies that integrate together. The idea that you could pick the best technology for the job whether it was from vendor a, b or c and it would work with the best of what vendors x, y and z delivered was a very attractive one.

Yet another goal of 'SOA' is reuse of services which comes down to the core of the question here. If the SOA stack is proprietary, it makes integration with other technologies and thus reuse from them as difficult and expensive as it ever was.

However, the larger vendors have sadly dumbed down what was promised by insisting on you buying 'their' SOA stack of software and providing some integration possibilities using standards on the outside but with proprietary internals with dependencies on their particular stacks.

If SOA only promised that we would have services, any well run IT organization has been building 'services' for many years that are still reused on a regular basis today.

One of the original promises of SOA was to allow better, more cost effective integration between best of breed technologies that could then deliver the services that the business required throughout the enterprise. The easier integration facilitates a level of reuse not possible with proprietary stacks. This ease of integration applies in the Cloud more than ever as what organization wants to simply spend money to move to another proprietaray environment in the Cloud ?

The SOA Gateway is a 'best of breed' technology that makes accessing your data and business logic easier while also working with any other 'best of breed' technologies from other organizations.

Transitioning your workload to the Cloud

Various Cloud computing organizations are offering the Nirvana in terms of IT where you only pay for what you use and capacity planning can become a thing of the past because of the elasticity provided by Cloud implementations. One would wonder why more organizations do not move into either a private or public Cloud, however, the answer is relatively straightforward.

All of the Cloud implementations available today make resources available on a limited number of platforms with a limited number of software stacks. While there is nothing wrong in principle with this, it means that if you are running your business on anything other than the limited platforms offered, it will require a conversion effort to prepare systems to be moved into the Cloud. This conversion effort represents another expensive exercise effectively to put your applications on yet another proprietary software stack.

A standards based approach to Cloud will pay a lot of dividends. While the Cloud itself still leaves a lot to be desired in terms of standards, the usage of existing inter operability standards like SOAP and REST will position your applications and data to move into the Cloud. The basic concept is:

- Create SOAP or REST Services around your core assets meaning your existing applications and data.

- Moving forward, your clients or consumers of these applications will use these SOAP or REST Services to get their data.

- Identical SOAP or REST Services may then be created in a public or private Cloud.

- Data can then be moved into the Cloud implementation.

- Once completed, your consumers of this data must simply be pointed at the new Cloud based SOAP or REST Services.

While such an approach does have costs associated with it, these are likely to be similar or less than what it will cost to move your applications on a proprietary basis into the Cloud. Consider also that this approach leaves you with the flexibility to potentially move workload easily again to perhaps a cheaper Cloud provider thus providing the optimum combination of flexibility and choice of provider. One requirement you will have will be that the tool or tools you use for this effort also run on multiple platforms and technologies. The SOA Gateway is such a tool. You can find further information on this topic at the document found here.

Change management, as it used to be called, or the new buzzword ‘governance’ is a key component of any SOA.

If we consider that one of the main benefits of SOA is reuse, this can sometimes only happen when slight modifications are made to a service to allow it to be used for a different purpose. The change will normally not impact on the previous use but to ensure reuse, the change must be made.

It is key that an existing, running service does not break so there must be different versions of a service available during the transition phase. However, once working, it is essential that the existing users of the old service are upgraded to avoid having to support multiple versions of the service. As such the usage of your services is key to this change management.

SOA Governance with the correct tools can be extremely helpful in upgrading services ensuring continued reused and deprecation of older copies of the service. There are two documents here which discuss how both life cycle and usage governance of your services can help your organization. These governance capabilities are all implemented in the SOA Gateway.

Is SOA dead within the enterprise ?

It is often said that SOA is dead simply because it does not appear to have been adopted in any great way by many enterprises but nothing could be further from the truth.

We need to consider here that enterprises change very very slowly for good reasons. They have systems running for many years that have served them very well. Many have learned through painful experience that making quick changes can costs millions in lost business and productivity through systems working slowly or not being available.

The point is that 2, 3 or even 5 years in the IT cycle of an enterprise is not a huge amount of time. Many will IPL (reboot to readers unfamiliar with this term) their enterprise systems (normally large mainframes) only once or twice a year which may surprise many people who see Windows and Linux as being the be all and end all of computing and a regular reboot as being a fact of life. Many enterprises have adopted a SOA approach over the years already so SOA is really just a new term for what they have been doing before it was called SOA.

Many enterprises have been using services for many years and will continue to align these with the external services provided via the Web and other new channels over time and more than likely even when someone has come up with some new term for it. The SOA Gateway is a simple way of introducing a SOA structure into your enterprise.

What is a standards based SOA ?

In the early days of SOA discussions, many people would have understood the term SOA to relate to implementing services using the following standards amongst others:

-         TCP/IP and HTTP to provide the connectivity to the machine(s) where the services reside.

-         eXtensible Markup Language (XML) to provide a platform, technology and language neutral way to exchange messages.

-         Web Services Definition Language (WSDL) which enables a service to describe in XML what it can do and how to call it. This is the piece that enables software to understand what a service can do and how to call it without any software installation being required on the client system accessing the service.

-         Simple Object Access Protocol (SOAP) which is used to build the request message (based on what was learned from the WSDL) to issue a request to a service and to receive a response from a service.

Using the above standards, technologies like MS InfoPath and many other technologies that understand these standards can:

-         Connect to another computer and request the WSDL for a service using TCP/IP and HTTP.

-         Receive and parse the WSDL (written in XML) to determine what methods the service offers.

-         Build a SOAP request to invoke the service and to understand the SOAP response from the service.

While SOA has come to mean different things to different organizations depending on what they are trying to sell, using the above standards and other related standards will ensure your services can be used again and again by multiple technologies on multiple different platforms and represents the ‘standards based SOA’ mentioned in the title. The SOA Gateway enables the creation of standards based services using configuration and without any coding whatsoever.

When is a SOA implementation complete ?

This is a question that is raised many times as it is quite normal to want to draw a line under any effort when it has been completed.

SOA at its highest level is architecture and an organization wide philosophy of how things will be done drawing input from the business and IT parts of an organization. Unless your organization intends to stay static for the foreseeable future, the SOA Implementation is an ongoing effort as each new project emerges.

During the early stages of the implementation of a SOA in your organization, there will be many projects planned and ongoing as you move forward to improve what is currently there. Many SOA projects will be completed as you proceed but in the early stages at least, there will always be further projects to complete.

As SOA becomes embedded in the organization, the numbers of projects will potentially be reduced, however, in a vibrant organization, things are continually changing and new projects will always be on the cards. These too must be implemented to work within your new SOA.

Ultimately while individual SOA projects will be completed, the effort to implement SOA in your organization must continue forever and will continue to provide benefits as your organization progresses.The SOA Gateway can form a key part of any SOA strategy.