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
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
You act as
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.
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
Epics flow through the Portfolio Kanban. You’re only mentioned in that description as a stakeholder for analysing Epics, but you are mentioned as
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
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
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
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
For more the more technical part of delivery pipeline improvements and initiatives, talk to the System Teams.
SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.