Mergers and Acquisitions (M&A) are typically done with the objective of gaining particular assets and / or to gain to a new customer base. To be effective, it is necessary to carefully consider the operational ramifications and the potential business and technology issues bringing the two organizations together.

Forrester clearly points out that the key best practice in handling M&A is to “Use business and IT capability maps developed before an M&A to accelerate due diligence and planning”.

The typical problem faced when two organizations have to merge is in rationalizing their systems, especially so as each side tend to take a view that their systems and processes are superior. There are cases where a long time (a couple of years) is spent in comparing each and every system/application with their counterpart and decision taken on an individual basis. In addition to the time and effort, the end result tends to be a sub optimal one, as the decisions are taken at each part and not looking at the “whole”. Having an established Enterprise Architecture (EA) helps to avoid this common mistake that often plague companies following a corporate merger or acquisition.

Enterprise Architecture establishes core principles and guidelines at the:

• At the business level, the EA strategy helps align with the organization’s operating model, strategy, and IT objectives, guiding IT transformations by providing a business-centric view of the enterprise from a functional perspective.
• At the application tier, the EA strategy ensures a minimal amount of overlap among information systems, laying the groundwork for a comprehensive set of applications that work well together, are easily integrated and don’t duplicate efforts.

While the Business architecture – business drivers and processes – enable the business managers to share a centralized vision for executing specific processes, application and technology guidelines enables the technology managers to make decisions.

Using the already established EA Strategy and guidelines as the baseline for making decisions – makes the decision making objective and less tedious. This approach helps in two counts:

• In synthesizing information systems in an efficient and economical way
• To foster harmony among employees of both the organizations.

Using the business architecture multi-level approach, it can be determined if the new entity is similar, subset or superset of an existing business component or if it is a totally new business component (in case of total diversification). The next step is to determine how to combine the business processes, applications, and infrastructure assets.

Depending on the extent of commonality in the business and the applications, the major scenarios are:

• If the processes, applications and technology platforms are reasonably in alignment with the established EA guidelines, then combining them to the existing environment would be pretty straight-forward.
• If the processes, applications and technology platforms are not aligned with the established EA, then the new entities have to be converted and combined with the existing environment.
• If the processes, applications and technology platforms are in such a way that they cannot be combined (typically in case of total diversification), then the Enterprise Integration Architecture guidelines have to be used to easily integrate these applications.

In the event of combining business processes, then the business levels have to be used to determine the sequence of the areas that are combined. Typically the HR (employee related) and Finance (accounting) get done, followed by client facing processes (so that the client have a consistent experience), and finally merging the other process areas.

In the event of the new processes, applications and technology components of the new entity have to be retained and integrated with the existing environment, then using the Service-oriented integration becomes essential. SOI’s key benefit in terms of handling heterogeneity, providing interoperability and service location independence makes it the right choice for integrating systems – that were not planned to work together.

In addition to having EA baseline, it is essential to have EA Governance in place which handles Architecture compliance as well as architecture change management. As a result of M&A, for optimal results, the established EA may have to be changed – and the decision making approach and authority to be defined and established much earlier to be really effective in handling such scenarios.

Enterprise architecture (EA) has become essential to make efficient use of technology and address the business needs and maintain the competitive advantage.  The expectations from EA include technology / tools rationalization, support business strategy, increasingly agile and flexible IT, improved interoperability and reduced TCO.

EA governance refers to the framework that ensures the integrity and effectiveness of the organization’s architectures.  The framework broadly covers the governance activities of Adoption, Compliance, Dispensation and Retirement. Establishing the framework typically involves:

• establishing processes to support management of architectural activities
• implementing a system to ensure to ensure compliance with internal and external standards and regulatory obligations
• Capturing and managing all relevant architectural artefacts – architectural models (architecture continuum), approved product and technology set (solutions continuum) and architecture contracts

 EA of an organization can begin using a wide-range of tools:

1. Office Automation tools like MS-Office

2. Diagramming tools like Visio

3. Knowledge Management tools like Lotus Notes

4. Comprehensive Architecture modeling tools.

With the growing pace of EA adoption and the increasing number of technology alternatives, enterprise architecture governance is becoming more and more complex. It is becoming mandatory that all technology investments are mapped to business processes and requirements justifying the appropriateness of the same. With this focus shift to a holistic approach to EA, use of Architecture modeling tools become a necessity.

Compared to other options like diagramming tools, comprehensive “Architecture modeling tools” provide functions for Analysis and optimization of business activities, processes, information, application as well as technology. Consolidating the business artifacts to a single standardized repository is expected to provide leaping benefits.

Various EA tools are available in the market that support modeling, storing, sharing and managing EA.  Two major categories of EA tools exist:

• EA Repository Tools – EA bottom-up approach aimed at providing a enterprise global view based on business processing and development models already available – Simple repositories suffice as they just have to store models from different tools and provide a global view; Should support various format enabling exchange of information. EA Web Modeler, Rochade, Troux etc. fall under this category.
•  EA Modeling Suite – EA top-down approach where the EA modeling is done at enterprise level from business, information, application, technology and infrastructure perspective. – Should be able to get UMLs, data models etc. and store in a common area in a standard format; Used for Storing, maintaining and managing EA models – to be used by architects, developers, project managers, CIO etc. System Architect, ARIS, Metis, Visible Advantage etc. fall under this category.

EA modeling suite provides the conceptual view of business and information flows, process and data models (as against just the physical and logical views provided by development tools that include modeling – e.g., Rational Rose, Visual .Net etc.). It has to be seen as business analyst tool – rather than development tool.

In addition to the standard characteristics of the tool, the following are the factors to be considered for tool selection:

• Available platforms
• Graphical user interface to model business activity, information, data structures, applications that support business processes
• Multi-user support
• Interoperability between EA modeling suite and Development tool suite is essential to enable seamless integration. Should have import/export capability
• Support for the chosen Enterprise Architecture Frameworks like Zachman, TOGAF, DoDAF etc.
• Support for required modeling methods – IDEF, Class models, data models, Information models etc.
• Ease of use
• Vendor support
• Cost – initial and maintenance and licensing modes
• Traceability to requirements and other architecture artifacts
• Configuration Management support

At times, organizations do have some of these  high end tools (like ARIS) in place, but limit to their usage to just store models. Before making any purchase decision, the possibility of exploiting the existing tools effectively should be explored.

Most people agree with Charles Edwards (of Agile EA) comment, that though software development and architecture has been making excellent progress over the past two decades, the same cannot be said of Enterprise Architecture. There are ongoing debates and discussions on topics like Is Enterprise Architecture dying? What is killing Enterprise Architecture? Is there any market for Enterprise Architecture?

The typical drawbacks of Enterprise Architecture (EA) are observed to be:

1. It takes way too long and requires too much effort
2. Not able to prove that significant value is being created
3. Lack of Communication

In an attempt to solve the major drawbacks of Enterprise Architecture, other methodologies (at times referred to as third generation EA) have come up. Still there is no consensus and as practitioners we realize that the hybrid approach is what works best.

From this perspective, the following key points could be directly used by practitioners of EA as a step toward agility:

1.    instead of trying to make a perfect architecture / model – which takes a lot of time and effort and hence quite detailed but not really more usable or correct (as with time the changes would have happened and the model may not reflect the current status), aim at a simple, usable and meaningful model that makes sense to both the Business and IT people and hence really effective (as people really would read and use them!).

2.    Not rely on a specific modeling approach and but use a variety of tools to depict the information and adopt an “iterative and incremental” way to build it. The key is to use the “Right approach – with the right level of detail – for the right context”.

3.    Look at the whole picture – using the various perspectives which are depicted in multiple artifacts.

AgileEA is a free open source EA Operational Process. It is a framework that is designed to either use as is, or to tailor and publish your own Enterprise Architecture Operational Process website. Right now, the site seems to be under maintenance - some time back it was in Beta and asking for suggestions. A whitepaper on Agile EA – Phases, Iterations & Discipline by Charles Edwards is available at http://www.agileea.com/Whitepapers/AEA_Phases_Iterations_Disciplines.pdf.

Enterprise Architecture has been there for over two decades now and still means different things to different people. For some it is a graphical model which excruciating level of details, while in the other extreme it is viewed as a practice that brings in business value.

Zachmann, TOGAF, FEA and Gartner’s EA practice are the four significant EA methodologies that are there in use today and most others are a combination of these. Of various artifacts that dwell on Enterprise Architectures and their comparisons, I found “Comparison of the Top Four Enterprise-Architecture Methodologies” in http://msdn.microsoft.com/en-us/library/bb466232.aspx the effective one is bringing out the differences. In spite of the differences in the understanding and approach of what constitutes EA, the objectives are necessarily the same “Business-IT alignment”, Agility, Cost Reduction and Improved Value.

Enterprise Architecture, though seen as an IT initiative (probably due to the reason that it has been handled by IT personnel), has to do more with Business than IT. In general, the essential reasons for developing an EA have been and remain as:

•Alignment – ensuring the reality of the implemented enterprise is aligned with management’s intent

•Integration – realizing that the business rules are consistent across the organization, that the data and its use are immutable, interfaces and information flow are standardized, and the connectivity and interoperability are managed across the enterprise

•Change – facilitating and managing change to any aspect of the enterprise

•Time-to-market – reducing systems development, applications generation, modernization timeframes, and resource requirements

•Convergence – striving toward a standard IT product portfolio as contained in the Technical Reference

Right now, Enterprise Architecture has reached an interesting phase where it is no longer looked upon as a technology or infrastructure or even application related. With Enterprise Architects today reporting to CxOs, the EA charter today includes enabling Business Strategy and addressing business issues.

Though it sounds like an ideal situation, it definitely remains an uphill task for Enterprise Architects. A survey from Forrester points out that lack of support from business is a common concern and improving perception of EA as a common goal expressed by Enterprise Architects.

Both business and technology are changing at a rapid pace and even bringing paradigm shift. Businesses are expanding, merging, de-merging and time-to-market has been shrinking and shrinking. Similarly technology advancements like Cloud computing, Software-as-a-service, COTS are making Application and Technical architecture of lesser importance than hither-to they have had.

Business Architecture, Information Architecture and Integration Architecture are the areas which are to be focused at by Enterprise Architects. Significant progress in these areas coupled with delivering business benefits, that too quickly, is what is expected from Enterprise Architects today.

In most organizations, Enterprise Architects currently spend most of their time in arriving at detailed models which no one else are able to use effectively, in creating detailed level of standards and guidelines that result in frustration during implementation, in acting as enforcement agents of the EA guidelines created and in trying to meet the immediate need of the business – giving short term the priority at the expense of long-term goals.

To enable the level of detail which Architects where arriving at and also to handle localized requirements, most large organizations had Enterprise Architecture groups at local or national level. And this trend is again changing with the focus of Enterprise Architecture increasingly becoming global.

Global Enterprise Architects should streamline their focus and efforts on high impact, high priority areas that are in alignment with the business strategy. Most of what they are currently doing cannot be ignored altogether – and these activities can be relegated to local and regional Architecture groups.

With the improved EA charter, aligning to any single EA approach may no longer be feasible and the best thing to do is to use the right set of tools, producing artifacts at the right level of detail, and most importantly within the right time frame. Communication – that always was essential for the success of EA, has become crucial today.

Enterprise Architecture, as any other discipline, should adapt itself to the changing demands and trends and agility of the EA is what would ensure that EA provides the benefits it promises.