Composite applications are delivered over an ESB on which discrete, distributed services connect to each other through an asynchronous, message-oriented communications infrastructure. First Command Financial Planning, which serves active and retired military families, deployed Sonic Software's ESB to provide an integration layer to exchange information between its BEA-supplied Web portal and an IBM iSeries platform with third-party financial applications on the back end. As a result, customers can now see real-time views of their financial positions.
In many cases, IT vendors have produced integrated development environments (IDEs) for this type of distributed programming, to make it easier for programmers to build composite applications from Web services. This is a natural evolution in software development. The objective, however, is still to develop software applications — more and more software, more and more applications, keeping business automation squarely in the hands of technicians and on the path of software development.
|Service-oriented architecture and enterprise service bus are feeding the real-time enterprise, but it flourishes at the process level.|
But wait a minute: Isn't the objective to develop business processes, not more software? Doesn't the real-time enterprise need to craft or modify business processes at the speed of business, sometimes on the fly, not at the speed of software development cycles? To move time to the center stage, companies need a direct business process management capability — a native BPM system (BPMS)— not a programmer's application server.
Because business processes should be in sync with naturally dynamic business initiatives, you shouldn't view real-time enterprises as just larger edifices built with the same "concrete" as transaction systems. The real-time enterprise is about fluid, dynamic, flexible behavior, and that's something that BPM uniquely supports. Think of the BPMS as a CAD/CAM system for process work — it's a user of the technology stack, not part of it. Automobile designers don't require programmers to code their designs; they use CAD/CAM systems to directly manipulate automotive artifacts. Likewise, business analysts shouldn't need programmers to code their designs; they should be able to directly manipulate business processes. They shouldn't be limited to serving up requirements specifications that will be fed into the technologists' alphabet soup of BPMN, UML, BPEL, BPEL-J, WSDL, SOAP and UDDI and then simmered until done. Their requirements must be met now — implemented directly and immediately, not after countless translations through the technology stack.
When an accountant designs a spreadsheet, the design isn't translated into requirements specs, then design specs, then coding specs — it just executes. Similarly, with a BPMS, process designs just execute. Think of Web services and SOA as an underlying technical operating system for the BPMS, which, in turn, is the engine driving the real-time enterprise.
The Process Paradigm
A distributed computing infrastructure is necessary, below the soil, but it's not enough to let companies create processes that differentiate them from their competitors. That's the lesson Progressive learned when it first became a time-based competitor. The company continues to innovate with time-saving processes that delight its customers.
There aren't enough programmers in the world to design and code process-oriented systems using conventional software development, even with the aid of service-oriented software development methods. Processes need an architecture and a paradigm of their own, not a data-oriented information systems paradigm. Just as spreadsheets are placed directly in the hands of businesspeople without the need for a cadre of support technicians, BPMSs must be turned over to business analysts.
What's needed to get to the real-time enterprise isn't just a technician's SOA, but a process-oriented architecture (POA) that, as author and business process methodologist Martyn Ould describes, centers on "units of work," not "units of technology." A POA is a blueprint, and it is to the BPMS (an execution engine) what SOA is to the ESB. IT architects refer to units of work as discrete transactions; business architects define them as sets of processes that come together to get work done and deliver value to customers. It's time enterprise architects start talking about units of work in a business context. Software developers have used unified modeling language (UML) diagrams for years to specify and design software, but UML lacks business semantics — it's from software engineering sphere, not the business process modeling world, for which it was never intended.
As Ould writes in his recent book, Business Process Management: A Rigorous Approach, "Today's dedicated follower of fashion in information systems development is likely to be speaking UML and using one of the various development approaches based on the UML. We cannot view the business process management systems as just another sort of information system."
Information-oriented languages and methods have evolved around storing, retrieving and updating information, not the dynamic world of process. "We're moving from the Information Age to the Process Age," Ould elaborates. "We need purpose-built methods for working with processes to replace our methods for working with information."
The real-time enterprise demands that the center of automation shift from information processing to process processing, for it's the actual operation of the business — doing the work itself — not the recordkeeping that's the objective.
Again, the real-time enterprise represents a management strategy, not a new killer-application technology. If operational transformation of the kind realized by Progressive or Virgin Mobile is indeed the next frontier of business advantage, IT must move from the Information Age to the Process Age to enable time-based competition. The real-time enterprise is the process-managed enterprise. It's indeed prime time for real time in the world of business, but is your company ready for this extreme competition?
Processes for Prime-Time Business Advantage
Peter Fingar, executive partner in the digital strategy firm, the Greystone Group, is the co-author of several landmark books including The Real-Time Enterprise: Competing on Time (www.mkpress.com). Write to him at [email protected].