My very first BPMS Watch column, over three years ago, was titled “Without a BPMS, It’s Not Really BPM.” And to a large degree I still believe that, although today I would probably tone it down to...

Collaborative Business-IT Architecture Realignment

IT architectures are merely a reflection of what business units have been requesting for decades. As the business changed, so too did the IT environment. Unfortunately, complex and often redundant data and application architectures can no longer adapt to increasingly dynamic business requirements. Coupled with the fact that the business architecture itself may be ill suited to respond to industry dynamics, it is clear that enterprise architecture realignment must be a collaborative effort involving key business and IT stakeholders.

Symptoms of Poor Business-IT Alignment

What would lead an organization to concede that business and IT architectures are poorly aligned? One aspect is that as an organization morphs and evolves, data and application architectures have not kept up with required changes. IT environments have grown large, cumbersome and unresponsive, preventing effective delivery of business value.

Addressing this challenge has been complicated by ineffective communication and poor collaboration between business units and IT. As a result, IT architectures are growing increasingly out of synch with business requirements.

An example highlights the challenge. A successful company had an old assembler system, surrounded by aging COBOL systems, wrapped by modern middleware technology. Core business data was locked into a master file only accessible to the nightly batch, assembler system. IT managers planed to convert the assembler system to Java, but sessions with business users found that this would sidestep fundamental architectural deficiencies.

In user interviews, numerous front-line users, analysts and managers said they could not get the data they needed, in the form the needed it, in the timeframes required. Confronted with this, IT sought to redefine and modernize its data architecture, but this could only be achieved by business units and IT working collectively.

The above example demonstrates that business users are key stakeholders in driving architecture strategy needed to meet critical requirements.

Business & IT Must Seek Collaborative Solutions

Business units and IT may both be “architecturally challenged”. This is the reason that business and IT management and analysts must craft collaborative solutions to synchronizing enterprise architecture. Another example highlights this requirement.

Consider an insurance company using two Claims Systems because Claims business units do not want to give up control of their customers or people. IT cannot possibly drive or even propose an independent solution to this situation. What IT can do is to suggest collaborative working sessions to craft an agreed upon solution that benefits the enterprise as a whole.

In the above example, such a session would require business and IT management and analysts to draw up the pros and cons for and against Claims consolidation. Given that this team could build an objective case for a consolidation initiative, they would then move to define a target business and IT architecture, a phased deployment approach, related impacts and cost / benefit model. If applicable, related impacts analysis would dictate inclusion of other affected parties impacted by the consolidation initiative. Finally, the team would present the strategy to the executive team.

Too often, such an endeavor is undertaken by IT alone or business units alone. In the above example, this would be doomed to failure because business unit, customer and IT architecture consolidation must be phased in and carefully synchronized.

Other examples exist of architecture alignment efforts that have failed because management did not create a collaborative approach. More common, however, is the situation where executives take no action at all to address enterprise architecture alignment because it appears too overwhelming. This will eventually result in an organization losing the competitive advantages that IT was meant to deliver.

Collaborative Teams – A Practical Approach

Collaborative teams may be formed for any particular issue and may be deployed in phases. A phased approach is required if one or more parties are unreceptive towards a collaborative solution.

Consider the example of a telecommunications company that had grown through mergers and acquisitions. This organization had many redundancies built into its business units and systems. One such redundancy involved customer support and billing functions. Because IT was working in isolation on a “big bang” solution, the business team created a collaborative working group of front-line users across redundant business units to redefine the business architecture around customer service and billing.

This collaborative team derived common requirements across business units, defined commonly agreed upon work processes and automated these processes with front-end systems. They also dramatically reduced spreadsheet, Access database and paper / pencil solutions. This same team then developed front-end / back-end integration points to redundant, host-based applications.

Based on proven productivity results, the collaborative concepts spread to the IT organization. Dozens of collaborative teams have emerged with the common purpose of streamlining front-end solutions and identifying application and data architecture realignment opportunities. This phased approach to collaborative architecture realignment was very successful. The bottom line is that collaboration is essential or an enterprise architecture realignment initiative will fail.

________________________________________

William Ulrich is President of Tactical Strategy Group, Inc., Co-chair of the OMG Architecture-Driven Modernization Task Force and author of “Legacy Systems: Transformation Strategies”. He may be reached through his web site at www.systemtransformation.com.

William Ulrich's Training Course.<//a>

Back to Articles, including BPM, SOA, BDM, BA & OP