Enterprise architecture is similar to electricity in more ways than one. Like electricity, architecture is often out of sight, out of mind. That is until it stops working, at which point it becomes painfully obvious that something integral is missing.
Architecture bears another similarity to electricity: throughout history, plenty of people lived their lives without it. I would have loved to have witnessed some of the early-era electricians trying to “sell” homeowners on the concept of electrification. While the electricians knew how useful electricity was, the homeowners probably rebutted that they got along “just fine” without electricity for many years, so why fork out the hard-earned cash for this newfangled fad called electricity? In many ways, organizations without an enterprise architecture practice have a similar mindset today.
In this article, I’ll articulate the key value proposition of enterprise architecture and enumerate several of my own “lessons learned” during the instantiation of several EA practices.
Symptoms of lacking architecture
Before jumping into the value of enterprise architecture, let’s quickly examine some of the organizational symptoms we observe when EA is either lacking or absent entirely. These symptoms often emerge as grumbled phrases such as:
- Why do we have four different content management systems?!”
- “Do we have a company-sanctioned instance of AWS? Who manages it?”
- “Where’s the roadmap for all these interdependent technology initiatives?”
- “What are all these technology projects going to cost, and what’s our ROI?”
- “Doesn’t this project conflict with that other project?”
- “Have we considered alternatives? If so, what were the pros and cons?”
- “How does this effort align to our current fiscal year strategy? Can’t this wait?”
- “Why isn’t anyone looking at all of this holistically?”
Without an overarching design and strategic alignment methodology, these and other terms of turmoil will continue to reverberate throughout the halls of one’s company; leaving executives perpetually confounded by the constant surprise and confusion associated with siloed thinking.
Enterprise Architecture Value
Enterprise architecture saves money, accelerates results, simplifies the complex, and aligns technology endeavors to corporate objectives.
If you’re concerned about what enterprise architecture may cost, think about the cost of not having enterprise architecture. Among the anti-architecture quotes above was one of having multiple content management systems. Imagine how much worse such the situation would be if an enterprise haphazardly deployed mission-critical CRM or ERP systems. EA actually saves money by identifying redundancies and building common solutions. By coupling these reusable solutions with methodical decision making, EA accelerates results by eliminating the repetitive, reinvention-of-the-wheel style of decision making we see in less structured environments. Moreover, the introduction of standards and frameworks simplifies the complex; thus decreasing confusion and accelerating shared understanding of technology and business. Last but not least, EA aligns initiatives to strategic objectives so that chaotic project workloads can be focused on the highest value-add endeavors.
The value of enterprise architecture isn’t purely strategic. There’s practical, “real world” value in EA operations as well. An enterprise architecture practice that produces sound designs enables engineers to focus on implementation versus going back-and-forth on the design itself. A related, yet positive side effect of this phenomenon is that EA alleviates contention between factions. When viewed as a relatively neutral third-party, EA can mediate contentious impasses among engineering and business teams. Finally, EA connects the dots between strategy, design, and implementation through both top-down and bottom-up activities which create a continuous, circular feedback loop across all levels of the organization.
Clearly Defining Architecture
Given it’s macro-level focus of enterprise-scope, enterprise architecture is often compared to city planning. If you could close your eyes and be magically teleported to the center of a bustling city, you’d likely see skyscrapers being erected, new luxury condos being constructed, and slew of workers conducting various maintenance activities from replacing old fire hydrants to repaving battered city streets. Now imagine if none of those activities were orchestrated. One developer may build a skyscraper that consumes too much power, thus creating blackouts for thousands of city dwellers. If the street pavers fail to sequence their work with the plumbers, then the fire hydrant replacement crews will inevitably dig up the newly-paved streets, permanently scarring what was recently beautifully-smooth new asphalt.
Part of building a successful enterprise architecture practice is having clearly-defined roles and boundaries for the architecture team. Continuing with the civil engineering analogy, we could say that the enterprise architect is akin to the city planner, solution architects are like city developers who are focused on one building at a time, and engineers are the carpenters who actually build the solution.
There are other roles as well, including functional and project managers who are accountable for results and team progress, respectively.
EA Challenges
Enterprise architecture creates immense value. Yet as the old saying goes: Rome wasn’t built in a day. It will take time to build an EA practice, and there will be challenges along the way. In particular, there are three common dilemmas often associated with newly-created EA practices. These include:
- EA being perceived as “IT-centric” and thus not business-relevant
- EA leadership consistently “outranked” by their business counterparts
- Ambiguous communication paths between EA and functional business units
“If you’re not with us, you’re against us” is yet another adage that business units often express towards nascent EA programs. In other words, if you’re not part of (Finance/Sales/Marketing/insert-other-business-unit-here) then you are “something else.” Just as our forefathers didn’t understand electricity, EA will need to be justified in order to secure its rightful place in the enterprise.
When EA finally proves its worth as a whole, individual EA practitioners may at times find themselves “outranked” by their business colleagues. An example would be an enterprise architect who has a director-level title, yet her peers are primarily vice presidents and above. While architects need to be persuasive, gaping chasms of authority inevitably breed power struggles. At least one of the architects, ideally the chief architect, should have a title that is on-par with the incumbent senior leadership team.
Ambiguous communication paths is perhaps the most common challenge for new EA practices, yet is fortunately the easiest to fix. Ambiguous communication paths emerge when business unit leaders become confused over who is accountable for results. For example, a vice president of marketing may have simultaneous lines of communication open to an IT director, an enterprise architect, and a project manager. It’s not always clear that the EA is focused on design and standards, the IT director on resources, and the project manager on execution. VPs and other senior leadership want “one throat to choke,” so having clear rules of engagement is a must when multiple teams are communicating at once. Typically an SLDC (preferably of the agile variety) can aid in streamlining “who gets involved and when” for such initiatives.
Architecture Deliverables
Enterprise architecture goes well beyond compiling pretty diagrams and slide decks. Perhaps the most prominent duty of the EA practice is creating and amending organizational standards. This ranges from rationalizing the portfolio of business applications, to creating a finite set of infrastructure services, to streamlining communication and collaboration tools used by knowledge workers. Of course, standards will change over time and therefore the EA program must have efficient ways of amending standards in order to stay current with technology trends.
With standards in place, architectural artifacts should be centralized and routinely curated. The process of maintaining the architecture repository is one of presenting readily-accessible artifacts to the entire organization in a structured, easy to consume format. Additionally, the EA function should hold architecture review boards where the business processes and technology solutions are socialized in a manner which solicits feedback so that solutions are constantly aligned to business expectations.
In addition to ongoing EA activities, the enterprise architecture function must be leveraged for guidance on all major projects. This requires the EA program to have a “fit criteria” so that the business knows when to pull in an architect, versus when they can fly solo. An simple fit criteria would be “EA involvement for all technology endeavors over $100,000” or perhaps “EA must be informed when cross-functional business process changes are proposed.”
Enterprise architecture should assist management with skills forecasting so that managers can hire and/or retrain existing staffers to keep up with technology trends. And finally, as a management practice itself, EA must maintain and publish enterprise architecture KPIs just as any other business unit would do for their internal operations. These are just a handful of examples, and of course EA practices will differ from organization to organization.
Hiring EA Staff
While there are many ways to build an EA practice, I’ll provide two core dimensions that require focus. The first is where the EA practice reports into, and the second is how quickly to ramp up the practice itself.
With respect to lines of reporting, EA is often born in the IT department and remains there forever. Other architecture practices report directly into a “business operations” type group. Still other EA functions are “virtual teams” that are piecemealed together from the various business and technical groups throughout the company. Regardless of the path taken, the key point here is that EA as a function must have some degree of authority, budget, and staff. Take away any one of those factors and EA is crippled.
As for how to ramp up the EA team, there are two coarse-grained approaches to consider: the incremental approach and the “big bang” approach. Starting with the latter, the big bang approach is taken when a full-fledged EA practice must be instantiated all at once. This likely means creating a new cost center, a new manager, and headcount for multiple solution architects. This is shown below:
The upside to this approach is a faster ramp-up to a highly capable enterprise architecture practice. The downside is that the approach is considerably more costly and you run the risk of overbuilding the team.
The incremental approach on the other hand is a phased methodology, whereby architects are hired one at a time, with the first full-time architect serving “double duty” primarily as an enterprise architect who also performs some high-level solution architecture as needed. Specialized solution architects may be “crowdsourced” for projects with dotted lines to the EA. For example, a major data center refresh project may require the top network engineer to function as a part time infrastructure architect, again with dotted-line reporting to the new EA.
The incremental approach is considered less risky than the big bang approach as it shows value prior to additional investment. The flip side to the incremental model is that tactical solution architecture work may detract from strategic EA activities. Dotted line reporting may also not bode well with certain organizational cultures.
In all approaches I do recommend some degree of consulting. Learning from experienced experts is more affordable in the long-run than learning from trial-and-error on your own.
Summary
Like electricity and smartphones, enterprise architecture has become a modern mainstay that assists in streamlining our highly complex work lives. However, EA often requires some degree of sales and marketing in order to take root. Yet when implemented correctly, a fairly modest investment in enterprise architecture can save considerable time, money, and human resources when compared to organizations without such a practice. Hopefully this article will help you on your path towards enterprise architecture maturity.
