Is Architecture the Answer?
How do companies aim for dramatic results such as this? Because surely this is the way to keep the IT budget coming your way. One way to address the problem is through the archtectural approach.

The architect's role in working with projects that span organizational silos is to stand back and look at the interplay among systems, information, business processes--and the people involved in them. Observing the interplay, a simple question arises: Do all of these pieces fit together smoothly and provide the solution that the business requires?

IT managers are often incentivized to deliver local optimization within their own particular silo. But an information architect must take the global view and strive for global optimization. To see across the silos, architects must therefore understand end-to-end processes and questions about these processes:

• What does each silo involved in a particular business process need to do.
• What changes need to be made on the development side?
• What operational changes need to be made to execute the business process?

Yet none of this matters if architects lose focus on getting business value out of these processes. It means something like shrinking the timeframe for designing or changing a business process from weeks to hours. This sort of dramatic change requires improvements that impact multiple silos.

But it also requires a very clear, upfront understanding of what magnitude of improvement is desired or required. This may seem like an obvious point, but it is nevertheless one that is often overlooked.

As the prominent architect and book author Paul C. Brown has noted, "If you want a 5% improvement, just make people marginally more efficient and you've succeeded. If you want a 50% improvement, you better take half of the work that was formerly done by people and automate it. If you want a 95% improvement, you better be taking that formerly manual process and completely automate it, using people only for rare cases of exception handling."

The high-level design (ie, the architecture) remains critical, to ensure that everyone is reading from the same, detailed playbook. Within that context, it is essential to take a real long look at automating processes.

The human touch will never disappear from successful businesses. As we sit here today, we can look back onto decades of research into computer cognition, artificial intelligence, expert systems, and all the utopian and dystopian scenarios envisioned by computers getting "smarter."

But as the author Terry Winograd has noted recently, computers will never be committed to doing the right thing. Give it what you think is every possible option to provide a specific action while serving customers, there will always be some new contingency that only a human being can handle and will want to handle.

So the idea of process automation for customer service remains valid, as long as there are humans around to manage these systems and get involved directly when necessary.

Brown also advises architects to remain aware of "the spectrum from implementing raw functionality on one hand versus a fully fault-tolerant, high-availability solution on the other. The latter approach can cost 4X as much as simply delivering raw functionality, so it behooves organizations to be very clear where they want their costs to fall within that broad price range."