Click to learn more about author Jason Baragry.
Today’s enterprises are operating within a VUCA world that requires constant change to meet new opportunities, competition, customer expectations, digitalization, and acquisitions. Enterprise architects provide the competence needed to navigate this change, understanding the benefits, costs, and impacts of transformation to enable CIOs and COOs to make informed decisions and drive forward strategic change.
However, enterprise architecture (EA) teams are not always delivering as they should. In fact, Gartner estimates that 42% of EA initiatives have disbanded and rebranded in the last five years – but what is setting so many of these teams back?
To answer this question, our company recently surveyed more than 100 EA teams across geographies and industries about their most common mistakes. Keep reading for their answers – and to learn how your EA team can prevent themselves from making the same missteps.
Mistake 1: Not Having a Clear, Business-Driven Goal
Our survey reveals that the most common mistake EA teams are making is not having a clear business goal with a clear business stakeholder. Building and maintaining artifacts like process documentation, building business capability models, IT-focused target architectures, and complex metamodels of the organization mistakenly become the goals themselves rather than simply the tools to deliver business-driven outcomes. If architects don’t know why they are performing these activities, then they don’t understand their business and how they can improve it.
Architects must establish objectives and key results (OKR) to guide their efforts. This includes defining measurable benefits as well as designating who will own them. A goal may be to reduce evaluation time in the strategy to portfolio process, reduce customer-facing downtime, or provide a target reference architecture that can allow teams to know where they can take autonomous decisions and thereby improve project throughput. Regardless, the key is to always have a business-driven outcome as the reason for performing the EA activities. Even tasks as seemingly simple as documenting how business operates through IT can be driven by a business outcome.
Few people outside of the EA team may understand the complexity of the IT interactions needed to deliver business capabilities, and so explaining the reasoning behind changes in the context of business goals for others within the organization can help build trust and correct the opinion of IT as an assumed bottleneck and cost-center. To this end, architects should focus on documentation for the sake of others’ understanding and not for the sake of their own.
Mistake 2: Working with Low-Quality Information About the EA
Enterprise architects must facilitate strategic change and governance processes to enable fast, agile organizations. The increasing rate of change and IT intensity of organizations requires quick, high-quality decision-making based on information that leaders can trust. However, architects may find that after building a repository of information for their organization as it currently stands, that data’s usefulness quickly erodes as the organization continuously changes. This results in EA teams spending more time reactively documenting to keep records up to date than they do on proactive strategic design.
Data-driven EA is needed to quickly answer where the impact of changes will be within the organization, who needs to be involved in the project, what the ripple effects will be, the total cost, when the benefits will be realized, and what (re)prioritization decisions need to made. That data must be trustworthy – otherwise, decision-makers won’t have reason to involve architects in the decision-making process moving forward.
The days of always running months-long pre-projects to determine this information is over. Fast-changing companies cannot and do not have time to stall projects with data collection. The only way to keep information up to date in the continuously changing environments we now face is through a combination of automation and data democratization: automation to update architecture models from the source of data (e.g., maintaining models of applications and deployment infrastructure direct from continuous build pipelines), and democratization to allow those with the most knowledge to update the models themselves, on a continuous basis. For example, democratization would be to allow system owners to regularly update technical fit information or the link to relevant business capabilities for their applications in the architecture repository so that architects don’t have to chase down this information themselves.
Mistake 3: Failing to Engage and Communicate Across the Organization
Another common mistake enterprise architects make is failing to communicate and collaborate effectively across the organization. All architects want to be part of the strategic change process of their organization, but sometimes they can become disconnected from their colleagues. This disconnect is two-directional: Whether intentional or not, some EA teams can act like an ivory tower of decision-makers. Likewise, stakeholders on both the business and IT sides can perceive EA teams as a bottleneck, and exclude them from their own transformation planning.
EA has the power to facilitate organization-wide change, but EA teams need to be an active part of the business units and explain the target approach and the benefits it provides – to both the business architecture and application architecture – if they want to make proposed changes a reality. As continuous change happens, stakeholders are often driven by a primary motivator such as time-to-market, short-term benefit realization, or IT cost reduction. It can be difficult for all – especially business unit owners – to see beyond their next budget allocation cycle, which is where architects can step in. By showing the tradeoffs between strategic and tactical approaches and long-term and short-term decision making, architects can help the wider organization build a plan that achieves immediate goals while still working towards overarching missions.
For the architect that means treating the target as a direction rather than a destination, explaining the benefits of an initiative and then compromising on the steps needed to get there. This also requires providing possibilities for smaller steps that meet short-term targets while still enabling the longer-term vision to be achieved.
Mistake 4: Sourcing EA Information That Doesn’t Capture What Is Actually Needed to Make Decisions
Traditional EA has focused on modeling business, application, information, and technology architectures, but decisions about proposed changes need to be based on even more holistic data. Instead of zeroing in on IT infrastructure, EA teams should look at variables such as which employees are involved in a proposed change project, how long the project will take to execute, what the current priorities are for transformation, how proposed projects can link to overarching strategies and objectives, what the anticipated benefits are and when they will be realized, what the costs are of implementing the change, and what the opportunity-cost or cost-of-delay is of not making the change.
Architects need to link together the traditional, structural architecture information with operational information to deliver these changes. This needs to be done continuously in order to shorten the time-to-decision that is needed in an agile organization. Decision-makers need help, not just with where a change will impact but when that change can occur and what alternatives can be discussed to get to market more quickly. For example, models of the application landscape need to be combined with information about teams that maintain those applications and the projects they are currently working on. This operational information typically changes faster than the structural architecture information and so is even more important to link together and update automatically.
Mistake 5: Focusing on EA Techniques Rather Than Business Outcomes
Architects can also fall victim to spending too much time focusing on techniques and notations rather than providing useful outcomes. Think: hours spent discussing the “correct” metamodel for all situations, modeling the business processes to the lowest level with inch-perfect BPMN, trying to communicate with business stakeholders using Archimate notations that included all possible levels but that were unintelligible to anyone outside the EA team, and trying to slavishly follow EA frameworks and methodologies. The old adage “All models are wrong but some are useful” also applies to EA, meaning architects need to focus more on being “useful” than trying to be “correct.”
Ultimately, it’s impossible to plan upfront for all possible changes, so architects should take a data-driven approach that enables them to be agile in their efforts. Following from Mistake #1, EA teams should use the outcome they are trying to achieve to inspire how they use tools, techniques, methodologies, and notations. To that end, architects should focus on just enough metamodeling, process and application modeling, and notation to achieve that outcome, versus bogging themselves down trying to be complete or perfect with their datasets. After all, how architects use those tools and techniques will need to evolve over time anyway as new goals emerge within their organization.
Don’t Let EA Missteps Shortchange Your Organization’s Transformation Momentum
EA has the power to deliver big on organizations’ desires to digitally transform, but only if those executing it plan adequately beforehand. To position your EA program for success, be sure to start with a clear objective for change, mapping your efforts to larger business goals to ensure EA drives relevant, contextualized value. Engage the entire organization, from stakeholders and members of the C-suite to employees across departments and seniority, for holistic insights to guide areas for improvement, and prioritize ongoing, quality data collection and presentation to keep plans on track and up to date and be able to communicate progress to colleagues. By making some internal culture and process shifts, investing in EA tooling that facilitates collaboration and automation, and empowering flexibility and agility during times of change, EA teams can put themselves on the path for success and drive EA initiatives that live up to their potential.