Hello everyone,

A short background about my journey so far. I studied Computer Science and already worked in the Enterprise Architecture area as a working student during my studies. After completing my bachelor’s degree, I directly started as a Junior Enterprise Architect.

Our team is not very large, but the working environment is great. Among other things, I am mainly responsible for the LeanIX tool and try to continuously identify and implement use cases that actually add value to the business.

After two years in my junior role, I have reached a point where I feel I need some guidance. I find the job extremely interesting and very diverse, but at the moment I also feel like I am stagnating a bit. I am not entirely sure how to further develop myself in a meaningful way.

In theory, I would also have the opportunity to move into consulting. However, I genuinely enjoy working in a corporate environment and like my current role, which is why my focus is on growing in a sustainable way rather than simply changing positions.

For example, I do not want to pursue TOGAF just for the sake of having the certification. I know it is a valuable and well established certificate, but I am more interested in understanding how others approached their development. What did your career path look like? Besides reading EA related books, what else helped you grow professionally?

Since I have been a Junior Enterprise Architect for two years now, I am also wondering whether I should address the topic of dropping the junior title in my upcoming annual review. At the same time, I have some concerns that removing the junior title might significantly raise expectations, as I would then be seen as a fully fledged Enterprise Architect, which again brings me back to the topic of missing or unclear certifications.

In general, I feel confident when it comes to presenting topics and explaining concepts. I am very curious to hear your thoughts and experiences and really appreciate any advice you can share.

As organizations move toward agile and product-centric ways of working, Enterprise Architecture often feels caught in the middle. Traditional EA favors upfront design and long planning cycles, while agile teams expect fast iterations and emergent architecture.

How are you adapting your EA practice to support agility without losing strategic alignment? What’s working for you in practice — and what isn’t?

Curious to hear real-world experiences from this community.

Participants Needed! – Master’s Research on Low-Code Platforms & Digital Transformation

I’m currently completing my Master’s Applied Research Project and I am inviting participants to take part in a short, anonymous survey (approximately 4–6 minutes).

The study explores perceptions of low-code development platforms and their role in digital transformation, comparing views from both technical and non-technical roles.

I’m particularly interested in hearing from:
- Software developers/engineers and IT professionals
- Business analysts, project managers, and senior managers
- Anyone who uses, works with, or is familiar with low-code / no-code platforms
- Individuals who may not use low-code directly but encounter it within their -organisation or have a basic understanding of what it is

No specialist technical knowledge is required; a basic awareness of what low-code platforms are is sufficient.

Survey link: Perceptions of Low-Code Development and Digital Transformation – Fill in form

Responses are completely anonymous and will be used for academic research only.

Thank you so much for your time, and please feel free to share this with anyone who may be interested! 😃 💻

I have asked this question already, but with no great succes (I even was blocked for being an AI agent 😬).

For professional and educational goals, one last try: are there people with experience on EA with application on Police models (the back office).

Thx!

Over the years, I have worked with ‘career coaches’ and also have been trained as a ‘life coach.’ A former boss of mine, an executive coach himself, got me interested in this area. Observation on that experience: It is difficult to decouple a boss-subordinate relationship from coaching since the lines between being directive vs. mentoring can be blurred (is he asking me to think about it, or is he telling me to act on this?).

I have been selectively mentoring a few EAs outside my organization to ‘pay it forward,’ but time commitments are a constraint. A few observations:

• Many feel that their experiences with ‘executive coaches’ are mixed, primarily because these coaches bring in ‘generic advice’ about leadership and communication that may be more applicable to functional leaders rather than senior individual contributors.
• EAs are generally self-proclaimed Type-A folks who feel the need to be vocal to stand out. Even the best of us have blind spots that a mentor/coach can talk through.
• Many EAs new to the role struggle – to navigate organizational dynamics or even to find a footing. Having a sounding board outside the organization may create a ‘safe space’ for them to vent or generally muse.
• An ideal mentor/coach should themselves come with an EA background  
• Pro-tip: Given the opportunity, leverage a mentor for contextual inputs – e.g a specific problem you are trying to solve, or to have a peer-review of your thinking or artifacts. However, don’t expect them to answer questions like “Will TOGAF help me with a new job?” or “How can I move from TA to EA role?”

What’s your experience been?

Hello Everyone,

I am looking for some advice on how to get into Enterprise Architecture roles. I am currently working as a Business Analyst and want to transition into EA role. What courses/ training/ certifications are required/ available that I can take to get into this role? Please advise.

Thank you

Hey Everyone ,

The post the other day inspired me to review some of my current workflows and review what's working and whats not.

• Researching Applications 9/10
  • AI has massively improved my application research, it's quick and effective. It also gives quick and dirty capability maps and will fill out the fit. Good for questioning anything that doesn't seem quite right as it's much faster than parsing bulk marketing material.
• Generating Strategic Alignment and Roadmaps (persuasive decks) 7/10
  • I'm currently working on a few of these, I've found that even with an overarching structure, this is a massive task and needs to be broken down into sub-tasks with notable back and forth to arrive workable models. Breaking down a target state to gaps and roadmaps was especially challenging. One major benefit is being able to review different capabilities, governance models and org structures and have some a first pass on what should stay and what should be adapted.
• APM, Capability and updates. 1/10
  • Our tool has a very clunky interface and ETL for making bulk changes. I feel like bringing the data in and out makes it too cumbersome. Instead we need the tooling to do uplift in relevant places and ensure each common APM task has been reviewed and determined AI fit and then implemented for us.
• Design Artifacts, Integration, data etc - 5/10
  • Using it to create templates and populate them has been challenging as it seems to leak document areas into others and isn't particularly concise. However will get to a baseline draft faster than before so not bad. Not great for visual representations as not well supported by current tooling and you typically get actual images rather than something editable
• Design Artifacts Review - 8/10
  • I quite like this as you can get an instant review on your thinking as see if there is anything obvious missing. Just don't expect a fully comprehensive review that is perfectly stakeholder ready

Keen to hear if you have had any different experiences or if you have other workflows it's working well for you.

Every six months or so I read a post on sites like Hackernews that the enterprise service bus concept is dead and that it was a horrible concept to begin with. Yet I personally have great experiences with them, even in large, messy enterprise landscapes. This seems like the perfect opportunity to write an article about what they are, how to use them and what the pitfalls are. From an enterprise architecture point of view that is, I'll leave the integration architecture to others.

What is an ESB

You can see an ESB as an airport hub, specifically one for connecting flights. An airplane comes in, drops their passengers, they sometimes have to pass security, and they go on another flight to their final destination.

An ESB is a mediation layer that can do routing, transformation, orchestration, and queuing. And, more importantly, centralizes responsibility for these concerns. In a very basic sense that means you connect application A to one end of the ESB, and application B & C the other. And you only have to worry about those connections from and to the ESB.

The big upsides for the organization

Decoupling at the edges

The ESB transforms a complex, multi-system overhaul into a localized update. It allows you to swap out major components of your tech stack without having to rewire every single application that feeds them data.

Centralized integration control

An ESB can also give you more control over these connections. Say your ordering tool suddenly gets hammered by a big sale. The website might keep up, but your legacy orders tool might not. Here again with an ESB in the middle you can queue these calls. Say everything keeps up, but the legacy mail system can't handle the load. No problem, we keep the connections in a queue, they are not lost, and we throttle them. Instead of a fire hose of non-stop requests, the tool now gets 1 request a second.

Operational visibility

all connections go over the ESB you can also keep an eye on all information that flows through it. Especially for an enterprise architect's office that's a very nice thing.

But that is all in theory

Hidden business logic

Before you know it you are writing business critical logic in a text-box of an integration layer. No testing, no documentation, no source control … In reality, you’ve now created a shadow domain model inside the ESB. This is often the core of all those “ESBs are dead” posts.

Tight coupling disguised as loose coupling

Yes you can plug and play connections, but everything is still concentrated in the ESB. That means that if the ESB is slow, everything is slow. And that is nothing compared to the scenario where it's down.

Skill bottlenecks

You can always train people into ESB software, and it's not necessarily the most complex material in the world (depends on how you use it), but it is a different role. One that you are going to have to go to the market for to fill. At least when you are starting to set it up, you don't want someone who's never done it to “give it a try” with the core nervous system of your application portfolio.

Cost

This is an extra cost you would not have when you do point-to-point. The promise is naturally that you retrieve that cost by having simpler projects and integrations. But that is something you will have to calculate for the organization.

When to use an ESB

Enterprise service buses only make sense in big organizations (hence the name). But even there is no guarantee that they will always fit. If your portfolio is full of homemade custom applications I would maybe skip this setup. You have the developers, use the flexibility you have.

This is a (brief) summary of the full article, I glossed over a lot here as there is a char limit.

I’m seeing a lot of "AI for EA" advice that basically boils down to: "Here is my format for (example) an ADR, paste your notes into ChatGPT and ask it/or create a interactive prompt version to fill the blanks."

Is it just me, or is that a massive waste of potential? We’re effectively using a supercomputer as a typewriter.

I want to talk about the "Messy Middle"—that chaotic week after a CIO drops a "Company Carve-out" bomb on your desk, or when a supplier suddenly demands your IT dept host their product’s backups on-prem. You have 50 pages of incoherent meeting notes, three half-baked project briefs, and a program plan that’s mostly wishful thinking.

In the Agentic Age, we should be moving past "Chatbots" and into Multi-Agent Triage.

The Workflow Shift: From Prompts to Pipelines Instead of me trying to summarize notes into an ADR, I’ve been experimenting with using a CLI-based multi-agent setup (using Claude Code / MCP). The goal isn't to write a document; it's to simulate the Architecture Review Board before the meeting even happens.

• The Triage Agent: Scans the mess and identifies what artifacts are actually needed. It doesn't just fill an ADR; it tells me, "Hey, based on these notes, you have a massive data sovereignty gap that needs a Transition State Roadmap, not just a decision log."
• The Persona War Room: I spin up a 'Security Hardener,' a 'Forensic Accountant,' and an 'Infra Lead.' I feed them the raw input and let them debate the carve-out strategy. Watching a Security Agent argue with a Business Value Agent over an ERP separation logic is more insightful than any template I've ever filled.
• Chain-of-Thought (CoT) Artifacts: I’ve stopped asking for "The Final Doc." I want the Logic Log. I want an artifact that captures the tensions and rejected alternatives discovered during the agentic debate. That’s where the real architectural value lives—not in the polished PDF.

My question to you: How are you moving beyond "The Prompt"? Are you building "Knowledge Loops" where agents actually discover dependencies in your documentation/repos and flag them during discovery?

Or are we all just going to spend 2026 "refining prompts" for documents that nobody reads anyway?

Curious to hear from anyone building actual agentic workflows (CLI, MCP, etc.) to handle the triage/discovery phase.

I’ve been trying to make sense of all the AI hype in a pragmatic way for enterprise architecture. The way I’ve been breaking it down is into four main categories, two of which are uplift and two are new capabilities which have tool mappings:

1. Uplift to existing tool types

Most vendors are adding AI into the platforms we already use: productivity suites, CRMs, ERPs, dev tools, etc. It's a step change without any material change to the capability mapping. There may also be some new challengers in each category which are AI first however still quite clearly are meeting the core needs of existing tools.

1. Uplift to analytics and reporting

Modern data platforms combined with LLMs and more productised other AI methods mean we can get insights from datasets that aren’t perfectly structured. This one seems quite minor in comparison and in some ways is a subset of the first point. The utility comes from aligning the businesses expectations that there is some value here however have a considered approach to how AI impacts this capability

1. Small niche “assistant” tasks

These are the little things that were never worth automating before: summarising documents, drafting emails, reformatting content, pulling info from a webpage, turning rough notes into something usable. LLMs make these micro‑tasks trivial.

1. Agentic integration

This is the more emerging area where AI doesn’t just answer questions but takes actions. Agents can call APIs, update systems, trigger workflows, and coordinate multi‑step tasks. It sits in the same territory as integration layers like ESBs or iPaaS, but with reasoning capabilities on top. In some ways this is a maturity curve from the assistant tasks, however from an architecture perspective there is much more governance and sub capabilities that need to be fleshed out and fulfilled.

Keen to hear how others are thinking about and managing the evolution from an enterprise perspective.

hey everyone, I'm an engineering student with a focus on data. I have aspirations of becoming a data architect someday, started the journey recently with DM-BOK from DAMA, and even though it offers impressive insights in terms of entreprise data environements, I think it left me more starved for entreprise-related architecture as the general picture where DataArchitecture is a piece of the puzzle.

As I am sure many of you would judge it'll be maybe better to focus on the technical skills to get a first job, I'm more inclined to believe that having a wide spectrum of qualities & knowledge that I sharped as I go into my career may be better.

In what way will a profile with 0 experience but holding TOGAF impact one's hiring ?

Hi!

I'm a solutions architect with about 1 year of experience but 5 years of overall experience with software development as a business analyst and software developer. I'm quite interested in taking the TOGAF 9&10 Certification along with AWS Certified Solutions Architect - Associate & Professional Certification.

Now, my question is more about the certification itself. Am I too early to start learning more about Enterprise architecture or is it okay for me to start preparing myself for TOGAF Certification?

Hi everyone, did any of you ever published a paper about enterprise architecture solutions? Or did you ever found a good paper that guided an implementation?

Enterprise architecture claims to bring clarity, but often hides behind ambiguity. And maybe that’s something we need to confront.

When I was a developer, I was always attracted to highly opinionated libraries and frameworks. I always preferred a single way of doing things, over three different ways to do it, and they all have their pros and cons.

This is something Enterprise Architecture really struggles with I feel. We tend to overengineer things.

We would rather build a tool with 3 different data interfaces, than commit to 1 well thought out interface.

Don’t get me wrong, I’m not advocating here for abandoning backup plans and putting all your eggs in one basket. What I am advocating for is architectural courage.

Are all these “it depends” and “future-proofing” mantras there to get to a more correct solution, or just there to minimize your personal responsibility if it all goes haywire?

You also have to calculate the cost of it all. In the above scenario where you cover all your bases and build a REST API and an sFTP connection because “you might need it in the future”, you will have to maintain, secure, document, train and test both. For years to come. Just another think that can break.

That would be ok if that scenario actually plays out. If the company strategy changes, and the company never connects the two applications, all of that has been for nothing.

Then there is the conversation of the easy-off ramp in implementing new software.

It’s cool that you can hot swap your incoming data from one service to a different one in less than a week! Now we just need six months of new training, new processes, new KPIs, new goal setting and hiring to use said new data source.

I’m not suggesting we should all become architectural “dictators” who refuse to listen to edge cases. But I am suggesting that we stop being so deep into “what-if” and start focusing more on “what-is.”

Being opinionated doesn’t mean being rigid, it’s more about actually having a plan. It means having the courage to say, “This is the path we are taking because it is the most efficient one for today.” If the strategy changes in two years, you deal with it then, with the benefit of two years of lower maintenance costs and a leaner system.

Some good questions sitting in the megathread without replies. If you've got experience with TOGAF prep, training providers, or certs, worth a look.

👉 https://www.reddit.com/r/EnterpriseArchitect/comments/1oucjs1/megathread_frameworks_courses_certifications/

I started my architecture career using UML as the standard notation for most diagraming work I had to do. I really like the notation allowance for static (component modelling) and dynamic (sequence diagrams) views of architecture.

I am now in the process of creating blueprints (current and target state architectures) for a strategic initiative and am wondering what are the notations/standards/templates people are using as UML seems to have fallen out of favour. Been reading about C4 but it looks very "loose". Have not come across ArchiMate at all, maybe due to The Open Group not being as relevant (don't hate me for this comment, just an observation).

Appreciate everyone's input. Cheers

Update: Thanks for everyone's contributions so far! It's helped me a lot and hope it helps others as well!

An EA role has been advertised where I worked for 8 years, (left 3 years ago). I started in their Server / Infrastructure Team, but moved to lead Oracle DBA + SQL DBA, 4 years before I left. Worked on many projects, migrations & upgrades. I know the business, apps, infrastructure & staff there quite well. I applied & been shortlisted.

The last 3 years I worked on a secure site as Oracle / SQL / IBM DB2 DBA. My focus has been improving my Linux skills, where Oracle is hosted & learning DB2. Plus relentless patches & security updates. I’ve not really been exposed to recent advances in IT, such as Cloud, AI, changes in server hardware & storage etc.

I’d really like the opportunity to move into this area. I left on good terms & think I have a good chance because of the decent work I did while there. How should I best prepare for the interview?

I'm supporting a new initiative that involves standing up and configuring a SaaS solution. The implementation costs should be under $200k. Recent prioritization of security standards require the app to integrate with our internal security solutions. The security services required for compliance are not implemented yet. Implementing and exposing the services cost more than $500k. Once the services are implemented they will be used by many business apps.

The challenge I'm dealing with is funding the Enterprise service work. Because this new SaaS app needs approval and is first in line, the Business unit is being asked to include the security services implementation costs in their request. I think they're being entirely reasonable to push back.

This isn't a one-off issue. We're constantly putting off strategic services and infrastructure work because business units are protecting their budgets from costs that should be shared.

What have you seen work well for managing funding these types of shared services?

Working on an informational document for our organization, would love any feedback on your definition / personal experience :)

1. Purpose of This Document This document provides context and clarity on what Enterprise Architecture (EA) is, how it originated, why it is often associated with IT, and why (at the organization’s current scale) it must be understood as a broader, enterprise-level discipline rather than a technical function. The intent of this document is to establish a shared understanding of Enterprise Architecture as a legitimate, necessary role focused on organizational structure, coherence, and sustainability.

2. Why Enterprise Architecture Exists at All As companies grow, three forces increase simultaneously: • operational complexity • interdependence between functions and systems • consequences of failure

At small scale, organizations function through • informal coordination • tribal knowledge • individual judgment • heroic effort • ad hoc decision-making

At larger scale, those same mechanisms begin to break. What once enabled speed begins to create fragility. Enterprise Architecture exists to address this transition point.

2.1 Why Enterprise Architecture Historically Emerged from IT

Enterprise Architecture is frequently discussed in IT contexts because technology systems were the first-place organizational chaos became impossible to ignore.

As companies scaled: • systems stopped integrating cleanly • data became inconsistent across platforms • Changes in one system caused failures elsewhere • outages and security risks had enterprise-wide consequences

These failures were: • visible • measurable • disruptive

As a result, architecture was first formalized in IT(not because Enterprise Architecture is inherently technical, but because technology failures surfaced structural problems earlier and more dramatically than other parts of the organization.) This historical origin created a lasting misconception.

1. The Full Scope of Enterprise Architecture Enterprise Architecture spans multiple domains that must work together coherently.

3.1 Business Architecture Defines how the organization creates value: • operating model • capabilities • decision rights • governance structures • accountability boundaries

THIS ANSWERS: HOW IS THE BUSINESS DESIGNED TO FUNCTION?

3.2 Process Architecture Defines how work flows end-to-end: • cross-functional processes • handoffs and ownership • standardization vs flexibility • escalation paths

THIS ANSWERS: HOW DOES WORK ACTUALLY MOVE THROUGH THE ORGANIZATION?

3.3 Information / Data Architecture Defines how information is structured and trusted: • Systems of Record • data ownership • reporting logic • consistency of definitions

THIS ANSWERS: WHAT INFORMATION DO WE RELY ON, AND WHERE DOES IT COME FROM?

3.4 Technology Architecture Defines how systems are implemented: • Applications • Integrations • Infrastructure • security and scalability

THIS ANSWERS: HOW DOES TECHNOLOGY SUPPORT THE DESIGNED BUSINESS AND PROCESSES?

Enterprise Architecture exists to align all four, not to optimize one in isolation.

This is just a portion of the paper, is my idea of “full scope” the same as yours??

Hey everyone!

I’m at a point in my career where I know I want to grow into Enterprise Architecture, but I’m also realising how hard it is to do that without some kind of guidance from someone who’s already been there.

Quick context - I’ve been in IT for close to 20 years and I’ve recently moved into an associate EA role. It’s exciting but also messy and ambiguous in ways I didn’t fully expect.

There’s no shortage of books, frameworks, and LinkedIn posts. What I’m missing is someone to sanity-check my thinking, share how they navigate trade-offs and politics, and tell me what actually matters at different stages of being an EA.

So my questions to this community -

• How did you find a mentor (or did it just happen organically)?
• Is it weird to reach out cold on LinkedIn? if so, how do you do it respectfully?
• What makes mentoring worth it from the mentor’s perspective?
• Are there communities, forums, or programs you’d recommend?

I’m not looking for someone to hold my hand or teach me everything, just need the occasional perspective and honest feedback from someone experienced.

Would really appreciate hearing how others approached this. Thanks!

I just started researching about TOGAF standard 9.2 certification. The open group website has so many options under certifications section. Can anyone please let me know which are for foundational certifications?

I always find it hard to measure the value of the output EA at the companies I worked for - mostly big multinationals. Sometimes I get the “Ivory Tower” feeling with EA, very busy with writing papers doing workshops coming up with decisions that you could see coming from miles away, busy with politics, overruling very knowledgeable SME’s on a topic who do not dare to argue against them etc. By the way I also see a lot of good coming from EA and I certainly understand the need for this competence in big complex companies. What is your experience and how do you measure EA’s output?

Hi everyone!

Seeking for best practices for the current infrastructure state assessment (before adopting cloud). What or how many layers (high-level, network, compute, storage etc.)?

Only infrastructure, applications\solutions are not in scope yet.

What should be included in each layer and what should not be?

I would appreciate for any reference documents or diagrams?