A theory on the future of software and services by Tim Wheeler.

6th September 2008

The Premise: 

As a business owner, I want to construct my systems, from inter-connectible services and resources.

The Situation:

Custom software development is both costly and time consuming and the return on investment is an important issue.  Compounded by the realisation that the ever changing nature of business means the software we write today maybe obsolete tomorrow. 

In opposition to custom built software, you can buy off the shelf products.  These vary in cost, but in almost all cases will never have all the functionality required.  It also suffers from the paradigm of "Software built for today maybe obsolete tomorrow". 

The Problem:

There are many problems faced by business in the realm of IT and computer systems.  Some of these problems are:

• Software development costs


• Software licensing costs


• Infrastructure costs


• Maintenance costs


• Vendor lock-in

Businesses are in a constant state of flux, a balance between risk and cost.  Consider "Its cheaper to store our data at a hosting provider, but what is the risk of them seeing our data?" 

So there is an ever changing need to balance this risk.  The need to change is dynamic, however generally IT systems are not.  Where should our services live, on premise or in the cloud? 

Consider an on-line ordering company, that require the scalability of a large service provider so they are  always able to meet demand.  If the data is hosted, what is the risk of credit card numbers being leaked from staff within the hosting company?  What if you could reconfigure the system to store credit card details on premise or with a dedicated security company with minimal time or cost?  What benefit would that have for the business and how would that increase the agility of their IT system?

The Question:

How can business systems keep up with an ever changing business?

At the moment, they generally can't.  Workflow systems are a step closer to this goal, but are only part of the puzzle. 

The Cause:

Why can't my IT system change as my business does?

Because everything we do is done slightly differently, tailored in some way for the client, for the requirement for the technology.  The way I access services in one system, is different to the way I access services in a different system.  

If there is one thing we have learnt in IT, there will never be 1 way to do anything.  Technology changes, but often the principles do not.  For example; the detail of saving data in a database will be different between say Oracle and Sql Server, but the way I need to interact with that data does not.  To be more specific the "interface" can stay the same.  This concept was noted many years ago as polymorphism.  We see this problem answered in ADO.Net and even earlier ODBC.  The answer was "We will separate the detail from the interface."  This allowed Oracle and Microsoft and others to provide their own "Driver" or "Provider" to be accessible via the same interface.

The Solution:

Almost anything we deal with within an IT system is a Resource supplied by a Service.  A Resource is any type of thing, and a Service is any mechanism for providing it.  For example; If you ask a server for some data, the data is the Resource and the Database Server is the Service. If you ask a Workflow Engine to complete an activity in a workflow for you, then the Workflow Engine is the Service, the Workflow is a Resource, and the Activity is a Resource. 

If all these things are just services and resources why are there so many ways to interact with them?

Albert Einstein reputedly said "Solutions to problems should be as simple as possible, but no simpler".  Keeping this quote in mind, and looking at the REST theory, why can't we have a simple way to access All Resources?  The HTTP protocol has defined all the things we will ever need to access any resource.  We have a way to identify a resource (URI), a means to interact with it (HTTP Verbs, GET, PUT, POST, DELETE), and a way to transport it (HTTP Protocol). 

The protocol will stay the same, what we transport over it will change.  So let's separate the the detail form the interface. 

Consider the key parts of most IT systems:

• Workflow


• Data


• Validation


• Security


• Interaction


• Schema's

These can all be services that provide resources.  Let us use the simplicity of HTTP to interact with these services.  Let's provide a uniform mechanism to access any resource.

Here I define the concept of a "Uniform Service Provider (USP)".  This provider can be on the cloud or on premise.  It defines a common way of accessing resources.  Many companies will be a USP and exist to provide different things in the same way.  Business owners can select a prebuilt workflow or a custom built workflow and store it in a USP.  That workflow may consume data services provided by another USP.  The business will use Well Known or Less Known Schema's, identified by the URI and stored in a USP.  As the business changes, it can move its resources between service providers to take advantage of price competition.  If a business uses a Well Known schema, then they can create, lease or license a user interface resource to manipulate data resources.

This solution may not suit business today due to a rationale of thinking, which is "We need to build a system to support our business without considering optimising how our business interacts with our technology."  This type of thinking might cut all generic service offerings from the short list.  The real question should be "How can we change our business to support a service and resource orientated system where we consume commodity services, and still have the flexibility to create custom workflows to model our business processes?"