Architecting for Flexible Processes
One of the main issues with technology is the way it has grown up. Applications were generally originally written to automate processes or tasks that were too boring or onerous for employees to carry out. The speed of the computer meant it could carry out simple tasks more efficiently than a human. This led to the rise of applications managing areas such as claims handling, mortgage offers, and so on. The unswerving focus of a computer on a specific task also makes mathematical modelling a strong point, enabling the computer to deal with massive amounts of data where a single human would just not have the capability to see patterns and inter-relations.
Beyond this, computers have moved up the information value stack and can also now be used to build on the capabilities of knowledge workers and existing business processes. This has led to enterprise applications, such as enterprise re-source planning (ERP) and customer relationship management (CRM) being brought to market. While businesses still moved at pre-computing speeds, this was all to the good, but once organizations saw that they could combine raw power with efficiencies, the processes encoded within many of these applications became an issue. The problem lay within con-fusing “efficiency” with “effectiveness.” If the business process involved was now wrong for the business, throwing more speed at it was counterproductive: all that happened was that a company that was going out of business was now doing so at a faster rate. What was really needed was the capability to apply the right process at the right time to any specific problem.
However, this was not immediately possible because many of these processes had been hard coded into the applications, and the new, computer-speed markets needed processes that were far more flexible. To address this, niche players grew up offering rules engines that could create process flows and deal (to an extent) with exceptions. In doing this, many areas such as governance and audit became bigger issues, as the workflow engines within the enterprise application could only deal with what happened within the application itself and tended to lose track of what was happening once the work-flow moved out into these peripheral systems.
The issue was also compounded by the general lack of an organization’s ability to describe its own processes. An end-to-end process can involve many different person-to-person, person-to-machine, machine-to-person, and machine-to-machine activities. Each of these tasks are far easier for people to describe than any one person trying to describe an end-to-end process.
Each task needs a set of inputs and results in a set of outputs. In an optimized process, each set of outputs meets the exact needs of the next task’s inputs. However, this is rarely achieved, and individuals and automated tasks find that they have to fill in some details from other sources—sources that may be out of date, may not be in context, and may compromise the overall process.
When architecting a platform for a process-driven organization, it is necessary to look at how IT and the business come together.
Figure 1 shows how the organization has a business imperative, which outside of public sector organizations is generally to make as much profit as possible. This imperative is supported by business processes, which are facilitated by aggregating sets of tasks as outline earlier.
From the technical point of view, there is the basic IT platform, on which a set of applications are run. These applications provide sets of technical functionality, increasingly being made available as part of a “service oriented architecture” (SOA).
The trick is to match the needs of the business tasks to the capabilities of the technical functions. By taking this approach, it becomes easy to identify the gaps, and from there, to work to fill these in. In many cases, this may be through adapting existing functions to do as required. Increasingly, it may be that these functional gaps are filled by going outside of the organization to the cloud, subscribing or paying-per-use for what is needed on an ad-hoc basis.
Such a task/function approach has a major impact on the flexibility of a business going forward. Historically, application implementations were measured in months or even years, meaning that the process issues they were put in place to fix were first seen in the distant past. Either the process problem had disappeared, been worked around, or had changed out of all recognition by the time the “fix” was in place. Even if it was just part of the process or rules engine being changed, it could still take weeks: an age in today’s markets.
Today, by taking a process- and task-based view and utilizing the power of cloud-based computing, changes to business processes can be carried out in business time. Aggregate or composite applications that facilitate the overall process can be constructed on the fly, and how that composite application was constructed and used can be fully tracked for audit purposes. If the markets force the need for a process change on the business, the composite application can change. If a new campaign requires a new approach, then put in place a new set of processes—even if it is only for the duration of the campaign. A new political world, leading to new legal audit and governance requirements? Respond immediately, ahead of the competition, and adhere to the new legal requirements. As the process needs change, the tasks change. As the tasks change, the technical functionality required changes. Monolithic applications, strap-on peripheral solutions, and complex means of dealing with exceptions that are often the new rules just don’t cut it for today’s organizational needs.
By architecting for flexible processes, IT gets to where it should be—a firm underpinning to the business, a service that facilitates business in a changing world, rather than a constraint as has been seen in many cases today. The approach does not call for mass replacement—instead, it builds on what is already in place, optimizing existing assets while minimizing the need for expensive new implementations of hardware and software.
All businesses and organizations are built around processes—shouldn’t IT be built around making sure those processes are facilitated in the best possible way?
by Clive Longbottom, founder of Quocirca, a company that provides research and analysis across a wide range of business and technology areas. He can be reached at Clive.Longbottom@quocirca.com.
