I have been working in IT product management and technology for two decades, across areas including security, government, networking, software development, and machine learning.
I have built up my technology knowledge through practical projects and hands-on experience. But for a long time, I felt that I was missing a formal foundation in IT and architecture.
To connect the different pieces of knowledge and experience I have built up over the years, I recently started an Enterprise Architecture certificate course at the University of Toronto School of Continuing Studies. I am also preparing for well-recognized certifications such as AWS Solutions Architect and TOGAF.
I want to reinforce the formal concepts and frameworks from UofT SCS by applying them to something practical: one of my own projects, SignalLeading.
I will share how I apply these theories and frameworks to real projects here and on amice.dev.
The Zachman Framework
One of the first frameworks I encountered in my Enterprise Architecture lectures was the Zachman Framework.
At first glance, it looks quite simple: six rows and six columns.
But the idea behind it is quite interesting. The same system can look very different depending on who is looking at it. A business executive may see a business problem and its expected value. A business manager may see a process. An architect may see logical systems and relationships. An engineer may see technologies, APIs, databases, and code.
They are all looking at the same system, but from different perspectives.
So I thought it would be useful to take something I have already built, SignalLeading, and see how it looks through the different Zachman perspectives.
Row 1: The Executive / Planner Perspective (Contextual Scope)
The EA Focus:
What is the overarching business problem, boundaries, and financial goals? Executive leadership doesn't care about APIs; they care about revenue and efficiency.
SignalLeading Reality: Solving the “Volume Trap.”
Sales teams need to research companies, identify relevant signals, qualify leads, and prepare outreach. But as the number of potential clients increases, doing all of this manually becomes increasingly difficult.
The idea behind SignalLeading is to use AI and automation to handle parts of this research and preparation process, so that human salespeople can spend more time on the conversations that actually require human judgment.
At this level, I don't need to talk about n8n, APIs, or Next.js. I am simply defining the business problem and the capability that SignalLeading is intended to provide.
Row 2: The Business Manager / Owner Perspective (Conceptual Model)
The EA Focus:
What are the logical workflows and business processes needed to solve the Row 1 problem? This layer must be clear enough for non-technical managers to understand.
SignalLeading Reality: The Sales Process.
At this level, I mapped the sales process into several stages:
Product & ICP Profiler → Client Signals Gatherer → Lead Qualification → Outreach Prep
I used an n8n visual workflow to represent this process. I documented the overall workflow in my earlier article, The n8n Workflow Behind SignalLeading.
A business manager can look at this flow and understand the basic business logic. First, understand the product and ideal customer. Then, gather relevant signals about a potential client. Then, qualify the lead. Finally, prepare the information needed for outreach.
The focus here is not on the code behind each step. It is about how the business process works.
Row 3: The System Designer Perspective (Logical Model)
The EA Focus:
How do we translate those business steps into system rules, constraints, and data relations?
SignalLeading Reality: Designing for Reliable AI Outputs.
One of the problems I explored in my earlier article, Why I Never Just Ask AI to "Write an Outreach Email" in One Shot, was AI hallucination.
My initial instinct could have been very simple: give the AI all the information and ask it to write the outreach message. But this approach can create problems. The AI may make assumptions, combine unrelated information, or generate something that sounds convincing but is not properly supported by the source data.
The important architectural idea here is not a particular prompt. It is the separation of responsibilities and the control of information flow. This is how I started thinking about the AI workflow as a system design problem rather than simply a prompt-writing problem.
So instead of treating the AI as one large black box, I broke the process into small, independent stages. Each stage has a clear responsibility and makes its decision based on the evidence provided by the previous stage, rather than jumping directly to the final answer.
Row 4: The Builder / Architect Perspective (Physical Technology Model)
The EA Focus:
What specific software engines, cloud structures, and programming paradigms are chosen to implement the Row 3 constraints?
SignalLeading Reality: Choosing Technology for Business Growth.
SignalLeading started with n8n because it was a practical and relatively low-cost way to experiment with the workflow. I could connect services, test different AI steps, inspect the data flowing between them, and change the process quickly.
I documented this early experimentation in Starter Guide — n8n + Docker.
As the project becomes more complicated, however, technology choices need to consider more than whether something can technically do the job. I also need to think about the expected volume, operating cost, scalability, and how easily the system can evolve as the business grows.
The goal is not to predict everything from day one. It is to choose an architecture that makes sense for the business today while keeping reasonable options open for tomorrow. A good migration strategy can also allow the system to evolve gradually rather than requiring a complete redesign and reimplementation.
This is where I see the connection between technology architecture and business strategy. The question is not simply, “Which technology should I use?” It is, “Which technology choice makes sense for the business now, while keeping the system ready to grow?
Row 5: The Sub-Contractor / Implementer Perspective (Detailed Components)
The EA Focus:
The hyper-specific, out-of-context components: database schemas, raw code parameters, and precise configuration strings.
SignalLeading Reality: The Code and Configuration.
At this point, the business executive has already understood the value of the system and why money should be spent on it. The EA has translated that business need into a logical and physical architecture. Now the implementation team needs to make it work.
This is where we get into the details that developers work with every day, for example:
- JavaScript API routes
- Database schemas
- JSON payload mappings
- System prompt variables
- Authentication configuration
- Backend logic
- Database indexes
- Docker configuration
The detailed implementation of the four major SignalLeading components is also documented in my previous articles:
Solution 1 — Product & ICP Profiler
Solution 2 — Client Signals Gatherer
Solution 3 — Lead Qualification Engine
Solution 4 — Outreach Door Open Prep
These details are important because they make the system actually work. But they are not the whole architecture.
As a developer, it is easy to spend most of my attention here because this is where I write and debug code. The Zachman Framework reminds me that implementation is only one perspective of a much larger system.
Row 6: The Functioning Enterprise Perspective (The Working System)
The EA Focus:
The operational, living system delivering actual commercial value in the real world.
SignalLeading Reality: SignalLeading.com itself.
At this level, we are looking at the system as it actually operates. SignalLeading receives inputs, processes information, runs its AI and automation layers, produces outputs, and ultimately supports a business activity.
But from an EA perspective, a working system is not simply one that is technically running. We also need to know whether it is delivering the expected business value while keeping performance, reliability, and operating costs under control.
This is where monitoring and operational management become important. For example, cloud platforms such as AWS provide monitoring and cost-management capabilities that allow us to track system performance, resource usage, and spending. These operational signals can then be connected back to the business objectives we defined at the beginning.
This brings the business executive back into the picture. They may not care about database indexes or API configurations, but they care whether the system is delivering the expected value and whether the cost of running it makes business sense.
Why This Mapping Practice Is Useful
Before studying Enterprise Architecture, I would probably have looked at SignalLeading mainly as a software project: the code, workflow, APIs, AI models, and infrastructure.
The Zachman Framework gives me another way to look at the same project. It makes me step back and connect the business problem, business process, system design, technology choices, implementation, and the working system.
This is probably what I was missing before. I have accumulated many pieces of technology knowledge over the years. Now I am trying to understand how those pieces fit together at an enterprise level.
Rather than learning Enterprise Architecture only from diagrams and textbooks, I want to keep testing the theories against things I have actually built. SignalLeading gives me a useful laboratory for doing that.
This is only my first lecture and my first attempt at applying an EA framework to a real project. I expect my understanding will continue to evolve as I continue the course.
#EnterpriseArchitecture #ZachmanFramework #SolutionArchitecture #TechnologyArchitecture #BusinessArchitecture #Architecture #SignalLeading #AWS #AIArchitecture
