Business Process Management Architecture Enterprise System : Keeping the end user in mind as you design the enterprise architecture can eliminate drag on the IT department, users, and ultimately on the bottom line. Let's look at how applying an efficiency filter to enterprise architecture can help an organization increase productivity, paving the way for cost savings and growth.

---

by Chris S. Thomas, chief strategist, Intel Corp.

Are your users free to do what they do best while their computers handle the grunt work? It's all in the architecture. Part 3 of 4.

Keeping the end user in mind as you design the enterprise architecture can eliminate drag on the IT department, users, and ultimately on the bottom line.

Let's look at how applying an efficiency filter to enterprise architecture can help an organization increase productivity, paving the way for cost savings and growth.

Efficiency as a sum of its parts
Achieving greater efficiency—and the labor and cost savings that go with it—means more than just tweaking a business process or upgrading servers. The right architecture can drive an organization's effectiveness in at least three areas:

1. User Efficiency—Enhance user productivity through offline functionality, application choice, and integration.
2. Network Efficiency—Optimize bandwidth by designing out latency and enabling occasionally connected functionality.
3. Enterprise Efficiency—Design out ongoing support and development work.

User efficiency: put people first
Everyone knows that humans are the least reliable application. To judge whether a technology solution promotes human efficiency, ask: Who's doing the work? Solutions that force users to enter data manually or to cut and paste data from application to application rank near the bottom of the efficiency scale. Yet I'm amazed at how many enterprise solutions depend upon human labor.

We've all experienced the frustration of having to redo work because our connection dropped halfway through filling out a Web form. Mark Forman, associate director for information technology and e-government at the Office of Management and Budget, is quoted in the Federal Times describing just such an occurrence.

"I spent two hours filling out a [personnel] form online," he says. "Because my Internet connection broke for a moment, I had to start over again."

Forman was describing why the people leading e-government initiatives have high hopes for Web services standardization. The goal is to make government systems more efficient by automating work that employees, contractors, and the public are required to do today. (See the Related Links section for more information about e-government projects.)

Let's look at a more efficient architecture than Web-based data entry for transactions such as Forman's personnel form.

1. Enabling offline functionality eliminates the frustration of losing work to blips in the network.
2. Offering standards-based data formats such as XML enables users to choose the most efficient application for them, whether that's a text editor, word processor, browser, spreadsheet, or automated business process.
3. Integrating with other applications can dramatically reduce the number of human touchpoints.

The user (in)efficiency factor becomes even more evident as the complexity of business processes grows into multiple layers of collaboration, integrating data from diverse sources, and accommodating approval cycles. Designing out human touchpoints is quickly becoming a recipe for improved efficiency—leading to productivity gains and cost reductions across the organization.

Network efficiency: design for occasional connectivity
Key to efficiency is reducing the network's impact on the application, shielding users from network inefficiencies and optimizing information flow. To make the network work for the user rather than the other way around, an architecture needs to eliminate these problem areas:

• Latency—Clicking Go or pressing Enter has a built-in delay as the HTML information travels to and from the server. (This response time issue isn't limited to browsers. Most of us are all too familiar with how slow email can be when composing in online mode rather than writing offline and synching messages later.)
• Resilience—Online data entry requires developers to build in layers of complex recovery procedures. What happens to the work that was in progress before the network failed? What security is in place for users to re-authenticate to get back to their work? How long and where does the system save uncompleted forms and transactions if the form can't be completed in one sitting?
• Acknowledgement—Transaction acknowledgement can be convoluted in online solutions. An HTML page saying "Thank you for your order, here's your confirmation number" doesn't guarantee that the user's application comprehends that the operation succeeded. Instead, the user must wait for the network to send some other form of confirmation, such as an email. And if the transaction requires email, why not use an email or other offline submission process to begin with? (See my magazine subscription example in Reduce Costs.)