In-Depth
Improving Business/IT Efficiencies with Enterprise Architects
How an enterprise architect can help you maximize your investment in BPM and BRE tools and other technologies.
Is your organization struggling as IT and business units work at odds? Automated tool vendors tout a multitude of benefits, some offering users more control over process logic to help relieve the project backlog within IT. If you’re not getting the greatest value from these tools, it may be that what your organization needs is more effective enterprise architecture.
The new discipline evolved from the intersection of business and IT—from the need to align business requirements and IT capabilities and the need to translate business strategy to IT strategy. Could it be the key to getting the value that vendors are promising?
There’s much to recommend bringing an enterprise architect on board, according to Vivek Mehra, director of global financial services at Keane Inc., one of the world’s leading business process and IT services firms, and a chief enterprise architect himself.
“Our clients bought business process management (BPM) and business rules engines (BRE) and all those tools, but their success rate hasn’t been very good. A large part of this is from a lack of governance, and most implementations are done in silos or within isolated divisions without taking into account cross-divisional impact rather than across the enterprise. There’s also an expectation that once installed, the tools will provide automation forever, but that doesn’t happen.”
A BPM suite of tools helps you take a process (handling an insurance claim, for example) and encode it in a tool using a visual interface rather than documenting it on paper. Its promise: making it easier to update changes to your processes. A business analyst can visually reconfigure a process using the tool’s interface, and theoretically those changes will cascade down to the systems and data level so IT doesn’t have to recode applications. Closely associated with BPM are business rules, such as “a claim with a box 14 checked must be routed to an exception-handing department.” Such rules can be stored in a business rules engine, and rule changes can be made to an automated tool (and are then reflected in an application) without asking a developer to change code.
The goal of BPM and BRE tools is to minimize coding caused by process changes. They are particularly useful when a business needs to launch a new product or service—which can be time-consuming, especially when IT must support it (probably adding the project to an already overflowing queue). The tools have an additional benefit: they force you to document the processes, which helps identify deficiencies, redundancies, and inefficiencies.
The problem, according to Mehra, is that BPM and BRE tools aren’t adopted across the enterprise—only in small pockets. Processes that cross divisional boundaries are partly in an automated tool, partly on paper—so you don’t get the advantage the tools offer. For example, they don’t help an enterprise quickly introduce a product that IT can support.
That’s where the enterprise architect comes in. Rising from the gap between business expectations and what IT can deliver, enterprise architects understand that tools must be used throughout an organization. They understand the business goals and priorities, what IT is capable of doing, IT’s roles and responsibilities, know what technology investments are being made—and have knowledge of where the data lives. Essentially, the architect must understand both sides of the business/IT coin.
An enterprise architect, commonly sitting on an IT steering committee, can translate business analyst’s requirements so they’re understood by IT analysts. The architect can prioritize projects and specify which projects can use the automated tools and which can’t. An added benefit: the architect can act as a referee in solving ownership problems. For example, if BPM is truly cross-divisional, someone must decide whose changes will go first, since changes in one area may ripple down to others. In a typical enterprise, BPM and BRE tools are among multiple technologies that need to work together. An enterprise architect understands the applications and data interfaces required between these technologies and can guide the introduction and coexistence of BPM and BRE within an existing, complex technology landscape.
Of course, success with tools such as BPM and BRE assumes that the processes and systems themselves are well understood. An enterprise architect can’t help you document what you don’t understand. What enterprise architects can help with, however, is to identify where the process gaps and inefficiencies are. “When the process is well-structured and well-defined, has high-volume transactions—with discrete ins and outs—BMP and BRE can work best,” Mehra says. “Enterprise architecture involves producing guidelines and standards for how architecture (everything from systems and hardware to governance and applications) will evolve over time as business needs change. Ineffective EA is a key block to getting the most use from BPM and BRE.”
Beyond Business/IT Alignment
The enterprise architect can be a critical aid in getting IT and business to see eye to eye. The architect can translate design issues into implementation issues, bridge the gap between what a systems architect designs with what a business expects, and tempering that design with an understanding of what requirements are actually possible.
The architect isn’t just useful up front. After an application is built or tweaked, the architect allows for its governance, helping develop an SLA for application processes, for example.
Mehra says organizations typically implement BPM by taking the first process that comes along and using that as the pilot project. “Instead, the enterprise architect can find a good process to use before any tools are used. They’ve thought through the high-level use cases to find just the right project. After all, there’s no point in institutionalizing a bad or redundant process.”
The size of the enterprise has little impact on how an organization uses an architect, though the larger the size, the greater the complexity an architect can address. Mehra says that a strong, centralized IT department needs a strong, centralized architect as well.
The trick, as any IT professional will tell you, is to have sufficient IT expertise to be understood by technicians yet have the ears—and trust—of the business users. Mehra warns that it’s a complex mix. “Sometimes systems or application architects will call themselves enterprise architects. That won’t work. You need someone who can straddle both IT and business sides of an enterprise—and have influence with both. They don’t need to come from the business side rather than IT, though it depends on how the organization supports the role as to their success.
“The architect focuses on good design—the tools don’t give you the essentials, it’s the design, and enterprise architecture facilitates that design.”