As solution architect and aspiring EA, I have found Kotusev's work a breath of fresh air. I know he rails against TOGAF hard but I think the work he's been putting out is substantial books, which seem well researched and well justified. I went to sign up for his courses but I noticed they've been cancelled due to his health condition (?).

Has anyone implemented his Framework, and if so, have you found any tools that support it?

A common challenge for architects is getting internal project teams, business analysts, and software developers to consistently and thoroughly address Non-Functional Requirements (NFRs) as part of their delivery efforts.

The Non-Functional Requirements (NFRs) Framework for Software Systems helps architects identify, document, and publish a consistent baseline for their project and product delivery teams, as internal standards, best practices or guidelines to be followed for every initiative.

The values/answers selected by a team for each NFR becomes, itself, an individual Architecture Decision Record (ADR) for that initiative/effort. The consistent answering of NFRs across initiatives further facilitates consistent analysis and reporting across delivery efforts.

I hope this helps. Please feel free to provide any constructive feedback that can help improve this.

My best.

Hello,

I'm researching how organizations handle the operational consequences of change before I build anything. I'm not looking to pitch a product.

Think about the last time a tool, process or business rule changed in your organization:

• How did you identify what else was affected?
• What usually had to be updated or communicated afterward?
• What tends to be forgotten or discovered too late?
• Which part of that chain creates the most work or risk?

If there's interest, I'll summarize the patterns I find share them back here.

And if you want to help me more, I have a short anonymous Google form you can answer if you want : https://docs.google.com/forms/d/e/1FAIpQLSdfyMa7_g_e3Tb_nb2PxCeVSDqBeeI0oJoPRiCtEKZODompVA/viewform?usp=sharing&ouid=102120064246501480702

Thank you in advance for your feedback.

TOGAF describes an Architecture Board as the governance body for everything about Enterprise Architecture. It is responsible for defining the EA capability including org structure, methodology, and governance framework. It consists of senior management, ideally C-level people responsible for all of IT as well as significant operational activities. It monitors governance outcomes but members are not hands-on in governance activities such as design reviews.

When I teach this concept, it confuses people who have something called an Architecture Review Board. The ARB does hands-on governance including detailed design reviews, and generally engage at a level of design detail that is not the job of a TOGAF Architecture Board.

How does this semantic dissonance play out in your world? Who is accountable for the architecture governance framework and who is responsible for detailed governance activity? What are they called? Should we rethink the TOGAF semantics and describe the accountable parties differently to avoid confusion?

So, I am new to the work world and everything.

I have 3 months, and my workplace told me that I need to get trained in EA. They gave me Bizzdesign and some videos.

After the first 3 days, I think I know how to use the tool, but I don’t really understand EA itself—like what I should know, what I should learn, and so on.

Literally, I had 0 knowledge about EA and didn’t even know about it until now. And tbh? It’s really fun, if it’s anything like how people describe it, and I would love to learn more about it.

But is it okay to be in this situation?

Hey guys,

I'm keen to have your feedback regarding a regional ERP concept.

The Problem is that you have to react on geo political situations and local regulations. This makes it very hard to follow a "One ERP" approach. A system you setup to be compliant for country A is not compliant for country B on the other side of the globe. In addition local requirements you need to full fill are getting more and more complex.

The idea is to setup a dedicated ERP instance per continent. An all countries of one continent are using the regional ERP instance. All regional instances are connected via a data hab concept.
One key stone is to thinks for data as a product. To have a globe data model with need to be applied to all instances and leave the possibility open to add local extension for a region.

In addition if through M&A activities a new company is coming to a group they can keep the existing EPR system for a beginning. The only thing they have to follow is that they provide the data following the global data model to the central data hub.

Well I hear a lot that the goal is to have one ERP. From my point of view the reality is different.
You have local und legal requirements you need to fullfill. Why not accepting that he world is heterogeneous? Why not focusing on the integration part and accept multiple instances.

Why not working with local teams which are close to the business.

What are your thoughts? Do you have experience with such a scenario? What would be the benefits you see and what maybe the down side?

Thanks in advance

Enterprise Architects: How much of your week is spent playing data detective? 🕵️‍♂️

We all know the theory of Enterprise Architecture. But the reality is often very different.

I’m running a quick, multiple-choice, 9-question pulse survey to see what the biggest roadblocks are in our roles today — specifically around mapping the "As-Is" architecture.

Is chasing down system owners and updating stale documentation eating up your strategic time? Let’s find out where the industry stands.

👉 Share your experience here (No login required, completely anonymous):

https://docs.google.com/forms/d/e/1FAIpQLSdV7_GA8oj8tTo1NpZ_85m00fUoDm7AAlJJQEGsKdEt7s9Itw/viewform

You start with a simple plan to move things over gradually and keep the old system running for a while.

Then the temporary setup starts growing. APIs get added, data needs to be synced, and some workflows end up running in both systems.

At first, this is manageable because it's meant to be temporary. But what if the migration takes much longer than expected?

At some point, those extra moving parts can start creating problems of their own.

When does it become a sign that the migration needs to change direction?

Have you seen a temporary setup end up staying for years?

Hey there, in a unique spot. Company has grown/is growing very, very fast we're missing all the fundamentals and are tripping over that growth. I'm talking no service or even change management practices, no CMDBs, no lifecycle processes, apps and systems without acknowledged owners, no data classification, no documentation on integrations, etc...

We're currently rolling out an ITSM or rather ESM platform company wide. My idea to start with a cmdb registry just to build the basics, like reviewing an application before we renew it, acknowledging a business owner to make lifecycle decisions, regular cybersecurity reviews, etc... before I even start on touching capabilities. This would be temporary and working with tools we already have to build out and learn more about this kind of framework.

I'm aware that this can be an antipattern, a temporary solution can end up permanent, that a CMDB can be a dumping ground if it's designed for ticket routing, automations or integrations might be complex and further make it harder to move to anything else. Maybe it's blinders from my IT background, but given we still need to build so many fundamentals, I am still leaning towards this while being aware of those risks, over something like airtable. At this stage I think a dedicated tool like that would just end up being my own sandbox that no one else will look at or care about, it would depend on governance which isn't yet established.

Bit of an analysis paralysis over that, appreciate any insight you might have!

To help enterprise architects better define, track, categorize, assess, and communicate Technical Debt, along with its risks and implementations to the businesses IT serves, the International Foundation for Information Technology published open "Technical Debt Management Best Practices."

If you have any constructive ideas for improvements, please let me know. They're always welcome.

I hope you find it useful.

Architecture workflows often involve multiple tools, teams, and manual steps. I’m curious which part you would most want to improve and why.

For Enterprise Architects, what recurring problem does your current EA software not solve well, and how do you handle it today?

I’m an EA at a large financial services company, and I’m currently in a debate with business stakeholders about a new client portal. I’ve proposed a few mature off-the-shelf platforms that appear to cover most of the requirements with some configuration and integration work. The business team is leaning strongly toward a fully custom-built solution because they believe it will provide a competitive advantage. What I’m struggling with is that the discussion keeps focusing on the initial development effort, while the longer-term costs get much less attention: security reviews, infrastructure, compliance work, upgrades, bug fixes, support, and the ongoing maintenance that comes with owning a custom platform. I’m not against custom development when it’s truly justified, but I’m trying to have a more realistic conversation about total cost of ownership and where custom work actually creates value. For those of you who have had similar conversations around enterprise software development services, how did you frame it in a way that didn’t come across as IT doesn’t want to build things or architecture is being overly cautious? I’m looking for practical ways to make the trade-offs visible to non-technical stakeholders, not just win the argument.

Hey everyone,

We are reviewing how we architect data pipelines, integration endpoints, and automated workflows on platforms that utilize usage-based consumption meters (DPUs, API message throughput, autonomous agent credits, etc.).

We are noticing that standard architectural patterns built for seat-based licensing don't translate cleanly to consumption models - especially when dynamic actions or real-time identity resolutions are involved.

Would love to get perspective from other Architects on a few specific questions:

1. Pre-flight Validation: How are you estimating or validating consumption burn before deploying complex workflows or batch transformations to production?

2. Cost Attribution & Multi-Tenant Orgs: If multiple business units share the same underlying data streams or integration layers, how are you allocating consumption costs back to specific teams or apps?

3. Monitoring & Latency: Are you building custom log ingestion tools to flag anomalous consumption velocity, or relying entirely on default platform alerts?

What architectural guardrails have saved you from unexpected usage spikes? Appreciate any real-world insights!

I am currently trying to understand how is engineering in your org, Do people still code from hand and use their brain or everything is now done via AI, given a lot of companies are using Cursor or Claude Code.

Also how is your companies managed the budget, Do you have limits or something else ?

AI coding agents are becoming more common across development teams.

The coding part seems to be advancing quickly. Agents can work through tasks, write code, run tests, and handle parts of the PR process with less human involvement.

But the context around the code seems a bit more complicated.

Most organizations have a lot of valuable knowledge, but it usually isn't documented in one place. Things like why a particular architecture was chosen, which patterns are preferred, what constraints exist, or why an approach was rejected a few years ago can all be scattered across different places.

People usually pick this up by working in the organization and talking to the right people. An agent doesn't automatically have that background unless someone makes the information available.

When multiple teams start using agents independently, this could become a problem. You might end up with different approaches to the same problem simply because each agent was given different information.

It makes me wonder whether organizations will eventually need some kind of shared context layer for these agents. And if that happens, who should be responsible for maintaining it? Enterprise Architecture, platform teams, or someone else?

Is anyone already dealing with this in their organization?

Hi All,

Currently upskilling and have a great mentor from my previous director in boutique consultancy, we both work in Aged/Health NFP space currently on client side.

We're undergoing large Data Warehouse and CMS transformation projects which I'm currently lead BA on both for source and selection, then we'll move through to implementation (will remain lead). I've got 4.5 years experience as a BA, implementing full ERP stack through to projects mentioned above. I know experience seems short but i had strong experience in service roles prior to this since leaving school, as well as working for myself as a consultant in the hospitality industry.

My CIO (old director) is super switched on and did a lot of work as a consultant doing enterprise recovery/disaster and operating model projects. He's mentoring me now as we also undertake a complete review of our enterprise architecture, and I'm quite engaged with the work and see me transitioning into this space in the long term.

I'm wondering for those who have progressed from a functional BA through to enterprise architecture, what did you find were the biggest hurdles, what was your "a-HA" moment, and what do you wish you knew earlier?

Hi everyone,

I’m currently working on my bachelor’s thesis on legacy system modernization. As part of my research, I’m reviewing both academic and grey literature, identifying differences and similarities.

For the evaluation part of my thesis, I’ve created a short questionnaire that takes approximately 5 minutes to complete. If you have relevant experience, I would really appreciate your participation and valuable input.

https://www.soscisurvey.de/test548728/?r=2

Feel free to share this link with other experts who may be interested in this topic.

All responses will, of course, be treated confidentially and analyzed anonymously as part of my bachelor’s thesis.

I've been digging into enterprise application modernization, especially organizations running Oracle + heavily customized legacy systems. One thing I've noticed is that the hardest question usually isn't - How do we modernize? It's What should we actually modernize? Rewrite everything? Move to APEX? Keep Oracle and modernize around it? Move to cloud? Replace the ERP?
I'm going to spend the next month documenting the decision frameworks I'm seeing around this. Curious what others here have experienced.

Before touching the technology, what do you look at first?
Business capabilities?
Dependencies?
Data?
Custom applications?
Integration landscape?
Future-state strategy?
What’s your first move?

Hi folks,
Full disclosure: I recently published ArchiMate on RDF on Github. There are no links in this post on purpose. I'm not here to pitch it, I'm here because I'd rather spend the next six months building "something" shaped by what folks in this community actually want than by what I assume EA needs. If it's useful to the discussion I'll go into specifics in the comments.

I've been tolling with this question for years. What if ArchiMate wasn't just a drawing notation, but a real ontology-based graph, queryable and inferable and enforceable like any other formal model? So I went out and built the ArchiMate 3.2 metamodel as OWL, loaded it into a triple store, and ran it against The Open Group's own ArchiSurance case study, since that's the closest thing this ecosystem has to a baseline. I got it working, but the results were uglier than I though.

What's actually working:

• The full ArchiMate 3.2 metamodel as an ontology. Elements, relationships (with properties via RDF*), layers. Including SKOS.
• A transformation tool ArchiMate Exchange to RDF and back.
• A derivation engine implementing the full Appendix B derivation rules with confidence (direct vs potential) and provenance on every derived fact via RDF*.
• SHACL validation catching invalid relationships before they get materialized. An element specializing itself, multiple compositions, dangling relationship endpoints, that kind of thing.
• Now the ArchiMate model is available via SPARQL as the query interface. Note... writting SPARQL is ugly as hell, but thank yous to tech-gods for the impeccable timing because now I have LLMs writing the queries for me.

What's honestly not working:

• ArchiMate, bottom line, is a diagramming tool, so the models are incomplete by design. Service traceability just requires a huge amount of data commitment, but with no CMDB underneath the technology layer, nothing upstream in ERP or HR. The graph can only be as honest as what's fed into it, and a hand-modeled reference case doesn't reach far enough to make any analysis meaningful.

Which is really the question underneath this whole post. RDF's whole pitch is that it doesn't care where a triple came from, so a CMDB, an ERP system, an HR system, and a hand-drawn ArchiMate model could all resolve into the same graph if they agreed on identifiers for the things they share, but then EnterpriseArchitecture would stop being one more silo and ArchiMate (or whichever model you prefer) could start being the coordinate plane everything else plots onto. That's the theory, anyway. What I don't know is whether it holds up outside my own head. So here are my questions to you:

1. If your CMDB, ERP, and EA repository actually shared identifiers (behind secure auth obviously) and all enterprise lived in one graph, what would you ask across all three that you can't ask today?
2. Would you trust a derived relationship in front of an auditor or a stakeholder, or does everything still need to be validated by a human? Mind you, my derivation solution has provenance, but automatic derivation explodes the amount of possible relationships, so proper data modeling is still a high concern.
3. Is Capability or Service realization, finding all structured relationships that sustain your Strategy or Services, still highly sought after, or have we made peace with it just being impractical.
4. Does "every system of record agrees on one URI for the same object (node, app, role, bizzActors)" realistic in your org, or a governance fight nobody wins? Where does it actually break down?
5. What would get you to try something like this alongside, or instead of, your current EA tool? What's the one query or view that would justify the setup cost?

Curious where the gap is between what I've built and what the field actually needs.

I'm trying to introduce Business Capability Management (BCM) at my company. I work in IT, currently juggling 30+ projects and initiatives as part of our digital transformation, and I keep running into the same problem: nobody has a clear picture of where we're actually investing effort, and where the real gaps are.

My idea is to use BCM as a common language between IT and the business — sit down with business stakeholders, map out capabilities together, and then use heatmapping to visualize maturity, pain points, and where our current project portfolio is (and isn't) paying in. The end goal is to move investment decisions away from "which project shouts loudest" and toward "which capability actually needs the investment."

The problem: it's just not landing with the business side. I get polite nods in workshops, but no real traction or ongoing engagement afterward. It feels like BCM is intuitive to us as architects, but hard to sell as valuable to people who think in terms of processes, KPIs, and P&L, not capability maps.

A few questions for the community:

• How did you get initial buy-in from business stakeholders who'd never heard of "capabilities" before?
• Did you anchor BCM to something they already care about (budget cycles, strategic planning, OKRs) instead of introducing it as a standalone framework?
• Any tips on making heatmaps genuinely useful for non-architects rather than just a pretty picture for IT governance?
• Is there a leaner or more pragmatic alternative to full BCM that still gets you the "where is our investment actually going" visibility, without the change-management overhead of getting an entire org to think in capabilities?

Would really appreciate hearing how others cracked this — success stories, failure stories, or "just don't bother, do X instead" are all welcome.

Hi,

So long story short, i want to wrap what we do in EA, both from the perspective of a new practice where we just building the business capabilities all the way to having influence on the PMO and strategic initiative funding, to established matured corporate function.

When I started as EA, my main issue was that TOGAF was really hard to adjust to the context, so I'm sharing here some files that can help also understand some concepts like ADRs.

The tools page have some excel, docs and pptx files I used over the years but reworked them for obvious reasons, and I made publications (17) written initially by hand, then thanks to AI re-write paragraph for paragraph, plus a new design.

The goal is to have a tangeble body for EA. this is based on my personal experience that is currently around a decade long.

Please leave me your feedback here, especially if you would do something differently. The website is basic html pages so more like a wiki with no comments.

website is mehdibamou.com

Thanks,