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 has not 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. Firstly 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) realised 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.