Economics of Service Oriented Architecture  

Service Oriented Architecture (SOA) is changing how enterprise software is being designed and deployed. Part of the success of SOA is in the technology and is due to the convergence of web services standards creating a common interoperable set of technologies to build SOAs on. The other part of the success of SOA arises from its superior economic model for enterprises. SOA is evolving to the point where new applications will not be deployed as monolithic instances but will become a collection of services woven together in a loosely coupled framework. Applications are becoming virtualized and being made available on-demand this will break the current technological and economic bottleneck caused by the traditional enterprise software model. This problem does not reside with enterprise IT organizations but rather with the enterprise software model as a whole. In most cases though corporate IT is made the scapegoat for the problems with the enterprise software model. Until now there has not been an alternative to the traditional model of deploying silos of functionality now IT organizations have a choice and a way out of the current web of complexity.

The service based model of software is here and forward looking enterprises are rapidly adopting it as a means to streamline operations, reduce costs and provide significant differentiation in the marketplace. Successful companies are investing in services that differentiate the company, and outsource commodity services to organizations that deliver them more reliably, and more cost efficiently. Who today would invest in building an overnight parcel delivery service? Likewise who wants to invest millions of dollars in the design and implementation resources in a CRM system when you can get a service from one of several vendors for a fixed monthly fee that scales dynamically with the growth of your organization? This approach is going to solve several significant problems with todayÂ’s enterprise software when it is broadly applied to the enterprise infrastructure. CRM is just a small example and the tip of the iceberg, when software as a service is used to build and deploy applications the economics are such that it becomes fiscally irresponsible not to consider this approach.

The current model of enterprise software is not aligned with the needs of corporate IT organizations its inefficient, cumbersome, and non responsive to the needs of companies. Measurements of return on investment (ROI) are, in many cases, optimistic at best. The percentage of failed projects by some accounts exceeds successful projects. While there have been and there will continue to be many successful deployments they are the result of careful planning and significant investment of a companies best and brightest IT personnel to ensure success. If the best and brightest are used to ensure successful rollouts - who is creating the business processes and applications that make the business successful? What percentage of the total IT effort is devoted to this?

Apart from the time to deployment and the inherent complexity of the current enterprise software offerings there is an even larger hidden problem. The actual value delivered when taken, as part of the total costs of development of the software is low. Enterprises pay a “portability tax” when buying software, the more complex the software the higher the “tax”. This “tax” is the costs that go into making the enterprise software portable and compatible with the underlying operating systems, databases, application servers, mail servers, directory servers, etc. These costs contribute almost no value to the business objectives of the enterprise yet they can be a significant part of the cost model.

When these costs, of developing, deploying and supporting enterprise software are taken into account the amount devoted purely to ensuring that the software is designed to be run, deployed and supported on a variety of platforms is significant. Based on many years of experience I would estimate that anywhere between 30-70% of the total costs are devoted to cross platform issues. The upper range is for software that utilizes as many native (propriety) platform features as possible and the low end for software designed with a lowest common denominator approach. While this estimate may seem high, consider not just the actual coding efforts but all the other efforts. How much time in the requirements phase is spent discussing and evaluating which combination of platforms to support, which patch releases to support, and then how to design the software to support these features. Every time a new feature is added there is a design discussion on the cross platform impact. Add to this the test matrix and support infrastructure the costs continue to mount, but the value to the consumer of the software does not.

The impact of all this on the customer is that a significant part of the cost of enterprise software provides no significant business value to the enterprise. This has not been questioned, as there has been no viable alternative to this model. Now a viable alternative is being widely deployed through software as a service model.

Software as a service has become viable through three trends that have converged to create an opportunity for enterprises to drive significant costs out of their software purchases, provided faster response to market conditions, and reduce infrastructure. The three trends are SOA, broad availably high-speed connections, and web services. These trends enable software to be delivered as a service – producers of services make services available on a SOA backbone, and then consumers can use the features inherent in the network to create applications by weaving together different services. Applications can now be created that are totally virtual and do not require hardware or software installation or deployment. Companies such as Grand Central are making the network smarter by deploying the necessary services for a SOA backbone. This is aligned with the objectives of corporate IT to build and deploy services that provide differentiation and leverage the services provided by others. The necessary framework to make this happen is not core to any one organization and as such should be shared infrastructure.

Deploying software as a service removes the significant problems with enterprise software as services only need to run on a single platform, therefore a larger percentage of the effort is in creating useful business applications not portable ones. Using shared infrastructure and other business services enables us to leverage the work of others in ways that have not been possible with the current model. The time to market or time to respond to market demands is shortened considerably as once again we are leveraging the services of others.

This will not happen overnight, nor am I suggesting that we rip out the current installed base of enterprise software. Far from it because the current installed based provides the core set of services required by the corporation and its partners today. The task is rather deciding which services are core to your business and investing in them and using services from others where appropriate. As in all technology revolutions the last generation usually remains a vital part of the infrastructure but not the only part. Software as a service is going to significantly reduce the need for enterprise software but not eliminate it. Software as a service is a more economically responsive model to the needs of IT and enables the corporation to focus more on the business process and the applications rather than the deployment of more enterprise software

posted by John McDowall | 7:13 PM

Merging Blogs  

Over the next few months I am going to merge my two blogs Fast Takes and Fast Takes - Web Services mainly because I do not have the bandwidth to support two blogs. They will both be merged into Fast Takes To facilitate this I am goign to cross post for a while and then let Fast Takes - Web Services go quiet. This is not because I am no longer interested in web services, quite the contary business is accelerating and the revolution is happening. I expect that in two years software as a service will become the accepted wisdom.

posted by John McDowall | 7:12 PM

Enabling Process Entrepreneurs  

Phil Wainewright describes the next wave of innovation for IT in Loosely Coupled weblog - Process entrepreneurs. With the release of the BPEL Service on Grand Central we have enabled all these process entrepreneurs. The ability to create business services without requiring massive (any) infrastructure is changing the economics of the value chain. Optimizing the value chain has suddenly become possible without massive investment.

In the past to create business processes between organizations required massive investments in time, software and hardware. These barriers to creating business processes have now been removed, this means that every dollar invested in business process development goes to business process development rather than 90% to building the infrastructure and 10% to the process. Imagine a world where you can orchestrate your value chain without first having to build the plumbing - it is here!

posted by John McDowall | 4:48 PM

BPEL as a service  

We have just launched our BPEL Resource Center along with the Grand Central BPEL engine. This new service demonstrates both the value of SOA and the network service model.

Using the new service I can provision new BPEL services into the network (I use XML-SPY, it provides a really cool edit, run, debug approach to progamming Grand Central) without having to deploy any software, hardware etc. This ability to create virtual processes that are completely managed by the network allows developers to focus on the hard business process problems rather than deploying, configuring and managing infrastructure software. Once the services are deployed they are registered in the directory and can then be reused and choreographed into more complex business process.

posted by John McDowall | 8:01 AM

Will Web services kill the browser….  

Web services have the potential to reduce the importance of the browser as a part of the technology stack. The browser has become a vehicle for delivering more and more complex applications due to its ubiquitous nature on the desktop. Unfortunately it is becoming harder and harder to develop browser based applications because the data is becoming richer and hence the demands on usability are rising.

Web services are unlocking more and richer data to be delivered to the user. This is putting pressure on the browser applications from two fronts, one is the richness of the data and the other being time to market. As web services make it easier to access data from the value chain the impendence mismatch in developing rich applications will grow. Developing sophisticated applications in the browser today is unnecessarily hard, mainly due to the fact the browser was not designed to be a rich applications environment.

Other approaches such as Java Applets require too much to be downloaded and installed. The platform of choice for the future will probably be Office. Office 2003 has full support for web services. This significantly reduces the impedance between the XML dataflow and visualization. Currently to get information from an application to the browser requires moving through several technology layers. This impedance has been significantly reduced by web services. There is only one step between the data and visualization now, whether the visualization is a form, a report, a graph or a spreadsheet. Office has the same degree of ubiquity as the IE and a much richer interface for data.

To be able to go from web services to a rich user interface using a single development paradigm (XML) and in a single step is going to dramatically simplify development. It might also reduce the application backlog in the enterprise and reduce the number of rogue applications.

As more information is offered, as a service that can be consumed by desktop applications the data should become better managed. The need for separate information silos will decrease, as the need to move data from the web to the desktop will be removed. The move to a service oriented architecture based on the flow of XML through the value chain will truly enable the real time enterprise.

posted by John McDowall | 2:43 PM

Headers, bodies and namespaces  

In More on REST vs. SOA; who's more loosely coupled? Mark makes some interesting arguments. The key difference I have with REST versus SOAP is in the headers. Turning the WSDL for the body of SOAP into "" allows very loosely coupled messaging with SOAP. SOAP and WSDL sometimes get tangled together into the mythical publish-find-bind trinity. WSDL is a common language for describing the interface to a service but does it need to constrain the implementation? The advantage of using messaging or data passing interfaces based on XML Schema is that they are evolvable i.e. loosely coupled. WSDL should not be considered a tightly coupled straight jacket rather a common language for describing interfaces. How we use the interfaces determines the degree of loose coupling.

The major advantage that SOAP has over REST is namespaced headers. To do truly loosely coupled and sophisticated messaging you need complex namespaced metadata. This is what enables loose coupling in a complex SOA architecture used by many different organizations. If you have a single organization using an SOA it is possible to get by with a single flat namespace. Implementing complex features between several organizations such as guaranteed messaging, business policy, and compensation transactions requires more sophistication than a flat namespace can provide.

While headers can be implemented in REST the key is reducing friction by getting agreement between implementations. We have managed to reduce the Tower of Babel to 2-3 implementations at the higher end of the stack. While this is not perfect it is better than a large n and being namespaced they will not collide. I will take that anytime over making it up as I go along.

posted by John McDowall | 6:32 PM

Enterprise Architect - 10 Rules for Services Design  

Just published a more refined version of the Rules.Enterprise Architect - 10 Rules for Services Design (registration required).

posted by John McDowall | 5:52 PM

It is the journey not the destination....  

By way of Doug Kaye an article by Ron Schmelzer at zapthink is worth reading Semantic Integration: Loosely Coupling the Meaning of Data

The article highlights some of the problems inherent in how we think and build applications today. Data is an inherently static concept in today's systems and it needs to be thought of as dynamic - data is moving and persistence and presentation of data should be considered side effects. Until we start looking at the flow of data in complete value chains we will continue to build immobile applications silos. Business processes are all about acting on flows of metadata and data. Value chain architecture is about reducing the friction in these flows and increasing visibility of partners and enabling richer semantics to flow

posted by John McDowall | 10:56 PM

A rational for service mediation  

In The 2 pin theory Jeff Schneider makes (perhaps unknowingly) a very good case for a service such as Grand Central. To do the dynamic negotiation that he illustrates you need a service to do the mediation, otherwise everyone must support all known technologies. As most companies are focusing on supporting fewer technologies and focusing on solutions the case for Grand Central becomes obvious.

posted by John McDowall | 10:01 PM