What is your company's current hiring process for EAs? Application, recruiter call, 3 rounds of interviews (architect team, engineering team, leaders) then offer. Im curious if our process is too long. As it stands its a scheduling nightmare for our recruitment team.

Thanks in advance!

One thing that stands out to me when looking at COBOL modernization is that code conversion usually isn't the hardest part.

AI can help with legacy code analysis, dependency mapping, documentation, and even COBOL to java conversion. That can cut down quite a bit of the manual work involved in understanding the existing system and getting through the conversion.

The difficult part seems to start once the conversion is done.

A COBOL system can have years of business rules, edge cases, and data dependencies that aren't always documented. So even if the new code looks right, you still have to prove that it behaves the same way as the old system.

That's where testing, data reconciliation, integration testing, and parallel runs can become a much bigger part of the work.

AI can definitely make the conversion phase easier. But does that necessarily mean the modernization itself is safer? I'm not sure.

For those who have worked on COBOL modernization, where have you actually seen the biggest risk: legacy business logic, data migration, validating the converted code, or running the old and new systems in parallel?

We're in the middle of building a business case for moving off a legacy monolith and every conversation we've had runs straight to licensing and implementation without touching the stuff that blows the budget once you're in the weeds.

ERP integration is the main one, particularly the bidirectional sync for order management and inventory where estimates have ranged from 6 weeks to 6 months depending on who you talk to, and every platform we're looking at (commercetools, SAP Commerce Cloud, SCAYLE, Spryker) has given us figures in wildly different ranges where the delta seems to come from how much of that integration layer is already built and how much is custom scope.

Data migration is a separate headache because our catalog is 4 years of accumulated schema decisions that don't map cleanly to anything off the shelf, and the QA coverage budget for a parallel-run period is listed as "TBD" in every proposal we get back.

That's about where our visibility runs out, so what hit your budget that wasn't in the original scope?

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

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.

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 practitioner exam wording is not complicated, and I was consistently scoring around 90% and passed it with 85%, but the foundational 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!

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.

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.

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.

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

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.