Alberto D. Mendoza

A 180 in my Personal EA Journey

As a Systems Analyst managing a large and complex technical portfolio, I was determined to document the entire technology landscape across every business unit I supported. I didn’t call it architecture back then — I just knew we needed reliable, up-to-date information to operate, maintain, and evolve the systems under my care.

That’s when I discovered ArchiMate — and with it, a completely new way of thinking.

I learned to think in layers: Business, Application, and Technology — each representing a distinct concern, yet deeply interconnected. I learned to distinguish between services and components, and how critical that distinction is for designing modular, reusable systems and communicating them effectively.

I picked up Mastering ArchiMate by Gerben Wierda, leaned heavily on the open-source Archi tool (still do), and learned countless patterns from people like Eero Hosiaisluoma and Steven Mileham.

Then I dove into strategy and capabilities — how to connect high-level motivations (goals, principles, requirements) to concrete actions. I learned to articulate current and future states, and how to structure transformation using the Implementation & Migration layer. Just as crucially, I began to see systems in their Enterprise context, thanks to the CAUDIT HigherEd Reference Models and the Educause ITANA community.

I modeled everything in ArchiMate. I built an architecture repository using a relational database and kept my model synchronized and up to date. It worked — but when I needed deeper insights like impact analysis, root cause identification, or cross-domain views, I was stuck writing massive SQL joins. The RDBMS-based EA tool was too rigid, and frankly, not user-friendly.

That’s when I stumbled on Neo4j, via one of Archi’s plugins. I went down the graph rabbit hole: conferences, books, graph algorithms. I built my own repository with Structr, modeled ArchiMate as a labeled property graph, and used shortest-path algorithms for impact assessments. But I still needed schema enforcement, versioning, and deeper semantic rigor — and I still needed a CMDB to track change over time.

Then I found the Semantic Web. I read academic papers, explored OWL ontologies, semantic reasoning, and alignment with upper ontologies like BFO and UFO. I modeled ArchiMate in SKOS, got proficient in Protégé and GraphDB, and realized: this is how we can build a truly flexible and intelligent EA repository.

And then… I discovered Svyatoslav Kotusev.

His work shifted everything.

His book cut through the noise. It made something very clear: most EA work isn’t about modeling or tools at all. It’s about strategic communication. It’s about alignment, decision-making, and organizational clarity. In his framework, EA tools are mostly helpful for landscape diagrams. In reality, Word, Visio, and PowerPoint are often just as effective — because they support the conversations that actually move the organization forward.

What I’ve Learned

Tools should support your practice — not define it.
Enterprise Architecture isn’t about diagrams — it’s about decisions.
It’s about people, priorities, and purpose.

I spent so much time searching for the best quarter-inch drill, I forgot to ask why I needed to drill the hole in the first place.

I’m still learning.