The statement floats around in online forums and pops up in articles, boldly announcing, “Enterprise Architecture Is Dead!” Or asking the more gentle question, “Is Enterprise Architecture Dead?”
The debate rages (or has polite discourse) with opinions ranging from the complete redundancy of Enterprise Architecture (EA) to the simple suggestion that rebranding could be a good idea.
Gideon Slifkin, LinkedIn influencer and Global Enterprise Architect at Deloitte met with Ardoq’s Griffin Schumacher to discuss the current state of Enterprise Architecture's challenges during an episode of Behind the Future.
Gideon is someone who says what he means and means what he says. The opinions expressed in this story are wholly his own and not his employer's. Now that the disclaimer is out of the way let’s cut to the point and get started.
Is Enterprise Architecture Dead? Gideon’s Opinion
Spoiler alert:
“I don’t think it’s dead, but I do think it has challenges … I think it's extremely important and will remain so. Maybe there'll be a different name - Advice, Effectiveness, Digital Transformation - everybody's coming up with cool new names. But I think the core, beating heart of EA as it were, is essential, no matter what you call it.” - Gideon Slifkin
Gideon has 25 years of experience working with Enterprise Architecture. During his time in business and consulting, he learned the many issues Enterprise Architects face.
Initially, he thought the recurring problems he encountered simply pertained to the consulting field because people only call for help when they have a problem. However, based on feedback on LinkedIn and expert forums, it seemed the problems he saw weren’t all that unique. He kept seeing repeating issues:
- Definitions: There isn’t one definition of EA, and many EA teams struggle to explain what they actually do to stakeholders.
- People skills: To succeed, EA teams need to know how to deal with people, power, and politics.
- Language barrier: EA is highly technical. For stakeholders to understand the value, they need it explained in a language they can understand.
Let’s take a closer look at how these challenges affect stakeholders and the teams working within the Enterprise Architecture space.
1. EA Is a Broad Topic and Hard to Define
It’s easy to get lost in wordsmithing and developing the perfect definition of EA. Unfortunately, that’s a lost cause because EA’s definition changes depending on the situation. For example, a company using EA for cloud migration would include Application Hosting or Application Rationalization in their definition. On the other hand, a company focused on digital automation could include Business Capability Planning or Business Process Management in their definition.
In some ways, EA is like a Venn diagram having a big circle with everything that is EA or similar to EA, and another with what your organization needs to do. The place of intersection is where your organization’s definition of EA takes place.
Defining can also be extra difficult when launching a new EA program. When new people join a company, it’s challenging to map the company structure. Even when talking to the stakeholders, the picture may not be entirely accurate.
In a larger company, defining Enterprise Architecture has other layers of challenges. Sometimes, teams playing in the EA space are not strictly Enterprise Architects, which means they may nibble at the edges of EA through strategy or relationships and perhaps handle jobs that the EA team should handle instead.
What’s in Your Lane?
Part of defining EA is knowing your core focus areas. You should be clear about which operations you stand for and handle for the organization. For some companies, that could be EA with a business focus, in others EA could have an IT solutions focus. Remember, EA is often spun up in response to some business need, and if architects stray from that, they could find trouble.
Gideon believes EA deliverables like roadmaps, reviews, and coordinating with people are universal, “although some might argue on those points.”
Key points to ask yourself about in your definition:
- What is it that EA does that adds value to the organization?
- What do you stand for?
2. Enterprise Architecture Challenges: Politics, Power, and People
There’s a saying, “Culture eats strategy for breakfast”... and then goes on to eat EA for elevenses.
EA isn’t an ivory tower. It’s more of a collaborative team. You’ll need everyone to make a roadmap to get a clear overview of where you are and where you’re going. Generally, this will involve working in many different lanes: application development, infrastructure, or business. The trick is to collaborate within someone's lane but avoid overstepping.
As you try to transform the enterprise, there are many stakeholders you’ll involve, and you’ll need their feedback. Sometimes they may not want to collaborate, as their priorities might not necessarily align with yours. Unfortunately, an EA’s goals might not be a top priority for the CIO or individual leader.
Gideon notes that leadership support is essential:
“If you don't have leadership support, you're not going very far in a large political organization. I've seen this so many times, ‘the poor team who no one listens to’ … It's not their fault. They're just not set up for success, right? It's almost like the CIO said, Well, we’ve checked the box, but we're not gonna give them any power or resources. Instead, just send them out and expect them to successfully get the entire organization to follow the strategy. I mean, that's ludicrous.”
To move forward, you’ll need permission and support from stakeholders. Gideon suggests using soft skills to communicate your message in a language they can understand. He notes that while most EAs don’t want to be a political bureaucracy, in reality, they might be.
This wraps back into point number 1. If you’re unable to define what you do as an EA in a decision-making meeting, then you’re unlikely to get stakeholder support. It also leads us into the final challenge, digging into communication.
3. TOGAF, Terminology, Towers Made of Ivory
Let’s be honest. When EAs have problems, it’s not always the ‘other side’ that is causing the trouble. Communication goes two ways, and three of the roots of terrible communication include the three T’s listed above.
The Open Group Architecture Framework (TOGAF)
As the most used framework for EA, TOGAF outlines high-level best practices for defining business goals and aligning them with architecture objectives. In it, you have a library of different architectural views. This library provides an approach for how an Enterprise Architecture team could design, plan, and govern their organization. Generally, it works on four levels: business, application, data, and technology.
Because there’s so much information in TOGAF, it’s not logical to use it as a whole. Rather, it needs to be tailored to your context, using the methodology that is applicable to your company.
Gideon suggests that, to some extent, nobody uses TOGAF fully and everyone uses it. While EAs understand TOGAF, often it’s incomprehensible to stakeholders and thus not useful in decision-making or problem-solving.
Terminology
Both EAs and stakeholders may be burdened by the vast terminology within Enterprise Architecture, especially since there are often different definitions from person to person. (See TOGAF above, everyone reading this story likely has a different way of explaining it.)
Think of it this way: a doctor might discuss a patient’s condition in Latin with another doctor but needs to find a simpler language when discussing it with the patient. While the terminology helps Enterprise Architects in work discussions, it confuses customers and stakeholders.
The first step to solving this: realizing it’s a problem. The second: listen to your stakeholders and adapt EA to their concerns and needs.
For example, a stakeholder from finance could relate to tangible cost savings analysis, while you might try transition roadmaps with a digital transformation lead.
Ivory Towers
Working in a pure EA environment and making perfect solutions will do no one in the organization any favors. In fact, Gideon notes, “EA isn’t a team, it’s an ecosystem, it’s a collaboration with everyone in the enterprise. The Chief EA is the driver, bringing the people to the table and helping them with the facts.” Collaboration can’t happen in an ivory tower.
In addition, it’s important to remember that EAs and Chief EAs aren’t the decision-makers. Instead, the team is a support system, handing clear information to those who make the decisions.
Overcoming Enterprise Architecture's 3 Deadly Challenges
These three challenges are intertwined. The bigger the organization, the more the politics, and the harder it is to work. While there isn’t a silver bullet, you can overcome them with hard work and better communication.
While communication can be challenging, there is no other choice. It’s part of the job. Remember to:
- Understand your core focus areas, and be able to define ‘your lane’ to others
- Talk to the stakeholders and understand their pain points
- Plan a different message for each department
- Help stakeholders understand, but don’t dumb things down
- Make sure you have a separate set of stories and visuals for the C-suite because their focus differs
While Enterprise Architecture isn't dead, it has issues that aren't going away. Unfortunately, it probably won’t get easier; but enterprises will learn to adapt and learn how to communicate the value of Enterprise Architecture.
Watch Episode 9 of Behind the Future to learn more about the three Enterprise Architecture challenges.
