Meet the Challenges of Enterprise Architecture – A Starting Point

[AndreasPoth]

There are many articles about the outstanding value of enterprise architecture.
According to The Open Group TOGAF Standard [1], a cross-enterprise optimization can bring the following benefits:

• More effective strategic decision-making by C-level executives and business leaders.
• More effective and efficient business operations
• More effective and efficient Digital Transformation and operations
• Better return on investment, reduced risk for future investment
• Faster, simpler, and cheaper procurement

The book “Enterprise Architecture – Creating Value by Informed Governance” [2] lists many values for Business Stakeholders, IT, and both, Business and IT.

Overview and understanding of the enterprise, process improvements, eliminating duplication, underpinned decision-making, etc., are relevant for the business stakeholders.
Effective IT planning and management of IT Roadmaps and much more address IT stakeholders.
Overall, enterprise architecture helps to bridge the gap between Business and IT and to align a shared vision.

At SAP, we use Enterprise Architecture(EA) in different areas or “dimensions” (which gave me, on various occasions, the possibility to attract attention by talking about 3D-Enterprise Architecture).
Overall, SAP business stakeholders and our SAP IT organization use EA to align - as most enterprises when they leverage EA. In addition, we use EA in Product Engineering as an engineering practice to ensure business-driven portfolio planning, precise product positioning, cross-engineering unit alignment, business-focused rollouts, etc. Finally, we leverage EA and offer Enterprise Architecture services to our customers.

Rarely a discipline has countless benefits for any company in any industry, such as Enterprise Architecture! When you have found this blog, I assume you also have a reasonable belief in the benefits of EA for your company!
Nevertheless, some individuals do not have the same level of trust in the EA discipline.
Why is that? EA does not only come with vast potential, but it also has its challenges.

I invite anybody to reply to this post, sharing key challenges and obstacles. Some key challenges we have been facing you will find below.
In the following blogs, I would like to share how we addressed those difficulties and discuss the best possible approaches with you!

• Challenge #1: Number of Existing EA Frameworks and Methodologies

There are many enterprise architecture frameworks available. Matthes [3] provided 2009 an overview of more than 50 EA frameworks, including the Zachman EA Framework, The Open Group Architecture Framework TOGAF®, and Gartner's Enterprise Architecture Framework.
Many different frameworks can cause difficulties, especially when the units of a single enterprise adhere to various frameworks.

• Challenge #2: Overwhelming EA Scope

The goal to improve business processes across an entire enterprise will automatically touch many architecture domains and concern a large number of stakeholders. Therefore, a successful enterprise architect requires particular (power) skills to interact with those stakeholders and to establish an accepted EA practice (with the appropriate focus, at the right level of detail,  respected governance, …).

• Challenge #3: Involved personalities

Actors who dedicate themselves to improving the structures and processes of an entire company are often strong personalities who aspire to achieve their vision and provide direction. Unfortunately, alignment and compromises are often time-consuming.

Such challenges often delay the value creation of enterprise architecture.
I look forward to reading about the top challenges you have been facing and the discussions of we should ideally deal with them.

[1] The Open Group (2005-2022): The Open Group Standard, The TOAF Standard

[2] Martin Op ‘t Land (2009): Enterprise Architecture, Creating Value by Informed Governance

[3] Dirk Matthes (2011): Enterprise Architecture Frameworks Kompedium  

[MartinMysyk]

Thanks for the post Andreas. We have both a rewarding and challenging role as an Enterprise Architect. You mention just a few of the things to consider that challenge us. I think going forward it will be both equal parts dealing with personalities and technologies. Moving to the cloud brings out both aspects. 

I am wondering if others are experiencing this - new challenges for EA's moving to the cloud. What do you think?

[Anup]

Thanks for sharing Andreas !

This is an important aspect of Enterprise Architecture which needs continuous improvement. We help our customers in defining their transformation journey using our Enterprise Architecture methodology, content and tools. Some of the challenges we face in our delivery organization are as follows:

#1 – Majority of the stakeholders assume Enterprise Architecture as only Technical Architecture

Discussion is always about technical architecture and infrastructure such as sizing, hosting environment, scale out, platform, hyper scalers etc. But, in all this the critical strategy drivers and business architecture is missed out as to “why there doing for what they trying to do” for the transformation initiatives. So, its important to bridge the gap between the business architecture, application architecture and the technical architecture

#2 – Enterprise architecture is to be discussed only at high level and does not solve problems

Enterprise Architecture is a “breadth” topic rather than a “depth” topic but within that “breadth” there are specific details which needs to be worked out to arrive at the architecture decisions and recommendations. Depending on the choices available for the architecture decisions, there will be consequences for the future. So, its equally important to document the rationale of each of these decisions and revisit them during execution stage to fine tune the target architecture and roadmap

#3 – Missing architecture governance

Setting up Architecture Governance at the early stages of transformation initiative goes a long for a successful journey to be measured. E.g. Having a set of architecture principles really ensures the guardrails to define the target architecture and roadmap

Happy to receive feedback and more experience sharing in this blog series

[Rajen_Patel]

Thanks @AndreasPoth  and @Anup  for sharing your insights.

Here are a few challenges that come to mind.

# Communicating the value of Enterprise Architecture

• IT and Business leaders are listening from the ‘What’s in it for me?’ (WIFM) perspective. EA frameworks come across as too theoretical and difficult to understand. As an EA we owe them a clear and concise explanation of the scope and the value of the EA layer they are interested in.

# Underestimating the ‘drag’ of legacy process and technical debt in moving forward

• EA often underestimates ‘pay off’ required to clear the technical debt and the efforts to dismantle entrenched legacy processes before implementing new business capabilities

# Coordination between Company, Business unit and Project

• These three layers move at various speeds and have different success metrics

[ChandraKnabel]

@Rajen_Patel - sharing some thoughts on communicating the value of Enterprise Architecture.

In my experience leading an Enterprise Architecture (EA) team, I found that at least 80% of people in IT and other business roles don't understand what Enterprise Architects do or the value the EA practice can bring to an organization. 

I think the confusion starts with the name of the role itself. It's as if the word Enterprise is invisible, or they substitute the word Technical, so Enterprise Architect becomes Technical Architect. The notion that Enterprise Architects are drawing up designs of how to connect servers, specifying server sizing, and optimizing backup strategies is cemented in their mind before we ever try to explain a more accurate role definition and value proposition. This confusion may come from the correlation to a physical building architect or is a result of all the various roles that now have "architect" attached. Some examples include Application Architect, Solution Architect, Cloud Architect, Security Architect, and Basis Architect, which are all very narrowly focused technical roles. 

So we have an uphill battle to explain the Enterprise Architect role and the value proposition to the organization. 

I like to start by explaining that EA is "the holistic design of people, processes, and technology to execute digitally inspired strategic goals" (Ross & Beath, 2020, para 2). Enterprise Architects work with the CTO and other technology leaders to drive digital innovation. This work includes leading the organization through technology-related business disruptions and opportunities, driving digital transformation initiatives, setting the technology strategy, and influencing the business strategy (Resnick, 2021). Perhaps this view of the EA role is more of an aspirational future state, but it does represent the target view.

I have found a few approaches that work well to communicate the value of Enterprise Architecture:

1. Communicate in a novel way - because of the high likelihood of incorrect impressions already set in people's minds about the EA role, you must use a more memorable way to communicate to replace those perceptions. A good example I have used is this video that explains the value of an EA: What is Enterprise Architecture (EA) and why is it important? EA concepts are explained in a simple ...
2. Quick wins - Identify a quick win that an EA engagement can impact and do just enough architecture analysis to make recommendations. Create visually pleasing, executive-ready deliverables to communicate the problem, process, and suggested outcomes. Gather successful use cases as you go along and use those as examples to explain the process and expected results to future stakeholders.
3. Create clarity with EA diagrams - When not explicitly working on an EA engagement, take the initiative to diagram and document critical concepts for strategic projects and initiatives. Share those diagrams to refine them with the stakeholders and use them frequently to ensure a broad and consistent understanding of essential elements of these initiatives. Lean towards visually pleasing, easy-to-comprehend diagrams rather than technical completeness to broaden the audience.

Using these approaches should help increase the understanding of Enterprise Architecture across the stakeholder group and increase the number of times the EAs are brought into strategic engagements early enough to have a significant impact. 

Ross, J., & Beath, C. (2020, August 24). Why You - Yes, You - Need Enterprise Architecture. MIT Sloan Management Review. https://sloanreview.mit.edu/article/why-you-yes-you-need-enterprise-architecture/

Resnick, M. (2021, February 1). Enterprise Architecture and Technology Innovation Leaders Primer for 2021 (ID: G00738733). Gartner. https://www.gartner.com/document/3996280?ref=solrAll&refval=293708537

[stevang]

I am Practitioner and I strongly believe EA (or Architecture in general) should be pragmatics discipline - we do not do Architecture for the Architecture sake, we do it in order to address specific (business or technology) problem. Let me share my thoughts on three points...

On challenge #1: Number of Existing EA Frameworks and Methodologies

Yes, it is a challenge if we put ourselves "in the box" of the frameworks. But again, what is that we want to achieve? We want to address the problem - so we only use or apply knowledge of various frameworks - and each will "speak" some (slightly) different wisdom. So, if we turn things upside-down, we may even say - hey it is good so many professionals wrote so many nice recipes how to address real-life enterprise problems.

For my TOGAF is the foundation on which I build my Structured Thinking - but when addressing those enterprise problems, I try to follow Architectural Thinking approach as mush as possible. E.g. I find SAP AppHous (https://apphaus.sap.com/toolkit) and Lean EA quite interesting..

On challenge #2: Overwhelming EA Scope

I guess some of the enterprise architects would be always better in e.g. managing stakeholders, while others perhaps in addressing particular (business or technology) problems of those stakeholders - just as some of the (contraction) Architects would be more artistic, while other more engineering oriented. But at the end, we all have to construct a "house" which is habitable...

Saying that - we may have some "power" skills in some areas of EA work - but it is okay to say - none of us have all the "power" skills. Or at least this is how I see it...

On challenge #3: Involved personalities

True, and honestly, nothing much to add. 

There is no magic-wand. Having ideas, architecting and drawing is an easy part. Making alignments and compromises among stakeholders and teams is probably the most difficult part of the EA work. But than again, if it would be easy, what what differentiate EA role from the role of other architects?

[AndreasPoth]

Hi everyone, thank you so much for your feedback today. We will follow up on that. Stay tuned!