Economic shifts from the fallout of 2008 are challenging long-term financial planning and inducing companies to be more productive and efficient, but at the same time more responsive and Agile. While mobility is allowing workers to be targeted at every moment, the cloud
Service-oriented architectures can help frame the IT side of a business transformation, but poses new questions:
- Are we leaving a workflow age for an event-driven age?
- Is enterprise architecture (EA) forcing inefficient IT models on us?
- Can we govern applications as loose federations of elements?
From the perspective of an IT revolution, service-oriented architecture (SOA) is a gigantic positive step. Software is componentized, framed as Agile services with loose coupling and composed into applications using a business process-oriented language (such as BPEL). SOA has preserved the integrated model of application development while adding flexibility to workflows that link people and IT elements to solve business problems. While other technologies challenge SOA, the biggest obstacle may come from the forces driving business transformation in the first place.
Workflow and the IT revolution
Mobility is probably the most significant evolution in productivity since the personal computer. A worker can be linked to a company's IT resources through a simple handheld device, making empowerment limited to a specific employee, not his or her location.
The challenge is that every empty desk has an In and Out box. Those boxes show that workers have been workflow-driven; however, employees are event-driven like in the real world. SOA, as most architects know, has focused on workflow and orchestration. How is this fixed?
Mobility is probably the most significant evolution in productivity since the personal computer.
The answer is back-end orchestration. Instead of pushing work sequentially through processes, a modern SOA application has to allow process flow events to proceed in parallel, subject only to its information dependencies. The goal is not to sequence tasks, but rather to organize the results in a way that maps how the completion changes the state of the business process.
Can something else, some new service, now be run? Is there now a manual process to invoke? Instead of doing a list of things, a modern SOA process does everything it can at any moment, and things advance as a collective result of discrete service/event activity.
IT model design and structure
The second issue is the way that EA influences software design and structuring. For a decade or more, it has been a doctrine that EA should focus on business processes and not on IT tools. There is a specific handoff between EA and software architecture at the end of functional/process design in nearly all EA methodologies. The problem is that tools and business processes are inter-reactive -- you can't frame a process without considering how it will be supported.
The traditional EA model tends to create linear flows because people that is how people think. Those linear flows are then hardened into workflows, a process that still works today. However, as we become more mobile-aware in productivity planning, those flows can't hope to be workable in the future.
What's needed is a formal overlap between EA and software architecture at the functional/process design phase. The goal is to remove a specific notion of flows and focus on individual workers' tasks.
Each worker has something to do and a set of IT tools to use. The pairing -- not the steps that may be an artifact of how we do things -- is important in structuring business processes. IT services to the worker are retrojected into EA processes so that event-based outputs emerge and align with services on a task basis, not on a workflow basis.
Where governance stands in the IT revolution
SOA as it's used today provides a strongly structured definition of service/process inputs and outputs (via Web Services Description Language), and a business-tuned description of sequencing processes (BPEL). As worker empowerment becomes more event-driven and businesses transform to deal with that, the rigor of these definitions can be lost. In particular, a pure event-driven framework has to either remake its notion of a workflow or figure out how to enforce process rules on a disconnected set of event-driven tasks.
More on the
People's role in the IT revolution
CIOs must lead big data revolution
Leaders urged to think forward
As services are redirected from steps in a workflow to tasks that support worker needs, task-level governance must be considered as a service in parallel with task functionality. You cannot overlay governance on an event process; you have to bind it to the way you address events. That means there is, in effect, a governance layer behind the services, which provides security and policy coordination. Worker-generated events are then linked with governance practices, as they would be to database resources.
The same principle is needed to bind event-driven processes into complete applications or business processes. As workers complete tasks, they are essentially ticking off something on a manifest of things that must be done. Each tick changes how later events -- representing later process steps -- are treated. This event-driven check-off must push the way future events are interpreted, rather than be a linear description of workflow. Governance can be added at this level by ensuring that compliance requirements are met by the accumulation of event-driven tasks.
Every business process is not event-driven; assembly lines show some tasks have to be sequentially scheduled to make sense. Nevertheless, the transformation of legacy processes demands the exploitation of new techniques and the reflection of new work practices. SOA can have a role in the future if it evolves to face that future squarely.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
This was first published in November 2013