Prime Time for Real Time

Companies that get to market first and respond to customers fastest win. But the same old time-consuming software development approach won't deliver the real-time dream. Here's why process management is key to speedy customer service and turn-on-a-dime product and service delivery.

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.

Cover Image
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

The Brief
»"Real-time enterprise" is more than a technology concept: It's fundamental to the way businesses compete. Business analysts and IT enterprise architects must focus on technology goals that will push time-based competitive advantages to the next level. Improving cross-functional, end-to-end business processes can have a major impact on responsiveness to customer events, supply-chain snags,or immediate market opportunities. Business process management systems (BPMSs) merit your attention as the underlying technology to support real-time enterprise demands.

» Evaluate BPMS technology to support cross-functional processes. While ERP and other applications can bring efficiency and speed to workflow and transaction management, meeting real-time enterprise goals generally involves end-to-end processes that cut across functions. Living at a higher tier than applications, the BPMS can draw on appropriate underlying applications and systems to achieve cross-functional process success.
»Create a service-oriented architecture (SOA) for application and information integration. Moving toward simpler interfaces and less proprietary integration methods will ease time-consuming bottlenecks and set up a more flexible integration infrastructure for processes.
»Choose development tools that enhance processes. Traditional integrated development environments enable rapid application development. Look for tools that help you shift focus to process modeling, management and integration.

»Does your organization have a clear business view of the real-time enterprise? Goals and metrics should address customer satisfaction, supply chain efficiency and other strategic objectives — not just the automation of existing processes and transactions.
»Will software tools and architectures adequately support cross-functional processes? Producing more software faster isn't going to be enough — and could get very expensive. Organizations need process analysis and management excellence to be agile and responsive to real-time business events.
»Can BI and information integration keep pace with processes? Data warehousing is often in a separate world, supporting standard reporting and strategic analysis. Cross-functional processes will demand timely, integrated information at every step.

Action Items
»Develop a business view of processes. Executives, business analysts and IT architects must see the forest, not just the trees, to understand how best to remove time obstacles to more dynamic, responsive business behavior.
»Adopt SOA and XML approaches to integration. If it takes an army of programmers to overcome proprietary roadblocks to smoother application and data integration, evaluate whether industry standards could get you closer to real time.
»Aim development at processes, not just software. A BPMS is not just an extension of the software stack; it should be on a different level, closer to business strategy. Developers must understand the difference so they can model and build open, cross-functional processes that deliver real-time business benefits.

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 ( Write to him at [email protected].