Issue #64 – Don’t Let Solutions Architecture Disappear
Sure, building products and apps may be easier now with AI, but don’t forget the principles of a good solution!
Read time: 16 minutes
I love Solutions Architecture.
Honestly, I think it is one of the most underrated and misunderstood roles in the data world.
It often went unhired for; companies figured they wanted engineers, analysts, and scientists instead. But more mature organizations realized they needed something that sat between those roles.
And now, as we hand our data teams over to the AI overlords of OpenAI or Anthropic, there’s an assumption floating around that you don’t really need a solutions architect anymore.
I mean, as long as you have a product manager or a good engineer who can scope out requirements, MCPs and plug-ins, you can take care of the architectural headaches that come with setting up a data or AI solution. AKA plug the agent in, point it at the warehouse, and your business users are good to go.
Nope. I’d actually argue the opposite: With increasingly complex architecture, faster speeds, and a more interconnected world of data, business, and AI, having people who understand how everything fits together is even more important, especially for long-term, scalable solutions!
Agents and AI have seemingly removed the friction, which sounds great (and offers a lot of benefits), until you realize you also removed the foundational knowledge/ expertise and the safety net. As smart as they are, AI agents can’t replace those components, and that will have negative implications. And while companies are hiring AI engineers like crazy, it is really not the same skillset as a Solutions Architect.
So I’m excited to finally dig into the world of Solutions Architecture. And how you build for and with AI Agents!
What a Solutions Architect Actually Does
Let’s start with a definition of a Solutions Architect.
The best way to define this role is by the gap it fills: A solutions architect sits between a business need and a technical build. They essentially design and build software programs to match a business process, usually customizing existing software solutions and linking them to required data sources to match the process.
The role blends design with strong project-management and communication skills. And since it involves translating technical detail into plain language and building scalability/ adaptability into any solution, it also requires technical skills. Therefore, most architects have hands-on experience in development or systems.
Now, this is where things get confusing in today’s world. With Agentic AI, product managers are now expected to build, and AI engineers are supposed to understand the business processes, making the Solutions Architect definition a bit conflated. But in reality, this kind of person is the perfect mix of defining the product/ solution and making it technically feasible. Things they have to think of are:
How do the business process and specs translate into technical requirements?
Which source systems actually hold the required data?
What transformation must occur for those sources to agree with each other?
Where does the logic get modelled, and how?
How should the answer reach the person who asked?
This is a very underrated question, and one that engineers are horrible at solving for because their specialty is backend development
How do you maintain the solution and what does it cost to run (both backend and frontend)?
A solutions architect bridges the gaps that impede proper productionization of data & AI products
If you’ve ever worked with a data analyst, scientist or engineer, they usually don’t think about all these things. Or they start thinking about these things after they start building.
A Solutions Architect (like the architect noun in the name) builds a scalable blueprint against what is required; and gets agreement to that across teams. Then figures out the plan to maintain it, and is often responsible for that maintenance as well.
And, to be clear, a solutions architect is not the same as an enterprise architect. Whereas enterprise architects are responsible for the entire system/ platform of tools in the organization, solutions architecture is supposed to be more contained; ideally one coherent solution to one business problem.
So to wrap up the definition of Solutions Architects section, I will end with why I love the role so much:
The domain starts with the architecture, not the tool.
I’ve walked into too many engagements where there was no clear blueprint about what the solution should be. Instead, companies decided to buy a tool and reverse-engineer the architecture afterwards, cornering themselves into a spot that ends up being more expensive and delivers worse ROI in the long run.
If you are building, you need an architect to design the solution.
If you are find this article helpful, please share with your team and/ or data friends. Sharing is caring and is a free way to support my work! Also shout out to Estuary who partnered with me on this article, helping keep the Data Ecosystem free for readers! Check them out, as they have been a fabulous company to work with and I really believe in their product.
Properly Architecting Solutions is Hard
The other reason I love this domain is that it is challenging.
It takes problem-solving, constant communication, project management, understanding stakeholders, and mapping all of that to architectural and technical design. This kind of data technology strategic thinking or data architecture expertise is hard to come by, and when you find somebody who can do this type of thing, they are worth their weight in gold.
In addition to the questions I shared above, these are the typical problems a solutions architect faces and has to ensure is embedded in the design:
KPI Alignment – The biggest problem with existing solutions is mismatched definitions or KPIs. The Solution Architect’s goal is to secure agreement on these points from business stakeholders and ensure they are reflected across the systems that feed into the solution. This is a mix of stakeholder management, KPI mapping and data modelling. Oh, and this will become even more important with AI agents.
System Connectivity – Most solutions pull data from a handful of source systems that were never designed to communicate with one another. The architect works out how they connect, how often each one refreshes, and what breaks downstream when one of them changes upstream. It’s a mix of integration design and actually understanding the source systems. This is where MCPs and connectors are starting to make a huge difference (more on that later).
Solution Security – Think tooling access management and usage guardrails: setting authentication, permissions, and limits for the solution and connected systems. This will become even more important now that agents can act and not just read; so deciding what a given identity (not just a human) is permitted to do. With direct access between systems and the internet, there is significant potential for increased vulnerability, especially if individuals are running AI agents from the terminal with limited governance.
Data Privacy/ Security – How do you approach protecting the data flowing through your solution: encryption, masking sensitive fields (e.g., PII), and controlling data access? Data and AI regulations are forcing companies to think about this one a lot more and while the Solutions Architect is not accountable for this, it is something they have to consider in design.
Scale – This is where planning for the POC differs from planning for production. For example, data analysts and scientists are great at spinning up a one-team demo. Where the Solution Architect comes in is designing for where usage is heading (e.g., data volumes, concurrent users, and now AI agents). This also has to be adapted and customized for the unique platform/ system within the organization, which isn’t something many people understand.
Latency – Speed is important, but knowing what speed/ latency you need is actually more important for solution functionality, cost, and maintenance requirements. This also now needs to be scoped out with agents in the loop. Similar to scale, this is a problem that requires knowledge of both the underlying systems and the front-end solution.
Reliability – Designing for what happens when a source fails or the data doesn’t ingest properly. Engineers are great at reliability, but this is usually contained to backend components, whereas a solutions architect should ensure reliability throughout the end-to-end process. Again, agentic AI makes this more important as you have less human validation.
Maintainability – Finally, the bane of any data team’s existence—maintaining tools. Solutions outlast the people who build them, but usually with the quality by which it was built. So a big part of an architect’s job is to design something without a single point of failure. And ideally, something that isn’t a pain to maintain (I swear I didn’t mean to rhyme there, but it’s too good).
The skill running through all of these bits is ensuring solutions integration and builds are done right. Unless you have a superstar engineer or data scientist, you will likely need somebody to oversee these things.
Now I want you to keep these things in mind as we transition to the next section—how the new AI reality with Agents and MCP changes things, but also doesn’t.
How Does This Discipline Evolve with Agents and MCP
The companies, teams, and tools that continue to consider all the bits I mentioned above will excel in this new agentic world.
…And the ones that skip it will hit a wall when it comes to productionizing data and AI solutions.
The problem right now is that many companies are skipping these first principles and assuming that, by connecting agents to data and tools via MCPs, everything is good (without taking the time to figure out where things can go wrong). What I’m talking about here is a mindset shift that anyone can adopt without thinking about how the solution needs to be properly architected.
Honestly, I get where that mentality comes from, because the tooling has shifted.
If you don’t know what it is, MCP is the Model Context Protocol, which gives a model a standard interface into a source or a tool, instead of someone hand-building a bespoke integration for every single pairing. By now everybody is using it (one reason Anthropic is leading in the AI space), and Anthropic has since donated it to the Linux Foundation under a new Agentic AI Foundation, with the official SDKs pulling something like 97 million downloads a month. This practice is now as standardized as APIs, and should be a part of any solution build.
And for the solution architect, the part of their job that was “the person who builds and maintains the integrations” has been made much easier.
But this isn’t the whole job, and the mentality that it (combined with AI Agents and their associated skills) is good enough is going to cost your teams in the long run.
So while the connector allows you to plug things in, it doesn’t do anything about whether the data behind what you are plugging in is modelled properly, means what it should, or matches the right definitions. Connectors don’t solve fragmentation; they expose it.
And don’t forget a ton of these systems and tools were already poorly organized, people didn’t use them properly, or they were customized by individuals. Without understanding all the components I mentioned in the previous section, just hooking up the MCP and calling it a day skips a number of steps (and future issues) that requirements gathering and architecture would usually account for.
Moreover, with agentic AI, the working relationship between tools is now happening at machine speed based on what is provided. And if we aren’t paying attention when we hook it up, things may not go well. Previously, a person was forced to look at every connection, and they would often catch problems along the way. An agent won’t, and a poorly set up infrastructure will miss a lot of things that will impact production-ready or already operational solutions.
The encouraging part is that the tooling is starting to build that discipline back in, instead of pretending you don’t need it. Think back to what MCP actually does: it gives an agent a standard way to reach a system. What it doesn’t do is tell the agent what it should do once it’s connected. This is where Agent Skills are relevant. As I explained in the last article, a skill is a set of plain-markdown instructions that hand an agent a defined, repeatable workflow (e.g., sets inputs, outputs, and expected behaviour) for a specific task, like standing up a database replication pipeline. So the agent runs a bounded job you’ve scoped, instead of getting broad tool access and hoping it picks the right path.
A well-articulated and documented Skill can help fulfil crucial components of solution architecture, written down in a form an agent can execute. With that being said, the business and ideally an architect still has to decide what the workflow should be, which systems it’s allowed to touch, and what “done right” means (and other things like permissions or where things live in your architecture). But what a Skill does is take that architecture and give it a repeatable shape the agent can follow instead of improvising.
An example of this I’m seeing across a lot of companies right now is business people trying to reach the data platform and pull analytics directly with AI. Unfortunately, most companies don’t have the engineering capacity to build the pipelines necessary to port in well-modelled data in a way that is trustworthy for non-technical stakeholders.
Estuary, who partnered with me on this article, built their Agent Skills to close this type of gap. The skill plugs into whatever harness/ tool you are already using (e.g., Claude Code, Cursor, Codex, etc.) and combines Estuary’s best-practice approach to building pipelines with the unique characteristics of your data environment. So instead of building from scratch, or from an AI tool that doesn’t understand how your data is modelled, this type of skill leverages the work you’ve put in to model and organize your data (aka the architecture), and helps you construct the pipelines to transfer it within your tools/ solutions in a best-practice way. For stakeholders who now do everything from an AI harness, bringing best practice to you will make a huge difference between generic tooling and high-quality outputs.
In practice, it comes down to asking your agent for a Postgres-to-Snowflake pipeline, and the skill discovers your schema, drafts the capture, generates the materialization, and hands back a working configuration for you to review. Basically, change data capture reads changes from Postgres and materializes them into Snowflake tables, with no one hand-building the connection. You can even use this type of skill and connection to further inspect your collections and suggest how the data should be shaped along the way.
I didn’t start my data career as an engineer or architect, so for me, these kinds of skills that help you harness some of the repeatable technical capabilities make a huge difference. You still own the design and modelling, but this kind of solution frees up engineering time during data deployment. Honestly, in smaller/ mid-sized companies, this is huge, and I’ve already recommended Estuary to a few of them (unprovoked).
Of course, that is a shortcut; you still need the discipline mentioned above. But the art of combining advances in technology (agents, skills, MCP integrations) with the right solutions architecture skills will enable a lot more companies to do proper analytics/ BI with a much lighter headcount.
So remember these two things:
Agents and MCPs help with the integration problem and the engineering
Companies still need to think about the whole system: what should be connected, how context reaches the agent, and who stays accountable for what comes out the other end (honestly, this is why we are seeing an onslaught of FDE roles coming from vendors and consulting firms).
And if you skip the Solutions Architecture step, you may fail. I mean, Gartner is already predicting that over 40% of agentic AI projects will be cancelled by the end of 2027 due to escalating costs, unclear business value, and inadequate risk controls. And I believe a large share of those cancellations will trace back to exactly what we’re talking about: solutions that nobody architected.
Which brings me to the word I’d use to describe the evolved version of this whole job: boundaries.
The Importance of Boundaries
Agentic AI has brought about a new design problem. In the past, every tool and system the architect designed was deterministic in nature. This means it was hard-coded, would require the same type of input and provide the same type of output.
AI agents don’t work like that. They use an LLM to interpret, predict, and choose what to do next. What that means is it won’t behave identically twice. The architecture is now not only about the connections, but also where the lines are drawn between deterministic vs. agentic.
The way I think about it, the boundaries show up in four places:
Requirements Gathering – This process used to involve interviewing humans to figure out what they needed and how they may work with the new solution. Therefore, the questions focused on “what should the solution do?” But now, we need to think about “what should the solution never do?” because it will likely be interacting with agentic capabilities. So requirements have to capture the decision rights: what the agent handles end-to-end, where it hands off to a human, and what is explicitly out of bounds. Most companies/ people aren’t thinking this way yet until they are forced to because some agent went a step too far…
Data/Systems Integration – While integration is much easier with MCP, the question remains about whether the things should be connected. Access management is a core foundation to a well-built system, and for solutions design the architect needs to decide which sources are canonical, what’s read versus write, and which systems are out of scope. This is also where KPI alignment work pays off; architected integration decisions will impact what context reaches the agent (e.g., definitions, trusted tables, etc.).
Quality Assurance – QA for deterministic tools surfaces bugs and whether the solution ships properly; for AI agents it is about testing the boundaries (because it might not return the same answer twice). That means invariants (a table can never shrink, a total can never go negative), validation checks between the agent’s answer and anything that acts on it, and a real test-versus-production separation. Even Anthropic says that predictable, predefined workflows beat autonomous agents for most well-defined tasks. Deciding where the system is allowed to be probabilistic and where it must be deterministic is the architect’s call, and making an informed decision in this area is becoming increasingly important for solutions design.
Stakeholder Onboarding/ Expectations – The consumers of the solution need to know what it can and can’t be trusted with. Business users assume the pipes are connected and the data is right. Onboarding therefore becomes part of the architecture discussion and definition. Having somebody outline and document the agent’s purpose, what it can’t do, where the human checkpoints are, and who owns the output is necessary. Honestly, the most important audience for this is often the senior execs who expect AI to run everything with limited hand-holding.
Something I only realized after writing the above list is that these are the non-functional requirements all over again. None of this is embedded in any AI or SaaS tool, you need to build the mindset and capability. Of course, having the right tools to do this are also crucial (and the right tool isn’t just Claude or ChatGPT), because moving the data from source to solution in a predictable and trusted way basically underpins each of these four boundaries and ensures your tool is deterministic/ reliable.
Again, somebody focusing on that is the benefit of a Solutions Architect. If you don’t hire one, well somebody has to think about these things (and it usually isn’t the AI tool without proper instructions)
How to Architect Solutions Moving Forward
This is a crucial question and a lot of businesses are having a tough time figuring out how to approach this new reality. Here is my best guidance for now (this may change in a few years but the principles should have decent longevity):
Start with the architecture, not the tool – Obviously I’m going to say this. You can’t bolt an AI agent onto a failing architecture/ toolset, then call yourself AI-native. Design for the agent the way you would have designed for any new customer in a way that can scale. Then connect things. Or test out the design in a sandbox, learning in a controlled environment.
Decide where determinism is required – When I talk to finance or ops teams the conversation always goes to the fact that they need deterministic models, not AI agents. You can still use the AI Agent as a harness/ orchestrator, but the outputs need to be the same every time with testable paths so that the business trusts the number. This fits into the architecture but is worth calling out on its own. In my opinion, this is most important for engineering/ data movement.
Model for trust – AI agents will consume your data and act on a wrong number. KPI alignment and modelling work has to come before hooking up solutions (especially if they are vibe-coded). Companies are starting to realize this as hallucinations accelerate and things stop looking right. Also, this breaks down trust in the data & AI, which isn’t great for the data/ AI culture!
Govern the consumption layer – A lot of things come back to governance now. Figuring out who or what is allowed to consume which data, and under what guarantees, is crucial. Previously, companies ignored governance because a human could apply the right judgement. With AI, you have to be more careful (as a lot of organizations are figuring out).
Keep a human accountable – People still need to be accountable. If an agent’s output goes into a decision, a specific person needs to answer for it. Design that into whatever solution architecture you set up. Maybe you don’t have a full-time resource in this area, but there needs to be someone!
Now I’ve not seen the Solutions Architect role disappear. Actually, I see a lot of companies still hiring for it.
The problem is that the companies who should be hiring for it aren’t, because they don’t understand the role and where it is needed. They also don’t understand how much exponential value can be gained by doing this properly.
Unlocking the power of AI is not just plugging in a tool; it is architecting a system around solutions that make sense for the business in a way that works with how people work, while being scalable and secure. Then it is using the right tools with the right AI capabilities and skills to make that job easier/ more manageable!
As the data and AI stack are becoming fused into one AI-native stack, aligning the foundations between the front-end business analytics and the back-end foundations will become even more crucial. And a product manager, AI engineer or business stakeholder cannot do this on their own!
So please heed my warning, and don’t let the solution architecture domain disappear.
And if you’re staring at an agent rollout right now and wondering why it is not going well, well, you may want to actually invest in a Solutions Architect. Or you can also reach out to me; it is a recurring conversation I’m now having most weeks. Until then, have a great weekend and see you next Sunday!
Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!
A note on this partnership: I worked with the team at Estuary on this piece. Their Agent Skills let you hand an AI assistant a defined, repeatable workflow written as a plain SKILL.md file that works across Claude Code, Cursor and other agents. Basically, it runs your scoped engineering job (one place where you really need deterministic, trusted workflows) instead of improvising against raw tool access. Underneath, Estuary handles reliable real-time data movement: change data capture, streaming and batch across 200+ connectors. If you’re wiring agents up to real data, it’s worth a look. Thanks to them for supporting the newsletter!
Great article! Solution architect will become more important imho. Product onboarding fails when the readiness layers aren’t architected first.
People try to manage expectations against fragile systems. Semantic Readiness (aligned definitions, canonical sources) and Operational Readiness (observable failures, clear accountability) have to come before stakeholder messaging. Solutions architects can help ensure those requirements are met.
Once those are solid, expectations almost manage themselves. Skip the architecture and you’re just replacing human judgment with nothing. A faster pipeline for failures.