Demystifying Enterprise Architecture: how-to write a great EA charter?

I write about the art of designing and transforming digital business. Enterprise Architecture is my key tool. If you like please subscribe to my substack newsletter on Enterprise Architecture.

So what is enterprise architecture and why should it make your stakeholders happy? Often I see there is a lot of misunderstanding about what Enterprise Architecture is and what it is not. What are the responsibilities, what is the scope and which deliverables can I expect when from the EA team? Of course the sometimes-confusing jargon we use as architects isn’t very helpful. Try to explain, enterprise- , solution- , domain- , business-, data-, technology-, target-, project-, baseline-, reference-architecture and so on. It might be crystal clear for you but many stakeholders are very confused by this. Confusion about scope, value, roles and expected deliverables could even be the reason why EA initiatives fail. Creating an EA charter can help to demystify Enterprise Architecture and avoid this pitfall. The EA charter is an essential tool to communicate clearly about what to expect (and not expect) from the EA team. It clarifies the scope, mandate, deliverables and stakeholders of the EA team. It helps to develop a shared understanding of Enterprise Architecture.

Who sponsors EA?

Before we start writing it should be clear who is the sponsor of the EA team. Who wants it and who should be very happy with EA? Of course this depends on your current maturity. If your EA initiative still is highly IT driven, maybe the CIO is who you should chat with? If you are better positioned within the business other stakeholders might pop-up. Maybe there is more than one sponsor? Well at least look for your best (executive) sponsor(s) and make sure you have an iterative process to create the EA charter with them, the EA team and other relevant stakeholders.

Short, shorter, shortest

I know we all love to write about our beautiful architecture work and please do. But since the EA charter is also meant for our stakeholders please keep it as short as possible. Use pyramid principle technique for structured writing and start with the most important message(s) first. Think from the perspective of the reader not the writer. So what would your stakeholder really want to know about the EA initiative? My guess would be why is it valuable to me? Of course use the words needed to properly describe EA, but don’t overdo it.

What to write in the EA charter?

So start with the most important message first. What is the value of EA for your most important stakeholders? From there elaborate on more in-depth topics like the objectives, scope, roles, responsibilities, team structure, definitions, mandate, deliverables, surrounding processes and architecture governance. Some of these are the core of the charter, others might be better of in the appendix. Keep in mind to first communicate the most important stuff! Information that is valuable but not necessary for the core message should not be in the charter but in the appendix.

So for the EA charter I would start with a preface and shortly after that dive into the really fun stuff!

Preface

• Why this charter?: what is the objective of the charter?
• For who is this charter?: intended audience of the charter.
• Sponsorship: who is the sponsor of the EA initiative and who approves the charter?
• Maintenance: how and how often will the charter be updated and how does this process look?
• Version control: version and history of the charter.

Alright so much for the obligatory part of the charter. Now let’s get into what is really important, value, objectives and how we track the success of EA!

Value, objectives and tracking

• Value: what is the value of EA for the organization?
• Objectives: what are the objectives of the EA initiative what is it expected to achieve?
• Tracking: how are the objectives tracked and measured? In other words how is the success of EA measured?

So now we know why EA makes us happy (value) what we want to achieve (objectives) and how we measure success (tracking). But who are the people doing all of this stuff, what are they creating for who? That’s next up in the charter.

Roles, team structure and deliverables

• Roles: which roles do we have within the (core) EA Team. Explain the difference between enterprise, domain, solution architecture and so on. Also define the roles outside the EA team that are important for example an executive architecture committee or the members of the architectureboard.
• Team structure: explain how the EA (core) team is structured. Which domains are covered by the architects.
• Deliverables: explain which deliverables the EA team creates for who. Also give insights in the cadence of these deliverables and when stakeholders can expect them.
• RACI: a RACI matrix might come in handy in here. It defines who is responsible, accountable, consulted or informed by the EA team. This matrix could be used to plot the deliverables and roles responsible for it in one overview.

Alright now we have more insight in the team structure, which deliverables to expect and who is responsible for them. But who is going to use these deliverables? The next chapter gives more insight in the surrounding processes interacting with EA.

Surrounding processes

Processes interacting with EA: define how processes like project portfolio management, strategy management, project- and program management, IT change management, service delivery management, information management and so on are interacting with EA. What deliverables flow between processes and when?

So now we have a lot of information. But there is still one last topic to cover. How is the architecture governance performed, who is reviewing and approving the architecture? So that’s the last and final chapter of the EA charter.

Architecture governance

Scope: what is in scope of the architecture governance and what is not?

Mandate: who is mandated to make decisions about the architecture?

Architecture review and approval: what does the process to review and approve architecture look like?

Let me know your thoughts

Actually I am in the process of writing a new EA charter myself. What I wrote in this article is where my thinking is so far. One of the reasons I write these articles is to learn in public and realtime. So please feel free to let me know your thoughts! So what do you think about writing an Enterprise Architecture Charter?

I hope this was usefull to you. Please subscribe if you like! When I am further in the process I might share my EA Charter template with you.

Until next time!

Tim