This blog was originally posted on the CloudSource blog in April 2013
In my last blog entry I promised you I was going to come back to service orientation. So, let me keep my promise. Let me actually start with a story.
More than 10 years ago some colleagues and I worked with two financial institutions on projects to combine workflow management and object orientation. How did we get there? In discussions with the customer we came to the conclusion that a typical financial services process consists of multiple steps. The actual steps do not change typically, but which steps are used do.
We were trying to develop each process step as a stand-alone object drawing only on information, not on the object calling it. We would then assemble those objects using a workflow engine to trigger the object and data structures to exchange information. We actually developed a financial services environment for both companies using these principles. The compute power available at that moment made it challenging, but ultimately we achieved success.
Separating elementary transactions and business processes
As I just mentioned elementary transactions mostly don’t change, but business processes are more volatile. If we could separate the elementary transactions from the business processes in the same way we separated code and data years ago, we could improve business agility drastically.
In my banking example, we did that using a workflow engine calling independent objects. We even went further by handing the responsibility of the workflow over to the business teams, while IT retained the responsibility of developing and maintaining the independent objects.
In our case the workflow engine had an intuitive graphical designer that could easily be used by the business people to design their processes. Can we take a similar approach today? I believe so.
Linking services to deliver value
Let’s fast forward to today and replace objects by services. Let’s develop a number of services; each performing the activities of one process step and let’s have them aggregated using an orchestration engine.
Service Orientation should be the basis for development of such services. So, each service should adhere to the 10 principles of SOA. Is that actually enough? I believe no and let me explain why. The key SOA principles include the possibility to transfer information from one service to the next. It limits this capability and proposes the information is transferred using XML documents.
But the concept that one service triggers the next one in line implies the business process is embedded in the services, and that limits the use of the service. Indeed the service is contextual and includes part of the business logic. What we want is a service performing exactly ONE task, regardless of who triggers it.
Combining SOA and orchestration
How will this work? A graphical design tool is used to draw the business process and link the services together. A service library is available and used to choose the individual business steps by identifying which service delivers the functionality required during the business step. The source of the input data that has to be provided as well as the place where the output data is stored, are defined in the business process so the actual service remains independent of the context in which it runs. Status information may also be provided. That information will highlight whether the service is performed successfully or not. The business process needs to define what action is required in case of success and failure.
Failure may not be something bad. For example if one step in the process is “search for the customer information” and we have a new customer, obviously, the service will return a fault as it cannot find the client. So, a faulty response may trigger a new service consisting in entering new client information.
When a user initiates an instance of a process, what happens is that the orchestrator initiates the execution of an instance of the template that was designed to perform the process. The first step is executed by calling upon the first service identified in the template and providing it with the appropriate data. Once executed, the service returns its results as well as status information identifying success or failure.
This same service can be used by another template instance (maybe another instance of the same template, or a different template that happens to call upon the same service). Cloud gives us the capability to scale up and down at a service level, so limiting the bottlenecks we found in the early, object oriented, version, where we ran out of capacity for some services.
What do we need for this?
As I already mentioned, we need a simple graphical process designer, allowing business users to describe and change their business processes. They will call upon a service library in which the individual services and their characteristics are defined. Ideally through a drag and drop approach, the services can be lined up so they perform the business process.
Those services can actually reside on different clouds. Some of them will be local. I’m thinking for example about services that recoup information from enterprise data reservoirs. Others will be in different clouds and access information needs to be contained in the business process template.
The user will still have a catalog, but this is now a business process catalog, not a service catalog. Each user is provided with the business processes he or she is allowed to access, so the catalog no longer addresses the provisioning of a service, but triggers the execution of an instance of the business process.
The role of IT
As already mentioned in many occasions, the role of IT is changing. IT is responsible for maintaining and evolving the cloud platform required to run the environment I described above. And IT is also responsible for the design/development or sourcing of the services required by the business. The business on the other hand is responsible for the design and management of its business processes. This fundamentally changes the role of IT. It is no longer responsible for digitizing the business processes as it used to be, but for the provision of building blocks and the environment in which the digital business processes will run.
We may be moving to a SaaS model, but SaaS meaning Service-as-a-Service. Individual services, paid per use, are consumed by the users as they trigger their business processes. ISVs provide libraries of services. Will these be the existing enterprise apps ISVs or new entrants? That is a good question. As the market shifts, companies will have to adapt or they will become “exhibits in the museum of corporate dinosaurs” as Alvin Toffler wrote in his book “The Adaptive Corporation” nearly 30 years ago. I’d add that companies whose IT department is not evolving in such direction will probably go the same way as our business environment increasingly requires agility and responsiveness only a close management of business processes provide.