First Cure: Process-Driven Architecture

An architectural approach is essential to managing complexity, says Motorola CIO Patty Morrison, and you need one mapped to business objectives.

"You very, very much need to have an end-state architecture in place -- a description of where you're headed," she says. That architecture cannot simply be for the IT infrastructure -- the network, the data flow to and from the ERP systems, the security checkpoints, the application monitors, and so on. IT-oriented architectures tend not to take into account the flexibility needed to support changing business processes. Rather, Morrison says, the CIO's architecture has to be driven first by key business processes.

Imagine what a failure a plane's design would be if its creators didn't take into account the fact that different customers may have different uses for the planes -- some desiring multiple classes, some looking for different cargo-passenger ratios, some serving long-haul destinations and others short-haul. Ignoring those factors would result in a plane that flew but couldn't adapt to its customers' business needs. The seats might be movable but not the lighting -- a seemingly minor detail, but one that might prevent airlines from configuring the seating to differentiate between first class and coach. In the same way, a business with a technology architecture that isn't created in service of current and anticipated business needs will be limited in what it can do. Change will require expensive retrofitting of technology to handle what the architecture hasn't anticipated.

At Motorola, Morrison ensures that her architecture accommodates and anticipates business goals by using business process management (BPM) principles and an enterprise reference architecture to define a common language for business and IT. The enterprise reference architecture is a broad set of blueprints that shows the business, operations and systems layers.

This approach also ensures that business-IT conversations don't devolve into throwing requirements over the wall, an approach that usually adds complexity in two ways. One is that IT fulfils the business's requirements outside the overall architecture, often leading to multiple ways of doing the same thing. These processes must then be reconciled, which frequently requires custom interfaces for other systems that no one (certainly not the business) realized would be affected. The other complexity add comes from IT's interpretation of those over-the-wall requirements. It usually misses something, leading to multiple rounds of rework and patches that make the final system ever more complex. By contrast, the architecture-based approach at Motorola "creates a rich, interactive, high-quality conversation around real solutions, not abstracted requirements," says Morrison.

But, she acknowledges, it's not easy to achieve this state. It requires that business units think beyond their immediate needs and work with other units toward a common approach.

"The hardest thing for IT to do is to get business units to agree on a common way to do something," says Morrison. That takes maturity in working across silos. Without it, business units end up clamouring for their own unique variants of, say, customer information. And that adds complexity.

With the architectural groundwork established, Motorola uses modelling tools first to design the desired business processes and then to simulate and test various technological approaches to delivering them. For example, Motorola used this approach to reduce part qualification cycle time -- a process of evaluating which suppliers' parts meet the quality, cost and other requirements for planned Motorola products -- from 28 weeks to seven weeks in 2006 while improving visibility and controls over the process.

Having an enterprise reference architecture doesn't mean an organization has an immutable plan. Because both business and technologies change, you can't always have a multiyear plan for a specific result, says Mack Murrell, vice president of IS at Dow Chemical. For example, you shouldn't develop a service technician scheduling system that depends on a specific wireless network, or is limited to servicing only the kinds of products you currently offer. Instead, "you want a set of options within your target," he says.

For example, you would ensure the application is network-agnostic and supports both always-on connections and intermittent connections. You would not hard-code product specifications but would instead rely on a metadata approach that supports a range of possible product characteristics, and could support a variety of information types (say, video and PDF) even if they're not needed today.

That requires an architecture that anticipates and enables change. To do this, Dow deconstructs its enterprise architecture into discrete subsets (such as purchasing, plant maintenance and pricing) and layers (such as business system, technical and products). Dow uses structured enterprise architecture methods and service-oriented architecture approaches to manage the subsets and the changing relationships among them within the overall architecture.

Dow has a group of IT and business staff whose job is to track these subsets and make sure they conform to the overall architecture -- or adapt the architecture if that's what's needed.