Back to top

Challenges in EAM

Challenges of EAM are manifold. Often mentioned examples are ad-hoc EAM demands [Hau+13], unclear business goals [Hau+13] and the ivory tower syndrome [RSV08].


EAM Challenges Foundations

Enterprise Architects face many challenges while conducting their EAM activities. An overview of possible challenges identified in [Hau+13] is provided in Figure 1. The most practice relevant challenges are ad-hoc EAM demands, unclear business goals, difficulties finding experienced enterprise architects, EA demands that are unclear for EAM team and enterprise environment that change too quickly [Hau+13].

 

Figure 1: Non-exhaustive list of possible EAM challenges. [M. Hauder, S. Roth, C. Schulz, and F. Matthes. “An Examination of Organizational Factors Influencing Enterprise Architecture Management Challenges.” In: 21st European Conference on Information Systems (ECIS). Utrecht, Netherland, 2013.]

 

Anti-Pattern

Anti-pattern constitute approaches that have proven to be unsuccessful in practice [Buc10b; BBL12]. Just like patterns, anti-pattern have catchy names and use a clear, accessible, and informal language. An anti-pattern frequently perceived in EAM is the so-called “Ivory Tower Syndrome” [RSV08]. This anti-pattern describes the development of a too detailed EA model which possesses the wrong level of abstraction [RSV08]. This behavior can surface, if a decoupling of the actual EAM activities and the stakeholder concerns occurs.

More anti-patterns are described in [BBL12]. Here, eight anti-patterns are categorized along the four dimensions Perspective, Governance, Strategy and Transformation. The first dimension Perspective captures the focus of the Enterprise Architect with regards to his tasks. Since the role of an Enterprise Architect comprises a spectrum of tasks reaching from strategic activities down to operational tasks like the support of single projects, he can take a more holistic or a more hands-on approach to EAM. The two ends of this range can be described using anti-patterns. “Living in Cloud Cuckoo” means that the Enterprise Architect has taken a too high perspective on the EA and is decoupled from the community of project architects and developers, loosing insight on their challenges. The opposite phenomena is called “In the Chief Mechanic’s Workshop” describing a situation, where the Enterprise Architect is too involved with technical issues and projects architectures, neglecting the holistic view of the EA [BBL12].

The second dimension is concerned with the strictness of the Enterprise Architect with regards to the adherence of governance rules. Even though a standardization of the IT landscape enables decision support and cost reduction, a too rigid approach to enforcing the rules can lead to an implementation of suboptimal solutions and to a lot of energy wasted in political fights. This anti-pattern is called “The Guardian of the Wisdom”. On the other hand, “The Overstrained Technical Advisor” is the anti-pattern which results from a laissez-faire approach to IT governance [BBL12].

The dimension Strategy looks at the time horizon of the strategic planning of the EA function. One extreme is an EA function without any long-term planning. In this context, the anti-pattern “Sweeping Up the Change Requests” emerges, which means that the Enterprise Architect merely records the change requests of the business instead of working towards an EA target state. Nevertheless, choosing a planning horizon which reaches too far into the future is also counter productive, since within a few years both the business as well as the IT situation may change dramatically. This anti-pattern is called “A Deep Look into the Crystal Ball” [BBL12].

Finally, the last dimension is Transformation, which deals with the speed of change of the business and IT landscape dictated by the Enterprise Architect. Constantly driving change at a very high speed can lead to a anti-pattern called “The Permanent Construction Site”. In such a scenario the stakeholders are left behind and the proper functioning of the IT is at stake. But again, also the opposite approach “The Ever-Growing Backlog” has negative consequences. In this case, the EAM function merely documents change instead of driving it, completely neglecting EAM driven change programs in the IT landscape. This approach results in EAM being a documentation graveyard which doesn’t provide any benefits to the organization [BBL12].


Sources:

[Hau+13]

M. Hauder, S. Roth, C. Schulz, and F. Matthes. “An Examination of Organizational Factors Influencing Enterprise Architecture Management Challenges.” In: 21st European Conference on Information Systems (ECIS). Utrecht, Netherland, 2013.

[BBL12]

S. Bente, U. Bombosch, and S. Langade. Collaborative Enterprise Architecture: Enriching EA with Lean, Agile, and Enterprise 2.0 Practices. Elsevier, Inc., 2012.

[RSV08]

B. van der Raadt, S. S., and van Vliet. H. “Stakeholder perception of enterprise architecture.” In: ECSA, volume 5292 of Lecture Notes in Computer Science. Ed. by R. Morrison, D. Bala-subramaniam, and K. E. Falkner. Berlin, Heidelberg, Germany: Springer, 2008, pp. 19–34.