Breaking Down the Ivory Tower: A Practical Guide to Enterprise Architecture
In this article
Enterprise architecture: Now & then
The evolution game
To keep pace in today's dynamic business environment, organizations must evolve to stay relevant and maintain an edge over their competition. Those that become complacent risk losing market share or, in the worst case, going out of business.
As the saying goes, "Evolve or die."
This evolution can take place along a number of paths. Companies can always attempt to evolve by pursuing new lines of business organically or through merger and acquisition. But more commonly, companies evolve through technology transformation.
Technology is evolving, too, with new and more disruptive tools continually springing to life to help companies achieve transformation, such as public cloud and its native services or data lakes and analytics platforms. While these game-changing technologies are exciting, they do come with a price — and we're not talking about money.
Tech is complex
Each new technology you adopt adds complexity to your organization. People have to be trained. Systems need to be integrated. Data must be normalized. Legacy systems retired and their capabilities transitioned.
If not handled carefully, companies can develop a myopic focus on their shiny new toys that leaves them siloed and fraught with redundant systems, inefficiencies and internal confusion.
Over the last several years, many companies have found themselves in this unfortunate position. Technical debt is at a tipping point and businesses need ways to eliminate complexity from their environments. At the same time, they want to ensure their technology and business strategies are aligned, and their IT decision-making frameworks are systematic and holistic.
What they're looking for is enterprise architecture (EA).
In need of a new look
EA is the art of balancing the various capabilities, constraints and needs of an organization against the IT capabilities required to be efficient and effective.
The problem is most organizations have been there, done that with EA. Simply put, it didn't work for them the first time around (or the second and third times). The EA they trialed did not lead to actionable results and was out of touch with the business vision. Eventually, those types of traditional EA programs were cut, forcing enterprise architects to revert back to performing siloed solution architecture activities.
Before we discuss why companies should take a new look at EA, let's dig deeper into some of the reasons why EA approaches have often failed in the past.
Common downfalls of enterprise architecture
EA is a well-established practice area that has been around for more than 30 years. Companies can leverage many different frameworks, methodologies, software packages and other tools to build EA artifacts.
Given the breadth of resources, what has prevented companies from succeeding? There are three main reasons traditional EA approaches have been unsuccessful:
- Companies create EA in an ivory tower;
- Companies focus on the harder side of EA (ignoring the softer side); and
- Companies build EA in a linear fashion.
Let's explore each:
1. EA's ivory tower
Generally speaking, EA is an abstract and high-level subject. EA's overarching goal is to build the guidelines and guardrails for solution architecture and engineering while ensuring all IT decisions are aligned to business strategy. This requires a deep understanding of how the business works plus an awareness of how technology can enable the business. It's an intellectual subject that attracts conceptual thinkers.
If not managed carefully, EA experts' conversations can get heady and push any focus on driving tangible business success to the periphery. Once EA ascends this ivory tower of abstract thought within an organization, it is extremely difficult to shift focus back to the realm of business relevance. And once the business loses trust in an EA's ability to produce actionable artifacts, it is not too long before EA becomes shelfware.
2. Focus on the harder side of EA
Companies typically focus on the harder side of EA during implementation. This includes concepts like EA modeling, dashboards, finances and reference architectures — the more concrete, logical side of the business equation. The softer side of EA, by contrast, involves more collaborative concepts like the using the right personnel and harnessing persuasion to promote adoption, messaging and accessibility.
Approaches that focus on the harder side of EA (to the exclusion of the softer side) can make it difficult to get the buy-in needed for EA initiatives to succeed.
Consider a company whose main focus during a traditional EA initiative consists of choosing a framework to guide its processes (e.g., TOGAF, Zachmann) and selecting an EA tool to build models and other artifacts. Because they are laser-focused on the harder side of EA, this process was performed only from the perspective of the EA team.
Such artifact creation can be valuable. These models describe high-level connections between the different layers of the business and technology stack, giving the EA team a holistic picture of dependencies across the organization. However, this type of artifact creation is typically not well received in the absence of collaboration with and buy-in from the greater organization.
3. Build EA in a linear fashion
In an ideal world, enterprise architecture would be designed and in place before a business begins operations.
Think about it. You would never build a house and then draw up architectural designs, right?
You'd think the same linear logic from the physical world would apply in the business world. But it does not. In the business world, initiatives are up and running, solutions are being designed and technologies are being implemented while the enterprise architecture is still being built.
Unfortunately, EA practitioners gravitate to the linear mindset. They want the complete architecture to be in place before enterprise operations begin. This mindset makes it difficult to properly insert EA into a mature organization. EA teams spend an inordinate amount of time working on foundational artifacts up front without letting the realities of the current state business influence their architecture. By the time they complete the first step down this linear path, the pristine foundational architecture they created can be irrelevant and completely out of touch with where the business is actually going.
Given these hurdles, it's no surprise traditional approaches to EA so often failed in the past.
WWT's practical approach to EA
Meet in the middle
If EA didn't work before, why would it work now? The solution involves employing a more practical approach.
Figure 1 below depicts various approaches to architecture strategy on a spectrum. On one end is the ivory tower approach. On the other is a siloed solution architecture approach.
When an ivory tower approach fails, companies often over-rotate in response by removing EA from the equation and exclusively focusing on solution architecture. This reaction promotes silos that produce project-led architectures rather than architecture-led projects.
Each of the extremes along the spectrum has its own short- and long-term issues, and neither has proven successful.
Components of a practical approach
WWT takes a practical approach to EA that lies between these two extremes and provides a cohesive long-term vision without sacrificing short-term wins.
Our approach customizes a governance methodology that embraces rigor and discipline without slowing things down to a point that impedes progress. It also emphasizes collaboration from the start, which helps garner buy-in across the organization up and down the chain of management.
The three key components to building a practical EA function are:
1. Collaborate, collaborate, collaborate
EA teams need to descend from the ivory tower of abstraction and engage the rest of the business in their processes. Collaboration should be both upstream to executive leadership and downstream to key stakeholders, across the organization (see Figure 2).
In reality, executive teams own the EA portfolio of artifacts, not the EA team. Not only does upstream collaboration enable executives to advocate for the EA team's strategies and architectures, it helps ensure artifacts are in line with overarching business strategy. Executives can also help build credibility by leveraging EA material in day-to-day messaging, making buy-in from the broader organization that much easier.
Collaboration downstream is also key. The EA team's goal should be to curate the collective mindshare of the organization and document it in an organized and digestible fashion. Downstream collaboration builds consensus with key stakeholders, makes EA artifacts immediately actionable and gives stakeholders a sense of ownership over the artifacts. This promotes buy-in and wider usage throughout the organization.
2. Focus on the softer side of EA
EA leadership must emphasize hiring a team of people with the soft skills necessary to collaborate in the manner described above. Overlooking these skills can be detrimental to the success of the EA team.
The softer side of EA and its relation to the harder side is shown below in Figure 3. It is important to note these two sides are not mutually exclusive. In fact, they support each other and only together drive a successful EA function.
Finding people who can execute both sides may be challenging, but it is worth the pursuit. Without the softer side of EA, the efforts put into the harder side will go to waste and the organization will suffer as a whole.
3. Build an EA function in a non-linear, iterative fashion
Building an EA function in an iterative fashion may be the most challenging aspect of implementing a practical approach to EA and one that is completely dependent on the two other components discussed above.
While desire to build EA from the top down using a linear approach may be strong, flexibility is critical.
A more iterative approach, rooted in agile software development principles, enables EA teams to carefully select which initiatives or solutions to focus on while building the overarching EA program in parallel. Using this approach, the company is essentially building the plane while it flies.
Foundational and domain-specific artifacts
In EA, there are foundational artifacts (e.g., overarching architectural principles, EA governance, capabilities domain mapping) as well as domain-specific artifacts (e.g., strategies, roadmaps, reference architectures).
Domain-specific artifacts depend on foundational artifacts. Because initiatives and solutions with specific domains are already underway for most businesses, an iterative approach to EA allows domain-specific activities to continue while the overarching and domain-specific EA artifacts are built in an agile manner.
The best way to demonstrate this relationship within the overall practical approach is with a case study.
Case study: WWT's practical approach in action
Business challenges
A company that traditionally focused on two main product lines (Products A and B) was undergoing a substantial transformation. From a business perspective, they were betting on a shift in consumer demand across their product portfolio:
- Product A was doing well and they wanted to grow their brands in this portfolio;
- Demand for Product B, on the other hand, was rapidly declining as costs were increasing; and
- The company's Growth Strategy Team was investigating a new product line (Product C) that was outside their current portfolio but predicted to have high growth potential and synergies with their existing customer base.
All three product categories required a heavy focus on understanding the consumer. But because the company could only legally sell through distributors, they had limited direct access to consumer data and were forced to get most of their information through distribution partners and third-party sources.
The company decided to acquire a business that created Product C and divest a majority of their interest in Product B. They were also planning future acquisitions of smaller companies to grow their presence in local markets with Product A.
Technology strategy
The company's Chief Information Officer (CIO) realized a new technology strategy was needed to address some of the company's most pressing needs:
- The M&A activity was creating a highly complex technology environment with redundant information systems and applications, driving the need for rapid and accurate data integration.
- Meanwhile, to implement the company's vision to get closer to consumers through data analytics, they wanted to democratize data across the organization and enhance their data science capabilities.
- Finally, due to the M&A activity and the unpredictable nature of building a data science capability, the company needed on-demand access to massive amounts of compute and storage resources to handle potential fluctuations in resources.
The company needed to manage the complexity of their environment while designing analytics and integration platforms in the public cloud.
The customer engaged WWT to build an EA capability from the ground up, and to design and implement three key strategic solutions that should be driven by EA. The four workstreams involved:
- Building an EA capability as an umbrella program to drive key initiatives;
- Developing a multicloud strategy and building the minimum viable cloud;
- Developing a data analytics strategy and building a cloud-based analytics platform; and
- Developing an integration platform strategy and building a cloud-based integration platform.
Iteration at work
A linear thinker following a traditional approach would first try to build the company's EA capability before starting work on the three key solutions to ensure each was completely driven by the final EA framework.
WWT's practical approach, however, allowed for a foundational umbrella EA program to be built at the same time that the key solutions were being delivered. Our approach also focused on capturing buy-in up and down the chain of management.
Figure 5 shows the parallel workstreams in flight under WWT's practical EA approach.
Softer side
With buy-in at the CIO level procured, the company created small working groups for each workstream and a steering committee of the CIO's direct reports to act as the first Enterprise Architecture Review Board (EARB). The working groups focused on building strategies and roadmaps for their respective domains, while the EARB collaborated with the working groups on foundational artifacts. The CIO collaborated with his peers to feed the EA team business strategies and guide artifact creation.
Artifact creation
As they were built out, the foundations drove more clarity and consistency across the domain-specific artifacts. At the same time, the domain-specific artifacts fed practical information back to the EARB and CIO for further foundations building. These living and breathing EA artifacts were built on a platform that was easy to share and update. A coordinated approach to messaging and knowledge sharing was key to the success of our practical approach, as was mutual trust in each other and a willingness to engage in healthy debate.
Outcome
WWT's practical and iterative approach allowed the customer to successfully build out the overarching EA foundations from the ground up in parallel with the creation and implementation of its key initiatives and high-priority domain-specific artifacts.
The teams designing and building the cloud MVP, the cloud-based data analytics platform and the cloud-based integration platform were able to rapidly digest the EA artifacts and put the plans into action. These artifacts were immediately actionable and tied directly back to business drivers identified in the foundational EA.
Proofs-of-concept were built and tests were iterated until the solutions met all business needs. Because the EA artifacts were built in a collaborative nature, solution architects bought-in to the strategies and design from the start. This allowed the customer to quickly migrate their legacy on-premise data warehouse to the new analytics platform and leverage more powerful data science capabilities in their cloud-based data lake.
Post implementation, EA has continued to gain influence across the organization as the EA team has scaled to handle the continuous curation of ideas and creation of artifacts. The customer's executive team has become more comfortable feeding the EA team strategic insights from the business, and solution architects and engineers are benefitting from having specific guidelines and guardrails. This has resulted in quicker IT decision-making that is more aligned with the business. It has also given IT a more holistic and dynamic method for choosing investment areas for future capabilities.
Conclusion
The need for enterprise architecture is greater than ever due to multiplying complexities in business and technology. However, building and implementing an effective EA function can be challenging due to some common downfalls.
To overcome these challenges, WWT recommends a practical approach to EA that focuses on:
- Collaboration across the organization, both up and down the management chain;
- A combined focus on the softer and harder sides of EA, including emphasis on clear messaging, digestible and available artifacts, harnessing the power of persuasion and making sure the EA team is accessible; and
- Using an iterative approach to building the EA function.
This approach will lead to an EA team that accelerates confident decision-making and provides a holistic view of your company's future capabilities. Strategies will rapidly turn into designs and solutions will be implemented at the speed of business.
For more on WWT's practical approach to EA, sign up for our Enterprise Architecture Workshop today.