Case study of not successful EA practice

After posting three case studies of successful enterprise architecture practices and discussing common EA pitfalls I decided that it’s the time to present a case study of en enterprise architecture practice that didn’t manage end up successfully.

Using Enterprise Architecture for changing business processes

Client environment:
The client is a government agency heavily based on information and information management for reaching the agency goals and objectives as they set by the regulator. This client new CEO came with new agenda of how the business need to be done in different and more affective manner. The CEO understands that the best way to enforce his new strategy is by changing IT business applications, systems and technology. To make his vision a reality the CEO asked the CIO to start a group that will make the change in current IT landscape.


Client business goals:

  1. Translate CEO vision to practical business capabilities and processes
  2. Change IT landscape to support new CEO vision
  3. Successfully implement new system to facilitate CEO vision


Approach:
the team followed a modeling approach in order to capture current situation, identifying gaps and create migration plan (IT roadmap) to fulfill the above business goals in one year time frame. Using the models we manage to simplify the complexity of the enterprise business, information applications and technology domains and cross relations between those domains. The work has been done internally in the group without interaction with IT teams with a goal to present migration plan after 12 months.


Steps:

  1. Translating CEO vision into new set of business capabilities and processes. Using business capabilities to create hierarchal structure of business functionality and by using BPMN describe how those capabilities are being done.
  2. Analyzing gaps between current and future business architecture. Understating new capabilities, how business processes are going to be changed and identify new business processes.
  3. Mapping current IT assets and modeling conceptual and logical models for Information, Applications and technologies (including hardware).
  4. Mapping existing IT assets to existing business capabilities.
  5. Based on current IT architecture and new business architecture creating future IT architecture by setting principles, standards, blueprints as well as conceptual and logical models of future Information, Application and Technology domains. The future IT architecture should cover all business capabilities exist in future capabilities map (at least all of the core capabilities).
  6. Analyzing gaps between current and future IT architecture.
  7. Identify opportunities for each gap and select the best solution.
  8. Translate the selected solution into 3 years roadmap.
  9. Present the work to CEO and IT.
  10. Get CEO support but reluctant approach from IT to adopt the plan.

Conclusion:

although the practice manage to understand new business direction and even get the CEO approve, the practice failed due to the fact that IT didn’t cooperate with the suggested roadmap. The reason for this failure is deeply rooted in the way that the EA work has been done. Doing EA from ivory tower without deep involvement of the people that need to do the work eventually, result in resistant from implementation level and actually caused a failure (regardless if the suggested architecture was the right or wrong one).
 

 

No Comments