Any Business Architect can make a case for developing and maintaining business architecture for any business situation; it is the best way to create agility, align IT with the business, and establish the governance that keeps the business focused on the stated strategy. However, there is one situation that benefits from business architecture that is more obvious than any other – merger/acquisition. No matter how well the business was defined prior to the merger/acquisition, as soon as the business merges another set of operations into the mix, the business processes are broken.
IT Can’t Wait
Merging multiples sets of business operations into one includes merging multiple IT operations; remember IT is part of the business. There is now considerable redundancy in the whole IT architecture. There is hardware to consolidate, network communications to merge, data to transform, services to leverage, and applications to rationalize.
Where business architecture is leveraged is in the data transformation, services, and application rationalization. Before the data is transformed, a firm and consistent definition of the data is necessary and only the business can define it. Before services are leveraged, the business processes that share those services must be reconciled. And the business’ functional architecture is necessary to effectively rationalize the redundancy in the combined application architecture.
Since time is of the essence, IT can’t wait. The business owners took the time to ensure that the merger/acquisition was the right move for the companies involved. But now it is a mad dash to align their respective operations, reduce cost, and realize value. One of the prime targets for reducing cost is in IT.
Where to start: The Functional Architecture and Application Rationalization
IT can easily get started on the hardware and network communications. However, these do not represent the largest target for cost reduction in IT. Reducing the number of applications that IT must maintain represents a huge opportunity for cost reduction. Most organizations already have multiple applications supporting any given business function. Merging with another organization and its bloated application architecture further compounds the cost of supporting those applications.
Developing the functional architecture component of the business architecture is relatively quick. It identifies the core business functions and segregates them into customer management processes, product development and operations processes, and network management processes. Defining these core business functions requires the involvement of senior management from every business unit, including IT.
IT reconciles the combined set of redundant applications against the functional architecture. IT knows what each application does. IT maps those applications to the functional architecture to determine not only where the applications overlap but also how well each application supports the business. While one application might support a very narrow part of one business function, it might be so specialized that it is critical to the business. Other applications might overlap. And if one application provides enough functionality to retire three other applications, the decision looks easy.
IT must have a weighting process in place to help make decisions when rationalizing the application architecture. Every business unit thinks their set of applications is critical to the business and no one likes change. Having a process in place that weighs the cost and the benefit of maintaining the set of applications helps build the case for those that are retired, those that are sustained, and those that are enhanced and further matured. The business makes the final decision, but IT makes a good arbiter in this case.
Concurrent with Application Rationalization: The Process Architecture
While IT sets about rationalizing the application architecture, the business sets about reconciling business processes. In a merger/acquisition, there are multiple business owners that firmly believe they are doing the right things the right way; to sit around and argue the point is fruitless. What is necessary is process architecture. Develop business processes from the same set of business functions against which the application architecture is rationalized.
Identify the primary business events that result in the execution of the various business functions. At this level of definition, dependencies and interrelationships between business functions are documented and value streams emerge. Keep IT involved in this effort. As IT rationalizes the application architecture they make determinations about the longevity of the applications. If they know that one application crosses functional boundaries, knowing that a certain value stream crosses the same functional boundaries may strengthen the case for further investment in the application. Conversely, if IT knows that no value stream crosses these functional boundaries it may strengthen the case for retiring the application to reduce the cost of maintaining functionality that is not leveraged by the business.
Using the functional architecture to drive the creation of the process architecture helps break down silos by defining the value streams that are core to the business. Using the same functional architecture to rationalize the application architecture ensures that the resulting set of applications effectively supports the business. And combining the knowledge of the two efforts in a collaborative environment ensures that decisions are made that are in the best interest of the business and not just in the best interest of cost reduction.
Business Processes: Driving the Balance of the Alignment Effort
Once the value streams are identified, fully define the business processes that make up those streams. The processes identify any constraints that govern their execution, people and organizations that are involved in the processes, the steps involved to execute the processes, any products or services provided and the customers to whom they are provided, and any applications contributing to the processes.
Again, we see the hand of IT in this effort. IT is rationalizing the set of applications that are available to support the various business processes; decisions have been made by the business about whether certain applications will be retired, sustained, or enhanced. This is the perfect time for IT to help the business navigate through the available set of applications as the business defines the future state. It is also the perfect time for the business to change any of these decisions.
The information architecture is another byproduct of this effort. IT must transform the data of the merged/acquired businesses into a data architecture that fully and effectively supports the business. IT uses the information architecture to gain a firm understanding of the information needs of the business and the data definitions that support it.
Once the applications have been rationalized and the data architecture is in place, IT leverages the process architecture to develop the communication between the many remaining applications. These applications can all “talk” to each other by virtue of their respective APIs and any existing middleware. But it is the business processes that tell the applications when to talk to each other and what data to pass.
Finally, the services architecture (if applicable) is tackled. The process architecture highlights any common processes that are executed across the various value streams. These common processes are candidates for services. IT weighs the cost and benefit of developing and maintaining the candidate services and the business makes the final decision about which services to implement.
It is important to remember that in the case of a merger/acquisition considerable change takes place in all parties concerned. Everyone must change the way they are doing business. Not everyone will view the change as for the better. It is vitally important to begin the process of organizational change management before the merger/acquisition actually occurs.
