What does an Enterprise Architect do in SAFe?

Warning: This is a rather boring article, which is primarily relevant to readers, who accept that SAFe® and Enterprise Architecture are relevant in general, regardless of whether you personally like it.

This article is intended to be usable as a reading guide on the responsibilities of the Enterprise Architect in the Scaled Agile Framework®. I will present my own interpretation, based on different sources in the SAFe pages and on my experiences working as Enterprise Architect. Please be aware, that I have no practical experience as EA in a SAFe implementation, but only as Solution and System Architect, so some of this is quite theoretical. Luckily for me, Enterprise Architects are not known to be antagonistic to theory 😉

Disclaimer: Content in this article has not been verified by Scaled Agile, but use of trademarks etc has. Please refer to official website https://www.scaledagileframework.com/. See copyright notice at bottom of the articl

SAFe formal descriptions

“Enterprise Architects work with business stakeholders and Solution and System Architects to implement technology initiatives across Value Streams. They rely on continuous feedback, foster adaptive design, and engineering practices, and drive programs and teams to rally around a common technical vision.”

Full description: Enterprise Architect

This definition may seem somewhat esoteric to people who are not well versed in SAFe. A slightly more practical description is given in SAFe Role Dictionary:

“The Enterprise Architect – This person works across value streams and programs to help provide the strategic technical direction that can optimize portfolio outcomes. The enterprise architect often may act as an epic owner for enabler epics.”

Notice that you are not a role but a person in the SAFe descriptions. Solution and System Architects are roles.

My impressions of ‘Enterprise Architect’ in SAFe

The overall purpose of having Enterprise Architect is much the same as in traditional IT organisations, but what you do and especially HOW you do it has changed drastically in Agile contexts.

SAFe has a dedicated place for you in the grand picture, (if the Enterprise/Government include the Portfolio level of SAFe). This means that you are recognised as an important stakeholder on the portfolio level – which will open doors for you.

SAFe does not tell you ‘How To Do Architecture’. SAFe prescribes some shared artefacts like Portfolio Backlog, but you have a free choice on what tools and artefacts you would like to use in order to communicate and share your thoughts and work.

There is much weight on the tech side but less on the business side. An example is ensuring a viable long term Architectural Runway. This mainly concerns technology but does require an excellent understanding of Business visions and goals. If you are strongest on Business Architecture, you may have to work on getting help for the tech stuff.

The biggest change from traditional Enterprise Architecture will be conforming to the Lean-Agile mindset. This may mean that you officially have less authority on paper – but you most likely didn’t have that much authority in practice anyway! Much of what EA’s do in the traditional role is regrettably ignored in most organisations.

Mindset and Agile

‘Agile’ Mindset and differences between traditional and Agile:

• Changing role to an Agile context. See my article ‘Play a new role as Enterprise Architect’ and ‘The Role of an Enterprise Architect in a Lean Enterprise’.
• The EA should also be a guru: ‘Extending Lean-Agile Leadership Skills with Empathetic Leadership’

The page ‘Agile Architecture’ concerns how Architecture is positioned in organisations that are using Agile methods and frameworks. How to design architectures that are agile, adaptable and resilient to change is mostly left to the Architects themselves.

Responsibilities of the Enterprise Architect

An Enterprise Architect works on Portfolio Level across Value Streams

• Collaborate with Lean Portfolio Management
• Communicate enterprise strategies
• Define key technical initiatives and guides strategy for Architectural Runway
• Help synchronize key disciplines across solutions
• Promote modern technical and DevOps practices

Collaborate with Lean Portfolio Management

The Enterprise Architect helps aligning work in LPM, Lean Portfolio Management, with both business and enterprise architecture visions. Note that LPM is a function and not a person or role.

You act as advisor in LPM’s ‘Strategy and Investment Funding’ activities, but not ‘Agile Portfolio Operations’. You will discuss strategic alignment of proposed business initiatives and you should be able to advise on a number of IT related properties like possible effort, risk and compliance. You will collaborate with Enterprise Executives and Business Owners. Please notice that their role description does not list you as a stakeholder, so you should ingratiate yourself with them.

You are a stakeholder in LPM’s ‘Lean Governance’ activities and you should make sure that you attend. If ‘Portfolio Sync’ is held, you need to get invited. Here you will naturally work with Agile PMO/LACE, but also your new friends, the Business Owners.

When you need to influence a specific (business) Epic, you may need to work directly with the Epic Owner. You are, once again, not listed in their role description, so you will need to sign your name on their dance cards.

Fortunately, you should be in good standing with the Architectural Epics (Enablers) since they are owned by either you or your Solution or System Architect colleague.

The Enterprise Architect contributes to the formulation of Strategic Themes. These will influence the Portfolio Canvas. Although you are not mentioned in the page on Portfolio Canvas, you will be able to contribute to it – especially in ‘Envisioning the Future State’.

Portfolio Canvas influences the Portfolio Vision. Although this is very focused on the business, you will need to ensure the descriptions align with the architectural visions. Please note that you’re not mentioned in the description.

Epics flow through the Portfolio Kanban. You’re only mentioned in that description as a stakeholder for analysing Epics, but you are mentioned as active contributor in this SAFe article “Applied Enterprise Workflow with the SAFe Portfolio Kanban: An Experience Report.

Epics for implementation are prioritized by the LPM and placed on the Portfolio Backlog. You provide some of the Enabler Epics, but LPM accepts and rejects all kinds of epics. Enabler Epics also come from Large Solution and Program levels. Budget for Enablers is discussed in several places including Lean Budget Guardrails but not Lean Budgets.

Communicate enterprise strategies

You are responsible for communicating architectural strategies to people in the enterprise/government. You will take part in sharing Strategic Themes, Portfolio Vision & Roadmap.

You may choose to create and maintain your own set of architectural artefacts for communicating principles, strategies etc, but keep in mind that the purpose is to share, get feedback and adjust and not prescribe or control, as discussed in my article on a new EA role. If maintenance of these artefacts requires efforts from others (like Solution and System Architect) you should clear this with LPM to make the effort transparent. Artefacts must provided value to the organisation and you must be open to discussions on this. Some artefacts like overview of the system landscape would probably make sense, but e.g. domain models may be owned and maintained on Large Solution or Program levels.

You should naturally engage with Solution Managers, Product Managers and Product Owners in discussions of architecturally significant aspects of the Epics, Capabilities and Features.

You will also need to engage with STE, RTE and Scrum Masters on improvements of Delivery Pipelines and generally our ways of working.

Communities of Practices may provide great places for communicating and discussion architectural strategy. This could be an excellent way to learn and get feedback from the whole organisation. This is explained very well in the linked page.

Define key technical initiatives and guides strategy for Architectural Runway

The Enterprise Architect is so high up in the organisation, that you have a responsibility to look outside the organisation for changes in the outside world, that may have significance within. This may be new paradigms, new tech, new methods and even threats. You should spread the word of relevant developments from the world beyond the walls of your organisation and you must identify areas and potential technical and architectural initiatives to deal with the changes. This may be even more important in Government than Enterprise. You have to figure this part out yourself.

SAFe is focused on how business needs can be realised with IT solutions to give value for customers. Much of your communication and sharing of architecture in the SAFe framework will be centered on Architectural Epics, which are Enablers of the Architectural Runway. The enabler epics may be a more suitable place to describe specific aspects of transitioning from current to target architecture, than maintaining permanent, comprehensive or detailed AS-IS and TO-BE architecture artefacts on portfolio level.

The Architectural Runway supports implementation of business epics in the roadmap and includes architectures and designs that live up to Nonfunctional Requirements (NFRs) .

You will need to work with Solution and System Architects during decomposition of Epics into Capabilities and Features in order to discuss items like the intent and strategic implications. You may be asked to collaborate on Capabilities and Epics that originate from Large Solution and Program levels. SAFe does not prescribe how and when you interact with Solution and System Architects, so you may create your own architecture forums, meetings etc to collaborate with them. Some things come naturally by attending various events like demos and retrospectives in the cadence together with other stakeholders, but it’s almost more important to focus on being proactive and collaborate during backlog refinements, when architectural decisions are made. There may also be an “Architect Sync” on Large Solution level, which architects, tech leads, key SMEs use to align and share things.

Help synchronize key disciplines across solutions

The EA helps align tech use in general across the enterprise – data, security, infrastructure, UX, NFRs – you name it. You may do this through various Communities of Practices. You also need to connect with people in Shared Services and System Teams across ARTs and Large Solutions.

Promote modern technical and DevOps practices

You’re the expert on engineering practices and the enterprise architecture strategy for technology choice and usage – or you have to find ways to delegate part of this. If you are good at interacting with teams and team members, you may get most of your input from them.

Another aspect is Enterprise Architecture strategy for improving development processes and delivery pipeline. This is something you should talk with everybody about, but STE, RTE, Scrum Masters have a huge stake in this. If you’re stuck, need help or inspiration, then talk to you local SPC.

For more the more technical part of delivery pipeline improvements and initiatives, talk to the System Teams.

Copyright Notice

SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.