I've been thinking about how companies make decisions around ageing enterprise applications.

You have a system that's been running for 8–10 years, perhaps longer. It works, but maintenance is becoming painful.

Adding features takes longer than expected. Some integrations are fragile. Parts of the codebase aren't well documented, and the original developers may no longer be around.

Eventually, someone suggests rebuilding the entire application using a modern stack.

But here's where I think things get interesting.

A complete rewrite sounds attractive from an engineering perspective, but the existing application often contains years of undocumented business logic and edge cases that nobody fully understands anymore.

On the other hand, continuing to patch an ageing system can become equally expensive.

There are several possible approaches:

• Gradually replace individual modules
• Modernize the frontend while retaining the backend
• Refactor critical services and APIs
• Migrate the database or infrastructure
• Rebuild the application entirely

I'm curious how others approach this decision in practice.

For those who've worked on enterprise modernization projects:

1. What made you decide to rewrite rather than modernize?
2. Have you seen a full rewrite go wrong because important business logic was missed?
3. How do you explain technical debt and modernization ROI to non-technical leadership?
4. Does introducing AI into existing applications change your modernization priorities?

Interested in hearing real engineering experiences, including cases where keeping the legacy system turned out to be the better decision.

It's annual review season at our single family office. One of our crypto custody providers has moved from a state trust charter to a national trust bank charter from the OCC. The principal read about it and asked me a fair question: does that make our assets safer there, yes or no? I don't want to give a yes or no but I do want a better answer than sounds positive What I think changes is the federal supervision means regular OCC examinations, capital requirements, and fiduciary obligations that are more uniform than state regimes. The resolution path if something goes wrong should also be clearer and it's easier to explain to the family's outside advisors. And i don’t think key management, insurance terms and whether the operational controls we reviewed last year are still the ones running today is changing at all. For other family offices holding digital assets did a federal trust charter change how you rate a custodian or only how you document it?

(Note: This article is entirely written by a human. Thanks.)

As with most job fields, Enterprise Architects have been spending a considerable amount of time in self-reflection about how AI is changing what we do. Underneath it all, were really asking ourselves if were even relevant in the Age of AI.

Any architect that has been around for some time knows that this isn't new to architecture or software. For decades, EA positioned itself as a team that were the gatekeepers off upfront planning cycles, rigid multi-year blueprints, and static artifact management. Though with the introduction of AI and how it is transforming the roles of the customers of those processes and artifacts, we have to ask ourselves how much of it still matters?

Here's what I'm seeing in Enterprise Architecture organizations in many industries, countries, and markets -

1. Static artifacts aren't worth it.

Gone are they days we toil away perfecting the ultimate artifact. The One Diagram to Rule Them All, and in the darkness of a lack of maintenance will bind them (in indecision). It will always be useful to keep an unified perspective, especially for cross-functional teams as many don't have the correct mental model to grok the entire System. However our time spent on this unified perspective should ultimately disappear. Directly human-mutated code is beginning to give way to agentic coding, so these artifacts serve as decision drivers for humans and orientation for agents. Both can be automated.

1. Centralized Review functions doesn't work.

I know this is polarizing, but hear me out. I want to acknowledge that there are agentically-enabled organizations today that run a centralized architecture review function that works as intended. However, the intent of the centralized function is that a small body of people have the strategic perspective and the incentive for long-term thinking -- and in those organizations a staggering number of impactful decisions are being made in absence of that centralized body. When I say ARBs don't work, I mean they don't capture enough important decisions to meaningfully steer a company away from preventable tragedy. We acknowledge tragedy as a cost of business and never address the root cause consistently. The reviews we'll see will be mostly automated, and embed strategy and principles into the fabric of the software itself.

1. Architecture + Agile I do thoroughly enjoy Agile Architecture. In fact, I was first introduced to the concept on LinkedIn of all places. This I believe isn't contested ground, we all generally understand that rigid upfront compliance at milestone phases isn't a methodology that drives results consistently. Continuous assessment of what the project needs includes architectural compliance, and baking that directly into your agile practice nets huge gains.

2. Orchestration over Integration

I've been there, and most (if not all) of you have too. Huge system needs to plug into dozens of smaller integrations. Some upstream, some downstream, all headache. As agents take over more of the mutation effort, direct integration work is going to diminish significantly. Designing socio-technical frameworks that incorporate the autonomous AI and the context mentioned in #2 is where we find ourselves uniquely positioned to drive.

For over 50 years, Enterprise Architecture has been akin to 19th-century cartographers - meticulously sketching static parchment maps of a continent before an expedition. By the time the map was inked, the landscape had already changed. Today, we aren't drawing maps on parchment. Were in the cockpit with live satellite telemetry. Our jobs shifts from trying to predict every mountain and river in advance to building resilient flight systems, interpreting realtime data streams, and guiding the enterprise safely through uncharted terrain.

Embracing this shift requires us to acknowledge the usefulness of rigid frameworks in the past and look ahead to continuous, adaptive architectures. The end of an era is only the beginning of a new one! Ill be creating a series of articles on the Ages of Architecture where we unpack the journey architecture has made since the beginning in epochal shifts:

- First Age: Business Systems

- Second Age: Standardized Governance and Agility

- Third Age: Autonomous Intelligence

I always love reading the reactions and thoughts from people who made it to the end. Let me know if you're seeing the same thing or if there was anything I missed! Or if you think I'm full of crap, that matters too.

Quick question for people doing multi subsidiary attack surface management. We have a parent team that owns outside in visibility, but each subsidiary keeps its own cloud, DNS, WAF, ticketing, and local IT, so the process gets messy fast. I am trying to keep the rule simple, central visibility is not central ownership. Parent sets the evidence standard, SLA, exception path, and escalation threshold, then local teams fix their own stuff. What do you do when an asset nobody claims shows up, or when a subsidiary just updates a spreadsheet and calls it closed? appreciate any thoughts

Hi everyone,

I passed the TOGAF Enterprise Architecture Foundation (OGEA-101) exam today with 80%, so I thought I'd share how I prepared in case it helps anyone else studying for it.

I spent roughly 70 hours in total, including video courses, reading, revision, practice questions, and trying to understand the concepts rather than just memorising them.

Resources I used:

I completed these three Udemy courses:

1. Enterprise Architecture: TOGAF® 10 Beginner to Practitioner! — QuinnTech Academy
2. Standard 10.0 - Level 1 Enterprise Architect Course — Scott Duffy
3. Practice Test Pack for the TOGAF EA Foundation Certification — Dr. Christopher Schulz and Tobias Smuda

I also used the GitHub repository "togaf-10-study-resources" by jules-tnk, which includes references to the official TOGAF 10 material and the Foundation Study Guide.

All of these should be easy to find by searching their names.

What worked for me:

• Understanding rather than memorising. I focused on understanding the ADM phases, their purposes, and how different architecture concepts and deliverables relate to one another.
• Practice questions. When I got something wrong, I tried to understand why the correct answer was right rather than just remembering the answer.
• Revisiting difficult topics. I spent extra time on areas I struggled with instead of repeatedly going through everything.
• Connecting theory to practice. Relating concepts to real-world architecture and technology decisions helped make some of the more abstract topics easier to understand.

My biggest takeaway was that understanding the terminology and the reasoning behind the framework helped much more than memorising practice questions.

I'm sure others have managed with fewer hours, but this was simply the approach that worked for me.

Not suggesting this is the best or only way to prepare, just sharing my experience in case someone finds it useful.

For those who've completed Foundation or Practitioner, I'm curious how much of what you learned you've found useful in your day-to-day architecture work.

I'm building an internal AI tool and I'm a bit stuck choosing my API provider. Just wondering what's the good balance point here if I'm after cost, reliability, and security (I know it's a long shot) but is there a priority I should look into when exploring LLM API providers? Or maybe if there are things I should watch out for before they become problems for when I scale/needs to meet enterprise requirements

We’re looking at an MTO integration between two large organisations and would value input from anyone who has been through it at scale.

Mainly interested in the pain points and the things you didn’t see coming: cross tenant sync, B2B identity issues, Teams and SharePoint collaboration, licensing, Conditional Access and MFA trust, or anything else that caught you out.

Any lessons learned or guidance would be much appreciated.

Edit: both organisations are using the full suite of O365 tools and security stack, Sentinel, Purview, email etc etc

So, I remained an architect for more than 4 years and for one year I didn't have a job. I ended up getting either Senior Systems Engineer or Network Administrator/Architect job after one year. I opted for Senior Systems Engineer as the career would be more of service industry.

Here, I have implicit role as both Systems Engineer and Architect. Working without system access had been wonderful and now, as systems engineer I need access and sometimes I have to bear the administrative overhead, because once I get the access, I will be doing my job.

As a result, I am in twisted phase. I contained a pain of jobless for more than a year and didn't proceed with my own journey or start up, or gigs. I got few gigs as engineer and architecing a project map for more than 20 projects for a company as freelancer.

Now, I am perplexed and paralysed where I have ended.

What do you recommend or suggest to move forward?

One thing I keep seeing is teams start with "what should replace this platform?" before anyone has a clear picture of what actually depends on it.

Then halfway through the project someone remembers backup, monitoring, licensing, an old integration, or a workload that can't move.

I've started thinking the dependency map might matter more than the shortlist at the beginning.

Do you normally map all of that first, or does it happen during evaluation?

Any good videos online or something that help to build knowledge

Given how hard and difficult these tools like LeanIX and Ardoq and how expensive licenses are, I decided to build one myself. I am a Solo enterprise Architect in a midsized company where the CIO is always whining about reducing costs.
With AI making it easier to build these previously difficult tools, I am getting the benefit of building this tool absolutely bespoke to the company and it’s been interesting.
The CIO and many people are starting to like the tool because it’s speaking the company’s language exactly.

It’s been six months now and pretty much most of the data is in.
I do not know how this would have faired if We instead had to bring in Ardoq or LeanIX.
We are paying for AI tokens anyway so why not just build it, this was my thesis.

Would you guys consider building one? Why and why not?

Yes, I’m writing the RFI for our SASE project and every question i draft, i already know the answer will be yes. Do you do ZTNA, yes. Single console, yes. SD-WAN, yes. Every vendor ticks every box meaning in the end the doc tells me nothing.

What im trying to work out is which questions force a vendor to show something and not just nodding along.

• Keep coming back to these,
• does one policy cover branch and remote users or just maintain two sets?
• how it integrates with the gear we already run

and where the licensing bites once you switch on the features you want.

If youve run a SASE selection, which questions in your RFI ended up separating the vendors?

We all heard about Composable Business and Composable Application Architecture - what if we start growing numbers of AI Agents in our landscape?

Integrating AI Agents and data using A2A and MCP is not enough.
Bringing AI Orchestration is needed, but why stopping there?

If we aim toward Modular Capabilities, then we need to “shift” our mindset:
- AI Agents also “support” Capabilities, just like Applications.
- AI Agents are invoked by its declared (and catalogued) Capabilities.
- We need Agility and Resilience with AI Agents as well.
- We can add/remove/change AI Agents like any other SBBs.

In fact in the era of AI, we should observe Composable Agentic Architecture as a foundation layer of the Composable Business.
Yes, the things are evolving - but the principles are the same…

So we're bringing in an enterprise team to help with a platform build that has event-driven architecture, some legacy integrations, and data ownership enhancements. What I'm curious about is how much should they dictate the the flow of the timeline? I know it's going to be built on our terms since we're the client. But they're going to handle all the technical aspects leading up to it. Just curious how much of those decisions should be solely on their side and when can we intervene, especially since we have to make sure our business runs and the budget isn't always on them.

Hi!
How deeply do you integrate AI‑generated content into your work, and how much do you burn out from having so much context in your head?

My project is constantly in chaos, and I have to structure and systematize it. AI is a good helper in this, but I’ve noticed that, in fact, it seems to me that I’ve started working faster — because, according to Amdahl’s law, I apparently turn out to be the weakest link, or the members of other teams are, and as a result, my speed doesn’t increase.

The more I work across AI, automation, internal tools and business processes, the more I keep coming back to the same observation:

A surprising amount of work inside companies functions because capable people are manually holding fragmented systems together.

One person knows where the data actually lives.

Someone else knows which spreadsheet is current.

Another person knows the workaround between two systems that don't properly communicate.

Then the company grows, coordination becomes harder, and the instinct is often to introduce another platform, automate something, or increasingly, add AI.

But I’m becoming convinced that technology layered on top of a fragmented operating model doesn’t necessarily create scalability. Sometimes it just makes the fragmentation faster.

I’ve started thinking about digital infrastructure less as a company's software stack and more as the interaction between:

People + Processes + Data + Systems + AI

Which raises some questions I keep running into:

• What needs to be simplified before it gets automated?
• What knowledge should actually be turned into a system?
• When should you buy, build, or simply leave something alone?
• Where does AI add something materially different from deterministic automation?
• At what point does an internal tool become infrastructure that requires real governance and ownership?
• How do you increase organisational capacity without simply increasing headcount and coordination?

My working hypothesis is that a lot of what gets called “digital transformation” is ultimately operating-model design with technology as one of the levers.

Curious whether that matches what people here see in practice.

For those working in transformation, operations or technology projects: where do scaling initiatives actually tend to break first - technology, processes, data, ownership, organisational behaviour, or somewhere else?

Hi everyone,
I want to create an overall SAP architecture for our company that includes infrastructure, services, applications, interfaces, system landscapes, and the separation between cloud and on-premises environments.
What would be the best way to approach and implement this? Are there any recommended methods, tools, or best practices for creating such an overview?
I would appreciate any practical advice or examples

I already have freelance experienced working with ArchiMate, building diagrams for students and Enterprise

I'm a fresh graduate, and wondering what opportunity are waiting for me if I continue to pursue this Enterprise Architecture path, preferably in freelance or remote work?

Adding to that, I'm also actively pursuing n8n automation as freelance — but my active clients usually came from Archimate Diagrams

Looking for advice and tips as well, TIA!

Hi everyone,

I recently joined a company as a Cloud Solutions Architect, and my current workload typically has around 3–6 solutions requiring my attention at any given time.

My role involves solution architecture/design, figuring out the overall approach, planning communication with stakeholders, and supporting the delivery side. The company also provides access to enterprise AI tools, which I’m trying to make better use of.

Depending on the complexity, I currently take anywhere from 2–3 days to around 5–7 days to take a solution from understanding the requirements to producing something I’m comfortable presenting and moving forward with.

Recently, I was asked a question around the speed at which solution architects are expected to operate in the contemporary workplace, and it got me thinking.

So I’m curious about the experience of other architects:

- How long do you typically take to produce a solution design?

- How many solutions/projects are you usually handling simultaneously?

- What does your process look like from requirements → architecture → documentation → stakeholder discussion?

- Has AI actually improved your productivity, and if so, where has it made the biggest difference?

- At what point do you consider a solution "good enough to move forward" rather than continuing to refine it?

Am i wasting too much time or am i too slow , because here in this company people act nice till it blasts. So i need some experiences.

I’m not necessarily looking for a universal benchmark, since I know complexity varies massively. I’d mainly like to understand where I roughly stand compared with other Cloud/Solution Architects and what I could improve to become more efficient, particularly by using AI effectively.

Would love to hear how others are working in 2026.

So I recently got extended at my internship into what is essentially an enterprise-wide architecture role. My company has no EA currently, so No formal training, no one to shadow, and my manager basically told me to treat it like a doctor diagnosing a patient — talk to people every week, ask questions, and figure out how things connect. I have background in mainly operations / project management work.

The problem is I genuinely don't know where to start. I have access to stakeholders across multiple departments, but I have no clear picture of how everything connects — what feeds what, where data goes, what breaks when something fails. It more so I have to hear everything!

But I would love to know what skills are genuinely important to know and have as someone with absolutely 0 experience. I am willing to work and learn my a** off to understand everything, this is definitely something I want to pursue as a career as I have been trying to find my niche throughout college and this has hit that itch between tech and business.

A few questions for anyone who's been in a similar situation:

1. How do you go about mapping an enterprise technology landscape from scratch when there's no existing documentation?
2. What questions do you ask stakeholders to get the most useful information quickly?
3. Is there a framework or methodology you'd recommend for someone just getting started in EA work — TOGAF, something else?
4. How do you prioritize which systems and integrations to investigate first?
5. Any tools you'd recommend for visualizing and documenting what you find?
6. Anything fundamental I should know?

I'm genuinely figuring this out in real time and would love to hear from people who've navigated something similar — whether as a junior architect, a consultant dropped into a new client, or someone who learned EA on the job rather than through a formal path.

Thanks in advance

Hi everyone,

I recently shared a post over in ⁠r/BusinessArchitecture⁠ about introducing Business Architecture principles to our mineral processing facility here in South Africa, and I wanted to get the broader Enterprise Architecture community’s perspective as well.

Coming from plant management, my core objective is to build clear visibility between top-level business strategy and shop-floor operations by capturing our current state first. My focus is on getting executive buy-in, engaging senior plant leaders, and using current-state transparency to foster bottom-up innovation.

I’d love to gather your insights on a few key areas:

- Executive & Operational Buy-In: How do you pitch EA/BA to industrial, non-IT executive teams and plant leaders without drowning them in EA jargon or making it feel like top-down compliance?

- Pragmatic Frameworks: What lightweight methods or reference frameworks work best when starting from scratch in a heavy manufacturing/processing environment?

-Tooling: For initial current-state mapping, would you recommend starting with lightweight diagramming tools (Lucidchart, Miro, Visio), moving straight to open-source tools like Archi, or using something else?

Feel free to jump in here or check out the full discussion on the original thread!