Skip to main content

Effective approaches to Enterprise Architecture organizations

Not all Enterprise Architecture organizations look the same. Here are three common patterns–along with their shortcomings–to consider adopting.
There are lots of strategic opportunities and risk involved with architectural decisions.

Photo by Mihai Surdu on Unsplash

The Enterprise Architecture (EA) function in large organizations has evolved, devolved, and in some cases, even revolved. The industry, business environment, skills of the practitioners, and the organization from which it grew can cause the EA function to take many forms and serve many purposes.

As enterprise-class IT organizations continue to adopt better DevOps practices and embark on long-overdue journeys seeking to eliminate perceived boundaries between Infrastructure and Operations teams and software development teams, EA's core mission is further scrutinized. EA's principal mission to preserve and secure existing business technology investments while balancing the need to design and deliver new solutions remains critical, but what is a practicing Enterprise Architect to do when that mission begins to appear superfluous in the eyes of those who establish the operational budget?

I have spent most of my career working on enterprise architecture. I was recently thinking about how organizations navigate through their annual budget season. It made me reflect on the types of business values that EA organizations provide and the risks each type must mitigate to maintain relevancy. I have found that the business benefits of robust EA organizations generally fall into three categories.

1. Strategic & Immediate

These Enterprise Architecture teams truly look across all functions of the enterprise and into the future. They continuously examine the dynamics of the business environment to determine how market opportunities might or should be combined with advancements in technology to drive the company's future. That focus is clear: The future. They partner with business development teams and are often responsible for "innovation" projects. New technologies' application to new business models is prototyped or explored via limited Proofs of Concept or pilot implementations. Finally, they maintain a level of expertise in organizational and operational disciplines to ensure that the enterprise is fully prepared to deliver services to its customers.

One risk that this sort of EA organization must mitigate is the impression that they are looking so far into the future that they fail to contribute to the company's immediate business needs. This can risk their internal reputation and, ultimately, their effectiveness.

2. Governing & Guiding

EA organizations establish standards and guidelines for how the enterprise will acquire and implement business technology. This mission drives efficiencies in both implementation methods and investments across the enterprise. It includes developing IT product and tooling evaluation procedures and establishing standards for the use of third party technologies. They often establish centers of excellence dedicated to specific solution domains to guide the enterprise-wide implementation of new technology investments. They also ensure that any new technology investments can be effectively integrated into the existing IT environment. Unlike the Strategic teams mentioned above, they focus more on developments in the technology space and spend less time examining business trends.

These organizations run the risk of getting perceived as "ivory tower teams" that produce a lot of processes, opinions, academic artifacts, and guidance but can be ignored entirely by their various business units in favor of more rapid (although less strategic and less "enterprise") solutions. And nothing generates business unit specific "shadow IT" processes and decisions like toothless enterprise governance.

3. Tactical

These EA organizations appear to be an evolution of one or both of the other two types. Results-oriented leadership disperses a team of experienced senior IT expertise across the organization into various business units or divisions. The idea was to leverage their experience to guide decisions and implement solutions closer to the business or end customer. They provide application development advice and business technology leadership to their respective units. Particularly in organizations with disparate businesses, this makes them more effective in applying specific technology to solving unique requirements. Representatives from the various departments often constitute a leadership body to lead or mediate technology decisions and collaborate on enterprise-level implementation issues. This type of organization, being focused specifically on only their own division, runs the risk of being relegated to the sidelines regarding strategic decisions. This has the highest likelihood of occurring when new C-level IT leadership is brought in and institutes a more strategic EA function with minimal input from business units.

This tactical approach to EA holds the least amount of risk, but it is also the least "enterprise" approach. It tends to reinforce tribal behaviors and legitimizes "this is the way we have always done it" decisions.

Architect intentionally

Naturally, many hybrids of these organizations and the types of value they provide may also exist.  It is important to keep in mind that when properly establishing and operating an EA team, each type can effectively guide IT decisions, investments, and return a great deal of value to the business. This keeps them from becoming the fourth kind of EA organization that I have also encountered far too often–ones that are disbanded for providing no perceived business value to the company.

If you are creating an EA function, do so with intention and share how you did it here on Enable Architect.


Topics:   Career  
Author’s photo

Douglas Allen

Douglas W. Allen leads teams that help forward-thinking organizations design and deploy enterprise-class business technology solutions. More about me

Related Content