Capturing Value from Enterprise Architecture: Understand your field of play, solve tough challenges and drive transformational change

Introduction

Coming back with an interesting topic popping up quite often in the current dynamics of driving digital transformation during consulting engagements. Why does it seem (or better is) so difficult to setup and sustain an Enterprise Architecture (EA) function (or other-named head functions for transformation planning) serving as the cornerstone, holding your digital transformation efforts together and paving the way towards targets envisioned?

Maybe because it’s as much about organizational challenges and various people involved as it is about complex technology planning and delivery. It’s dealing with a lot of different people following different agendas, political dynamics and balancing change work with running the daily business – therefore it might be tough to focus and foster transformation activities.

From a general standpoint, people (and literature) often say that EA is linking strategy and execution as well as business and IT. Gartner refers to '…a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations ...'. CIO Magazine summarizes EA as '...the practice of analyzing, designing, planning and implementing enterprise analysis to successfully execute on business strategies'.

So, within the broader company context an enterprise architect is identifying, assessing and solving, most likely a mix of business and IT related, critical challenges for the stakeholder of interest to meet their key objectives around e.g. strategic or technical fit, quality, cost, and delivery timelines.

The need of an (enterprise) architecture function varies quite heavily depending on where it sits, related audience and expected results to produce – from a Corporate to CIO/CTO office to IT delivery function. Therefore, to be successful, it’s key to understand where you are and who is around you.

Approach

But what does that mean, and how does it pay off? So how do we come to a reasonable scope and actually get work done if it’s so broad? What is the EA function working on?

Basic aspects from my side are on the one hand solving problems that really matter to your organization and on the other hand knowing your stakeholder and customers, their needs and their supporters. If these are not known, you most likely end up in having no clear seat in any place. Link your work to key challenges, which is the only chance to link your work to important priorities of your organization, whether that be business or IT, best heading towards business and leadership priorities. If you cannot prove that for most parts of your functions work, it will be difficult to prove the value and justify your function’s existence and therefore funding. Third, you need talented people being able to survive and drive change in complex and political context.

Suggesting a stakeholder-oriented approach to link EA work directly to your organization. It works no matter what size your team is, supporting to refocus and clarify priorities. One could also take a corporate business strategy / objectives approach directly, but it’s most likely too far away and not linked to actual daily dynamics.

The approach below summarizes one potential way towards capturing value from enterprise architecture and provides anchors for your efforts. It should help to work on concrete results requested from your stakeholders and link these to strategic dimensions.

Understand Your Field of Play: basically means to look around, listen, interact and reflect on who are the stakeholders around you and your reach, whether that is in IT or business, and BU or Corporate Center level, depends on where your function is located, project organization environment possible. Essential to understand their concerns, questions and required support.

Align Position and Direction: Align the needs analyzed with your own organizations targets, the firm’s overall strategy and build a fair triangle – while coming to a certain positioning (strategic coach vs. delivery unit) and direction serving as a motivating north star for your function.

Define and Evolve Services: tailor the offers towards the needs of your stakeholders, coming up with a service menu covering clear-to-understand work products (e.g. IT roadmap, app assessment) and capacity/skill-driven services solving tough problems (project delivery support, PoC).

Line-up Delivery Capabilities: all about how you will deliver the services and support to the stakeholders in your scope. This might happen via people in your function, agreed team-ups with others in your firm or partnerships with external suppliers.

Design Roadmap: prioritizing and planning the service delivery capabilities and teams, in initiatives or towards defined work products, covering timelines, responsibilities and budgets. This helps to focus on a limited set of services and provide an evolving plan for the EA function.

Collaborate and Execute: mobilizing your function, working on early proof of value with quick wins like e.g. delivering a small project, assessment of a business domain, or an executive presentation simplifying a complex topic. Beside evolving the function with a collaborative, community of practice approach.

The approach and proposals outlined should serve more as meaningful input for your planning efforts and reflections, less as a strict route. Next, we run through the first three steps in more detail.

Understand Your Field of Play

Gartner recently published rules for business value of IT around crafting and articulating impactful (business) value stories helping stakeholders to make sense of and buy into (technology) initiatives including e.g. stakeholder determine the value, communicate IT value in stakeholder’s language, measure based on stakeholders’ objectives, and ensure sponsors understand contributions. CIO Magazine states '...doing just enough enterprise architecture to balance speed with long-term, strategic insights for better business value'.

Especially in the first weeks and months (first 100 days), and review cycles, it’s necessary to identify, meet, listen and understand your key stakeholders. Best would be to have first discussions with them to check their perspectives and mindsets. These stakeholders will have questions and concerns, sometimes to be uncovered throughout time, that matter to them and are of their importance – definitely note these and keep them in mind. These define their focus of work and frame their agenda. Their emotions, values and politics might play a role in shaping the focus of work.?

Once you made a call on the key ones (which might change over time 'unfortunately') you can focus on follow up, enriching you notes and summarizing their key concerns and questions. Below there is an example covering potential stakeholders, exemplary questions and their focus serving as a frame and template to indicate what to work towards.

For some more aspects to consider the value of EA and potential work products feel free to check out the Architecture & Governance Governance Magazine article (see sources).

Once your key stakeholders are defined it most likely helps to provide them with key attributes and position them on a matrix addressing the dimensions of orientation or focus (business to IT) and planning horizon.

Overall to say if your key stakeholders are in IT functions it’s most likely more technical questions and objectives – still it would be key to link them ever somehow to the business side (objectives). The part of business architecture dealing with driving change on business side covering e.g. value streams, processes, and products / services seems to still lack attention in most companies.

According to them your function might focus more on business topics (e.g. in alignment with process mgmt. and business architects) or IT topics around IT planning, solution architecture and agile software delivery. Range from tactical or implementation planning with clear steps to implement or strategic mid-to long-term and change topics with more uncertainty while also keeping in mind your position around a central vs. BU-aligned role.

Based on these you build your initial priority list based on additional criteria like e.g. indications on urgency / impact vs. efforts.

Analyzing existing information about strategic directions on business and IT side supports to frame your mind. For upcoming challenges and initiative planning it might help to use a value tree connecting your work with strategic objectives of the organization around growth, risk and efficiency. While this is a stakeholder-driven approach, you could of course be driven by immediate pressure, key programs and so on, these need to be added to this list, to include them in discussions on priorities.

This provides an indication about the field you are working in, think of your future position (scope of people and work) and the need for different communication styles, types of work and results you will produce.

Align Position and Direction

Most likely this remains a tough part, as you might have conflicting targets from your own reporting line compared to what you got from your stakeholder analysis and the firm’s strategy, even more complex in a multi-BU /region setup. It’s individual to the setup of your industry, organization, culture etc. - kind of aligning top-down and bottom up comes into play here, and type of work expected.

Based on the initial, crucial set of stakeholders and their concerns assessed you would be able to set parameters and frame your position of driving the organization towards digital transformation success. Depending on that you would think of a motivating position for our EA team and a corresponding community approach. Selected examples are listed below spanning a range from strategy to execution.

Strategic Coaches offer support, advice and mentorship along strategic and leadership areas and challenges, e.g. a CIO/CTO (or even CEO office) related EA team will most likely work on strategic / or mid-term planning topics and executive questions, loosely linked to solution architecture teams. Beside they spread the vision of architectural thinking (in simple ways) across the enterprise supporting to broaden the understanding of holistic planning. Downside here might be a certain detaching from project, product or software delivery work.

EA Consultants would go for a (pure) problem-solving based model focusing on a key challenge or work staffing based as project architects. Small, fast-paced project help to be quite dynamic and fast. Downside here is that overarching perspectives are most likely not created, only in case of dedicated enterprise level projects. – to be honest a lot of central EA department have at least some people working this way anyway, because they have limited team resources.

The Delivery Powerhouse would be aligned to deliver results either in form of a large transformation program or implementing a software solution defined (e.g. CRM / Salesforce). On the one side it would play a vital role on portfolio level structuring epics, aligning portfolios, etc. (for more to get a feeling check e.g. the Scaled Agile framework). On the other side it would be an EA team aligned to a transformation program delivering a defined range of solutions like e.g. a new core system and related CRM - they support planning towards that, much more solution architecture oriented.

Fully aware that in daily doing, beside executing a feasible approach, political dynamics and your organizational alignment are playing a major role. Political discussions will make a clear positioning difficult, still these thoughts to think about your main audiences, or at least to consider audience, their information need, and type of contributions required. Therefore making it even more difficult, you might need to run different approaches and working styles for different stakeholders.

In the end positioning comes down to 'what you are and what not', so you need to go for trade-offs and select in alignment with your reporting line and key needs uncovered. A generic approach on all levels will most likely fail because the range is too big, expectation-wise, delivery-wise, culture-wise etc.

There are indicators that you want to think of when finding that motivating north star and positioning like e.g. ways of working (enforcement centric vs. influence centric), methods/approach (cycle vs. continuous, conceptual vs. lightweight) and use case levels (group-wide vs. divisional/function vs. domain or single delivery piece). Beside key principles guide your thinking along the way and provide guardrails for driving decision-making. These need to be easy-to-understand and communicate. Some graphics make them more reminding.?

You need to define the reach of principles, whether company-wide, Group IT, or towards architecture work in projects. Structure-wise you could follow areas of architecture (e.g. governance, business, application, information, technology, and security) and nail principles down per each like e.g. going forward cloud first vs. cloud by case, rent before buy before build, facilitate agile architecture planning.

Define and Evolve Services

Beside starting to deliver first results as mentioned (quick wins, best small, fast paced based on urgent challenge), you might think of relatively stable services expected from your EA team. You could get inspired by looking at classic EA deliverables (artifacts). These could be quite different according to your field of play (C-Level recommendations vs. agile software delivery).

We could differentiate between direct services delivery to the stakeholders and foundational services required to enable these EA efforts. Below you find some examples to get your mind going and start with a first list:

The business architecture part (here Digital Strategy, Product Mgmt.) is often misunderstood or lacking maturity – people evolving in business planning functions or process management on the business side evolve work in the area of BA. Best would be a teaming-up with other team in your firm to build a feasible service offering in partnership (e.g. with BPM team, CIO office, etc.), with the upside effect of knowing where certain planning functions actually sit.

In the following we take three services giving them just a brief call out. In line with our people and demand analysis each service should be linked to stakeholders consuming them, and strategic objectives (e.g. growth, risk and efficiency).

E2E Process Management and value stream management focus on analyzing, structuring and refining processes from a customer-oriented perspective to understand customer expectations, facilitate efficiency improvements, establish standards, improve procedures and communication, and support digitization and automation. There will be an upcoming article to cover this in insurance industry.

Application Portfolio Analysis (Rationalization) covers an analysis of the application landscape corresponding to business process or capabilities they support to create transparency, reduce costs, risks, and complexity or raise flexibility. Potential levers include e.g. application decommissioning, license optimization, shared services. These would be structured along a timeline for quick wins, efficiency gains and reorganization / renewals (check LeanIX sources).

Cloud Assessment determines your organizational readiness, ways of cloud usage, and cloud migration efforts through application discovery and assessments based on the cloud strategy covering e.g. Why to move to the cloud?, strategic decisions based on business capabilities and platform decisions - Which functionalities? Which vendors? How to interact?, Whats the cost frame? etc. (check AWS sources).

For delivering these services its often required to link information from across the company on different levels. Below there is a proposed scheme to indicate areas of architecture and related information pieces / objects you could connect.

During your work, you might come across supporting structures serving as an analysis starting point, aligning people toward the desired direction and working towards achieving your objectives. Below, there are common examples. More to come in a take on reference architectures.

These supporting methods and models (endless discussion field in the EA profession) should support framing, analysis, aligning, deciding, planning and especially solving challenges - not making it more complex and slowing down day-to-day work when coming into play. Still it needs time to prepare and maintain these to be helpful and connected to the firm's context (foundational EA work). If you like to read more on what the results and documents of an EA department could be like e.g. principles, roadmaps, etc. feel free to check the articles from Kotusev (see links below).

Following Steps to specify delivery of EA capabilities, define roadmap and execute

Your operating model supports to make all this happen and organize the EA function from perspectives of governance, performance, roles & responsibilities, key processes, ways of processing information and common tools.

An EA Governance based approach with fighting for complying with tech standards and central directive kind of failed in most organizations (e.g. as funding of projects and power decide on who gets it). Giving it a try on being an open-to-support coach and contributor with improving step-by-step mindset, building a community of practice around interested people from all over the company and hiring great people (that will do the job) sounds like a feasible way of working.

A sustainable collaboration model - how to work together with key functions and stakeholders - supports to join forces in guiding activities ranging from business departments to solution architects and SW delivery. From a talent perspective not everyone in the architecture function needs to be an architect when joining. Over time colleagues willing to learn and grow evolve skills fitting to the team – recognizing that architecture work is a big call on communication, balancing stakeholder interests it’s definitely a rich-in-variety job, e.g. for ex-consultants. Sizing and funding an EA team might be based on business and IT complexity of a firm and industry, amount and size of transformation challenges to solve, architectural thinking / EA approach taken and foundational work to prepare.

Beside planning mid-term, you have to deliver small pieces of value early. If you say it doesn’t work like that in your firm make suggestions to your stakeholders outlining potential EA contributions. Guess they don’t know it all, just provide them with a working draft for discussion on a key challenge. Finally if there is no understanding of architecture work at all consider engaging in a role that uses your thoughts.

Following up by defining a roadmap with key milestones towards objectives and evolve your EA function mobilizing and getting key people on board in a collaborative way.

Summary

Talking through this already took a bit of time and gives a glimpse about the exciting way you walk through to establish a successful EA function. You could follow the steps to come towards a reasonable scope, position and work statement for your EA function supporting planning and transformation efforts. It’s stakeholder-driven and communication heavy - so no silver bullet to win here beside evolving based on constant interaction and iterations, supporting to solve key challenges and staying close to respective leadership, expanding and making more friends over time.

Upcoming articles might focus on E2E process management in Insurance, using reference architectures in a feasible way and catching up on selected EA services.

Note: This article reflects the private opinion of the author. Unpaid advertisement.

Sources

Arch & Gov Magazin (2022) Develop a business case for the organization’s EA Practice

AWS (2018) Assess your own cloud readiness: create a roadmap for cloud migration

AWS (2016) Considering a mass migration to the cloud

CIO Magazine (2022) Five steps to minimum viable enterprise architecture

CIO Magazine (2018) What is enterprise architecture? A framework for transformation

Gartner (2022) Glossary: Enterprise Architecture

Gartner (2022) Demonstrating business value of IT

Kotusev (2022) Enterprise Architecture on a Page

Kotusev (2017) Eight essential enterprise architecture artifacts

LeanIX (2022) Answers to important questions of EA stakeholders

LeanIX (2022) Application Portfolio Management

McKinsey (2018) Five EA practices that add value to digital transformations

ScaledAgile (2022) Framework (portfolio / EA level)