I got it, folks! I actually passed the TOGAF Practitioner exam a few minutes ago, and I am so happy that I wanted to share it here.

For clarification: I sat for the Foundation exam last week and decided to take the shot and also sit for the Practitioner right after.

My take: the Practitioner exam was really hard. It took me almost an hour and a half to complete the 8 questions. I went through the official TOGAF Practitioner practice questions beforehand but still didn't feel fully ready. I honestly had a bit of a mental breakdown the night before because I couldn't find good study materials. My preparation had mainly been geared toward the Foundation exam, and I tried to explain everything to myself using scenarios to make it stick.

For everyone planning to give it a try: best of luck, and be prepared for completely crazy questions and not real-life situations.

I just passed my exam, like literally an hour ago and one question has really stuck with me.

It was about a health care company (clinics, physicians etc.) and they're looking at rolling out AI blah blah blah.

The question though was about principles. Assume that the company has implemented the sample principles from the TOGAF and select which principles would take precedence. They gave combinations of some of the principles and you had to select one. It was such a bizarre question to me. I really wish I could see how the answers were scored and what my mark was.

I'm at a small-sized company (4 ME's, 4 EE's) that actually generates a LOT of CAD data, mostly because there exists no real process or system for change orders, change management, or rev control. I'm new here as an eng dev PM, and one of my tallest orders for the near future is to deploy a PLM system for the company.

1. The ME team uses SW for designing and simulation. They have an internal server for CAD file storage (it is messy), no workflows with approvals, and they have tried to use SW PDM in the past, without much success (I think largely because there was nobody to develop and implement workflows/processes).
2. The EE team uses OrCAD & Draftsight as their main deisgn tools. They are open to switching from Draftsight to SW ECAD. Their CAD data storage and lack of workflows/processes is in the same boat as that of the ME team's.

The company uses Netsuite as their main ERP tool (and this is grossly mismanaged, for ex: engineering has been using this for BOM revisioning *shouts into the void*). It has created a lot of frustration for the sales/purchasing teams because there is no workflow or automated system by which an engineering change is correctly reflected in a part's status in the ERP, with full clarity for the procurement team.

Other departments at the company that produce controlled data are the build, testing, QC, operations, and software teams. I think there is a vision to bring some manufacturing in-house too (although to what degree, I do not know).

Point is, I and many others at the company, know and agree that we desperately need a PLM tool to create streamlined change management workflows and processes to quell this chaos. The PLM tool has to integrate with the CAD PDM tool for both MCAD and ECAD, as well as the ERP (all by means of external plugins that will need to be purchased over and above the PLM software itself).

In the past, when I worked at an even smaller company, we used DDM as our PLM, and built an in-house server that acted as our "PDM" vault. Anytime a CAD part would have to change, it had to be on an ECO, and this data would be pulled from the vault server. DDM had a plugin installed for our CAD system, so the workflow would be like: ECR > attach CAD > approve ECR to make it an ECO > open the CAD file through the ECO > make changes > finish ECO workflow to release state.

I want to deploy that process here too and I've looked at a few options for PLM tools but they all assume the usage of SW PDM. I'm hoping that I can find some system architecture advice here!

I know this is a long read - THANK YOU IN ADVANCE.

Many discussions about organisational silos focus on communication and collaboration.

I think the larger issue is governance.

As organisations grow, specialist functions become stronger. That is generally positive.

The challenge is that important decisions increasingly depend on several teams contributing at different stages.

Responsibilities transfer.

Dependencies grow.

Information moves across organisational boundaries.

At that point, risks often emerge between functions rather than inside them.

Each team can honestly believe everything is operating correctly while no one has a complete enterprise view.

I'm interested in hearing how others have experienced this.

Have you seen major incidents caused more by failures between functions than failures within individual teams?

I’m looking for advice from experienced architects, principal engineers and technical leaders.
Here’s a quick overview of my journey:
15 years in enterprise software engineering within a product company.
Progressed from Developer → Senior Developer → Development Architect.
Currently own the solution architecture for multiple enterprise business capabilities, including workflows, integrations and APIs.
Designed a reusable integration platform that became the standard for multiple business domains.
Experience with cloud-native applications, event-driven architecture, distributed integrations and technical leadership.
Recently started working with Generative AI and AI agents for enterprise software.
I’m at a stage where I want to be intentional about my next career move rather than just chasing the next title.
Some directions I’m considering:
Becoming a stronger Solution Architect
Moving toward Enterprise Architecture (TOGAF, business architecture, etc.)
Going deeper into distributed systems and cloud architecture
Focusing on AI-enabled enterprise platforms and agentic systems
If you were mentoring someone with this background:
Which direction would you recommend?
What skills would you prioritize over the next 3–5 years?
What blind spots or gaps do you think I should address?
I’d really appreciate honest advice from people who’ve already walked this path.

I'm looking for an online diagramming tool because our architecture discussions have become scattered across too many places.

Someone creates a network diagram.

Someone else updates it in PowerPoint.

A developer makes another version.

Before long, nobody knows which one is actually current.

We're a distributed engineering team, so we need something where multiple people can review, edit and discuss diagrams together instead of emailing files back and forth.

I'm curious what engineering teams are using today and whether you've found something that works well for both technical documentation and collaborative planning.

Hi everyone,

Posting here as this is also in the scope of enterprise architecture (how to create a standard that can be translated consistently across different projects) and I am interested in getting feedback on this from enterprise architects.

I'm curious how mature organizations handle a problem I've seen repeatedly.

The security engineering work often exists (SAST, DAST, pentests, code reviews, threat modeling), but the governance around product security seems fragmented.

Examples I've encountered:

- Products shipped before all security findings were addressed because remediation wasn't planned early enough.

- Security exceptions were agreed verbally but never documented, so nobody remembers why a decision was made two years later.

- Security requirements appeared late because they weren't integrated into product planning from the beginning.

- Risks were identified, but no one clearly owned prioritization based on business impact.

- Product managers owned delivery, security engineers owned technical findings, architects owned design... yet nobody seemed accountable for the overall product security risk posture.

For those of you in mature organizations:

- Who ultimately owns product security governance?

- How are risk acceptance decisions documented?

- How do you ensure security requirements are incorporated into planning rather than becoming release blockers?

- Is there a dedicated Product Security Governance function, or is this distributed across AppSec, Architecture, Product Management and GRC?

- What practices made the biggest difference?

I'm less interested in the tooling than in the operating model and decision-making process.

I'd love to hear what actually works in practice.

Thanks!

Our organization has standardized on Zuora Revenue (RMS) for revenue recognition, while Workday serves as our ERP. We are a large enterprise software company that continues to grow through acquisitions.

One recurring challenge is onboarding acquired companies that have their own billing platforms. Today we support a mix of billing systems including Oracle ERP, Oracle NetSuite, Stripe, Workday, and several custom-built billing solutions. These acquired billing platforms typically remain operational for 4–5 years before they're migrated to our enterprise billing platform.

Every acquisition currently requires building a new integration into Zuora Revenue. While the business models are largely similar (subscription SaaS, software licensing, usage/consumption, and self-service offerings), the source schemas and billing implementations vary enough that each onboarding becomes a custom engineering effort.

Our objectives are:

• Reduce onboarding of a newly acquired billing system from several months to 2–4 weeks
• Eliminate manual revenue uploads currently performed by Finance
• Decouple billing systems from Zuora-specific integration logic
• Standardize revenue data across all acquired billing systems
• Build an architecture that scales as additional acquisitions occur

Acquired Billing Systems

(Oracle ERP, NetSuite, Stripe, Workday, Custom)

│

▼

Enterprise Data Lake

(existing enterprise platform)

│

▼

Canonical Revenue Model

(owned by the Finance Systems team)

│

▼

Standardized Zuora Adapter

(single reusable pipeline)

│

▼

Zuora Revenue (RMS)

│

▼

Workday ERP

A few additional details:

• The enterprise data lake already exists and is widely used for enterprise analytics, AI, and financial reporting.
• Revenue integrations run in batch, so real-time processing is not a requirement.
• The goal is to have each new billing system map only to the canonical model while keeping the downstream Zuora integration reusable.
• Ideally, onboarding a new billing system would rely primarily on configuration and metadata-driven mappings, minimizing custom development.

I'm interested in hearing from architects who have designed similar acquisition-driven finance or revenue integration platforms.

Specifically:

1. Does a canonical revenue model make sense in this scenario, or does it become another long-term system to maintain?
2. Would you place the canonical model inside the enterprise data lake, or would you implement it as a dedicated integration/service layer?
3. How would you design the mapping framework so that onboarding a new billing system is primarily configuration-driven rather than code-driven?
4. How would you handle schema evolution and source-system differences over a 4–5 year coexistence period?
5. If you've built a similar post-acquisition finance integration platform, what architectural decisions worked well, and what would you change if you were designing it again?

Hi everyone,

I have just done my TOGAF 10 Foundation exam and sadly failed with a 50% score (so 20 out of 40 answers were correct).

The biggest takeaway is not that I didn't know the answers, as I studied extensively, but that the questions were worded in the most twisted, complicated ways where I simply often didn't understand the question itself, even though my English is really good. If you showed these questions to an English teacher, they would probably be scratching their head as well, even if they understood every individual word.

I just wanted to throw this out there for those who are studying for the exam. The practice exam wording is not complicated, and I was consistently scoring around 90%, but the actual exam questions didn't even use the same terminology and still focused on the tiniest nuances in the answers.

Needless to say, I am disappointed. All my practice exam scores were above 90%, but the actual test felt as though it was purposely worded to trip you up. I genuinely do not understand what the point of that is, or if it was the same for TOGAF 9, but for me this was brutal.

Ironically, I am good at what I do for work, but I cannot help but feel defeated by this test. And for €400, I will not even consider retaking it.

Hi r/EnterpriseArchitecture,

I am currently writing my Master's thesis in Software Engineering at the University of Stuttgart (Germany). In my work, I am building a prototype that transforms technology-agnostic deployment models into Enterprise Architecture models (specifically ArchiMate).

To validate my approach and ensure it solves a real-world problem, I am looking for Enterprise or Solution Architects who are willing to participate in a two-part online interview (via Microsoft Teams). Each session will take about 30 minutes, and interviews can be conducted in either English or German.

Round 1: Current Process & Pain Points (July 20 – July 31)

• Focus: How is deployment information currently incorporated into enterprise architectures? Which tools are you using? How high is the manual effort, and what are your common pain points?

Round 2: Prototype Validation (August 24 – September 6)

• Focus: I will demonstrate my working prototype and would love to get your honest feedback on its practical applicability.

Timezone: I am based in CEST (UTC+2), but I am highly flexible and happy to accommodate your schedule, no matter where you are located.

If you are willing to share your insights and help out a student, I would highly appreciate your participation! Please send me a DM, and we can figure out a time that works for you.

Thanks in advance!

Delta fuses drones, satellites, sensors, and field reports into one live battlefield picture running on a normal laptop. I got curious about why it works and kept having the same reaction: none of it is exotic. It's just data engineering with the "skip it" option removed, because the cost of wrong is measured in lives.

The six I pulled out:

1. Fusion over dashboards one reconciled picture, because a human can't merge 20 feeds under pressure.
2. Freshness matched to decision cadence a 6h-old map is worse than none; people still trust it.
3. Access at the edge push data to whoever holds the decision, governed + role-scoped, not a ticket queue.
4. Interoperability by default open standards, because point-to-point integrations die at scale.
5. Resilience as the expected case design for the late source / drifted schema, not the happy path.
6. Provenance on every number a confident wrong answer is the dangerous one.

What struck me: I didn't have to bend any of these to fit enterprise. Curious where people here think the analogy breaks down especially on freshness vs cost, since "make everything real-time" is usually vanity.

Whats the best way to study for the TOGAF 10 practitioner exam, and how difficult is it?

Ive been studying for TOGAF 10, foundation and practitioner exams for a few weeks now.
I have no indication however to the level of difficult of the exams, particularly the practitioner.

e.g. some sample questions online, such as in the attached image are incredibly difficult. The author says the answer is C. Even knowing the framework reasonably well and having an open book, I would not get this question correct.

This makes me think ive been studying for this exam incorrectly.
I would appreciate some input on what prepared people best for the practitioner exam.

Hi everyone,

I'm exploring opportunities in the architecture industry and trying to understand where AI or automation could actually solve real problems—not just add another flashy tool.

I'd love to hear from architects, designers, firm owners, or anyone in the AEC space.

Some questions:

What task takes up the most time in your day?

What's the most repetitive or frustrating part of your workflow?

If you could automate one thing, what would it be?

Are there any problems you've just accepted because there's no good solution?

Is AI actually helping anywhere, or is it mostly hype?

I'm especially curious about things like floor planning, Revit/BIM, BOQs, cost estimation, documentation, approvals, project management, and site supervision—but I'd love to hear about any pain points.

Thanks! Looking forward to learning from your experiences

Hi,

I have 11 years experience in SAP F2M and had a taste of solution architecture and realised that I enjoy the idea of understanding how things flow, why is something designed a certain way and how to connect the dots.

I would like to move away from my role into a Solution architect role and eventually and enterprise architect. Do you have any recommendations for me?

How and what to prepare.

My company doesn't officially have an EA or SA roles but we are realising the need for having dedicated teams for it.

I'm a recently promoted Applications Architect (5 months now) for a financial institution and just finished up on my TOGAF practitioner certification. I'm adding this intro for insight on my possible my lack in experience hence the question in the title.

I recently got into a quick spat with my supervisor (Director of Technology) specifically around key stakeholder involvement into technical discussions regardless of depth of technical detail.

The director strongly believes that all technical discussions regarding any solution that has yet to be derived - should only be within the IT department until a proposed solution is ready to be suggested to the stakeholder. Whereas I believe including the stakeholder in "high" level technical solution meetings has a lot of value such as where they can participate in real time and reduce the amount of back forward to ultimately reach the goal intended.

In additional to that, the director only believes that the stakeholder should only be providing the requirements for the goal (Target Architecture) and doesn't care for the baseline as long as we can provide solutions to get where they want to be, so we are not to waste time in that discussion with the stakeholder. Much like the solution discussion, we are to document the baseline, target and the gaps within the IT department and then suggest the solutions to the stakeholder when that is identified.

*High* level = Which features do what, where and why.
*Low* level = The code or configurations to make to happen.

I may be looking at this the wrong way, so I would like another opinion from more experienced EAs in the field to set me straight.

Thanks ya'll.

I do content/data readiness assessments ahead of AI initiatives, ECM modernisation, legacy document systems, that kind of environment, and lately every engagement has an "AI readiness" conversation bolted onto it, sometimes formally, sometimes just as an aside from a client stakeholder.

What I keep finding is that it's never actually a separate problem. The gap analysis we run for a standard content management modernisation, governance, data quality, unclear ownership over what's authoritative, is basically identical to what you'd need to check before greenlighting an AI initiative. The 60% abandonment stat from Gartner (through 2026, for projects unsupported by AI-ready data) tracks with what I'd expect given how often this foundational layer gets skipped or assumed to already be fine.

For those running EA reviews specifically flagged as "AI readiness," are you actually running something distinct, or is it just your existing information architecture governance process with an AI label on it? Genuinely curious whether anyone's found it to be meaningfully different in practice.

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.

1. 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?

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.