r/EnterpriseArchitect

I have two recent encounters/cases where I see that enterprise architecture as a discipline is either non-existent or not properly established. Let me lay out the context and issues and hopefully we can make some progress.

1. Senior care corporation

The client is a senior care corporation operating more than 50 facilities, with medical staffing, logistics, operations, and all the complexity that comes with that business. The company grew from a handful of facilities to a multi-country operation. IT support grew organically and was never really planned. Management traditionally treated IT as "the guys who fix jammed printers."

Now that they have billing, accounting, payroll, training, HR systems, intranet, customer support, internal support systems, digital channels for patients and staff, integrated diagnostics, and healthcare management systems, managing and planning the application landscape is proving to be a serious challenge.

As an architecture consulting company, we proposed performing an analysis to capture the current systems landscape, map business capabilities and actual requirements, and create a gap analysis and roadmap to identify what systems are overpaid for, what capabilities are missing, and where investments should be made. Management largely perceives this approach as unnecessary overhead or lacks confidence that it would deliver tangible value.

What is particularly striking is that there is effectively no architecture governance in place. Decisions are made tactically, locally, and reactively. The organization has reached a level of complexity where organic growth and tribal knowledge are no longer sufficient, yet there is little recognition that architecture itself is a business capability that needs to be established and managed.

2. Global merchant acquirer

An established global merchant acquirer (card acceptance terminals, e-commerce, payment gateways, etc.) is undertaking several core systems migrations and replacements. Since these systems support core business capabilities, the impact and blast radius are enormous.

The interesting contrast here is that enterprise architecture teams do exist at the global corporate level. However, they largely function as governance document authors rather than active participants in delivery and transformation. They define standards, principles, and target states, but have little involvement in the trenches where critical architectural decisions are actually being made.

Problem-solving is handled by various layers of mid and senior management, multiple vendors, and delivery teams, but there is no effective architecture function coordinating target state, transition architectures, capability ownership, integration strategy, dependency management, or enterprise-wide risk assessment.

What strikes me in both cases is that the organizations are already paying the price of not having effective enterprise architecture, yet they still perceive investing in architecture as an additional cost rather than a mechanism to reduce risk, complexity, operational cost, and time-to-market.

I've been in so many of these situations throughout my career that I'm honestly baffled by how often I find myself participating in the exact same conversations. Different companies, different industries, different people—but somehow the conversations are almost identical, sometimes literally word for word.

My observation is that there is also a structural incentive problem:

- C-level management often does not fully comprehend the long-term implications of architectural decisions, technical debt accumulation, organizational complexity, and transformation risk.

- Mid-management is typically incentivized to deliver short-term outcomes and quick wins. Whether today's decisions create significant operational, financial, or technical problems five years from now is often somebody else's problem.

- Enterprise architects, when they exist, frequently end up either too far removed from execution to influence outcomes or too focused on governance artifacts to drive meaningful change.

It sometimes makes me wonder whether enterprise architecture has a value problem, or whether it simply has a marketing and communication problem.

At this point, I'm honestly more astounded, perplexed, and exhausted than curious. I've participated in these conversations so many times over the years that I'm genuinely baffled by how we keep ending up in exactly the same place, having exactly the same discussions, sometimes almost word for word.

I hear there is progress in enterprise architecture, but I just don't see it.

I'm a dev in a big high-tech company. We have lots of teams, lots of processes and therefore lots of software. We try to control this with polaron and leanix. But it's just performative. These tools don't really do anything? And besides being laughable bad, I think they also cost money?

What's the point of someone who has never worked in software and never worked on the processes we use to write down "requirements"? They end up on our Devs table, we try to decipher what that's supposed to even mean. Eventually we usually just end up talking to the people who'll use our software. And almost always these requirements are wrong and we just code what they tell us. And after working completely outside of the entire re cycle, they pad themselves on the back. It seems like a giant scam to employ unemployable people as "requirements engineers".

Same for leanix. It's some weird website that has a few redundant and wrong Infos about our programs. So then what? What's the goal? Colleagues talk about wanting to get an overview of our software landscape and prevent double development. But we Devs know that full well. We develop these redundant programs with full intention: because that's what gets you promoted. I can tell you *exactly" what programs shouldn't exist, and all other Dev teams can as well.

This might sound frustrated but I'm really struggling to see the point of all this. Feels like a few boomers discovered computers and made up fancy words and titles to make themselves seem valuable to the dinosaurs in the lead. All the struggling Devs pivot to rEqUiReMeNt EnGiNeeRiNg. None of this will ever impact a single line of code.

Recently, I had the chance to speak at length with the CIO of a large enterprise (obviously can't share the identity), around their thoughts on semantic layers, ontologies and agentic systems. They are fairly active in the CIO circles and have been engaging with their peers on the topic. Notes below are a mix from both our observations.

Some obvious observations first:

1. Large enterprises are disproportionately focussed on building internal agents (rather than customer-facing ones), with the focus on reducing talent costs and they are already realizing that the infra for it is far from ready
2. Enterprises are understanding the pain and the need for context management but they don't have the right terminology for it yet
3. Most enterprises are pointing agents at fragmented internal systems and hoping the model infers business meaning across them which obviously breaks quickly in production.

A few interesting aspects that emerged:

1. Static ontologies are dead on arrival. The real world environment changes daily but the semantic model updates once a quarter and hence the system is stale before it ships. Even human organizations get redesigned every few years because reality moves. An intelligent system should be able to reorganize its internal understanding far more often than that. The better analogy is cognition, not schema design: continuous consolidation, continuous re-linking, continuous updating of what matters.

2. The bottleneck is not data access, it is context selection. The real question is rarely "how do I retrieve more information." It is what context is right for this decision, what should be ignored and how fast that can be assembled at the speed the task demands. A person making a judgment call is not querying a giant flat database. They are drawing on a compressed, evolving, relevance-weighted internal model and that is much closer to the actual design problem.

3. Enterprise semantics gets misread in two opposite directions. Some people flatten it to metadata and catalog descriptions. Others make it so abstract it cannot be operationalized. The real need sits in between: technical enough to run in production, dynamic enough to evolve with the business and grounded enough to encode institutional meaning without collapsing under latency, security and ownership constraints.

4. Vendor semantics is not organizational semantics. Every major platform is now shipping its own semantic layer, but a company's core institutional knowledge cannot be fully outsourced to whichever vendor has the best UI this quarter. Meaning scattered across product surfaces owned by different vendors gets you local optimizations but never a coherent institutional model. This might be one of the more unresolved problems in enterprise AI right now.

5. The hard part is representing judgment, not just knowledge. Most valuable work inside a company is not a deterministic logic tree. People get hired for how they interpret incomplete information and make calls under ambiguity, not just for what they know. So the real question is not how to build a company knowledge base. It is how to build systems that inherit evolving decision context, not just stored facts.

One more thing, the same need gets called an ontology, a knowledge graph, a semantic layer, a context graph, a company brain, agent memory or institutional memory, sometimes all in one conversation. That pattern usually means the need is ahead of the label.

My rough takeaway: we may be underrating how much "intelligence at work" depends on continuously evolving context, not model quality or data availability alone. The next real layer probably is not another copilot or orchestration framework. It is whatever can unify fragmented meaning, keep it current, and make it queryable at decision speed without collapsing under latency, trust, or governance constraints.

Genuinely curious how people here see it: are semantic layers and context graphs the actual missing layer for enterprise agents or is this still too early, too abstract, or too category-confused to matter yet?

Former DBA/Cloud Architect stuck in ECM after reorg. How do I leverage my PM and cloud background to pivot back to EA?

All,

I’m looking for some career pivot advice. Earlier in my career, I worked as a DBA and Architect with solid multi-cloud exposure (AWS, Azure, OCI). I have also spent time as a dedicated Project Manager leading a high-profile "blackbook" project, giving me strong delivery and stakeholder experience.

I’ve been constantly upskilling to transition into a proper Enterprise Architecture (EA) role. Unfortunately, following a massive internal restructuring post M & A, I got sidelined into Enterprise Content Management (ECM). Because of this reorg, the chances of moving into my org's established EA team are now practically getting to nil as the existing EA who mentored were also moved to delivering modernization/Blackbook Projects, and I lack the visibility to fix it internally.

I need to exit ECM and look externally or if someone went through this tide can share their expirience. How can I best market my blend of data/cloud architecture, PM delivery experience, and EA upskilling to land an external EA role? Any recommendations on how to position this on a resume to escape the ECM trap?

Employees belonging to legal, and Finance are not technically advanced and are prone to share sensitive and client related data AI models.

Employees are given access to ChatGPT and Claude but they are sharing sensitive information, emails and files to AI for quick help. We don't have any audit and usage patterns for the employees. How to track the usage of AI models from such employees.

So here’s my situation. I'm a Staff architect at a big tech company, pure IC track. Right now I design large-scale systems, wrestle with performance and reliability, and still get my hands dirty with code and design reviews. Honestly, I still enjoy the technical side of things. Not burned out at all.

Now there's an internal opening to become Head of an engineering department. Full people-manager role. Basically I'd be leading a decent-sized team, owning delivery roadmaps, dealing with budgets/capacity, and spending most of my time coordinating with product, ops, procurement, and external vendors. Almost zero hands-on work.

The pay bump is fine but nothing crazy. It's the same company, so I know the culture and the politics pretty well.

My dilemma is the classic one, do I jump to management to keep climbing (since IC ladders usually top out eventually), or do I stay in the architect lane where my actual interests are, even if that means I might plateau salary/title-wise down the road?

Has anyone here made this exact jump, from a senior IC/architect to a department head? What do you wish someone had told you before you took it? How did you actually make the final call?

Appreciate any honest takes.

Here's my situation. I need a central app inventory, capability mapping, something to draw solution architectures that doesn't look like it's from 2005, and basic threat/control tracking so security stops asking me for spreadsheets every quarter.

We don't have the budget for a leanix or similar, and honestly we don't have the appetite for a 6 month procurement process that ends up creating more tool admin work than it solves.

But everything else I find online is either abandoned open source or some web app that looks nice in the demo and falls apart the moment you need to produce a real artifact for a SteerCo meeting.

Is anyone actually using something smaller that holds up in practice? I am genuinely curious what's out there that my team is not finding. Saw some pitches in this sub from a while ago but most of them seem quite abandoned. Also happy about any open source suggestions

I'm looking for recommendations for an Enterprise Architecture or Business Architecture mentor/coach.

I'm an experienced Business Analyst moving towards architecture roles and would value practical guidance from someone with real-world architecture leadership experience.

Ideally, I'm looking for someone based in Europe or the UK. If anyone here offers mentoring or coaching themselves, I'd be interested to hear about your experience, approach, and areas of expertise.

Has anyone worked with a mentor or programme they would recommend?

For those who are either founders or have worked in founding roles:

I want to ask why so many refrain from selling to larger orgs, often mid-market or enterprise. I don't mean vague plans of going after bigger clients in the future; I mean setting a concrete roadmap and actually going after it.

The benefits of enterprise AI adoption from the vendor side seem obvious: higher-ticket contracts, more brand recognition, fewer clients to manage than SMBs. But I see most founders either avoid selling there or withdraw completely.

What's the hardest part of going to market in the mid-market & enterprise space? Is it just the inability to handle complexity at scale, or something else?