The Evolution of the Solution Architect: 5 Years in the Seat, 10 Years in the Game (& My Outlook for 2026)

First of all, happy new year! I hope you had a great break. This is my favorite break as everybody stops working and we truely get no emails during this time.. hehe.

I wanted to start this year by writing down my thoughts on how our industry has shifted. Looking back at 2016 - 10 years ago when I first started as a junior finance consultant—and comparing it to where we are today, January 1st, 2026, the contrast is incredible.

I want to be very personal and honest with you in this post because there is a lot to unpack. The role of the D365 F&O Solution Architect isn't what it used to be. Honestly? It shouldn't be.

The "Good Old Days" of Dynamics AX

When I first started, I remember being on projects that were strictly Microsoft Dynamics ERP—whether it was AX 2009 or AX 2012. Back in the day, these were pure technical implementations. The complexity was manageable. The scope was smaller. The teams were lean.

We were implementing in small-to-medium-sized companies. Sure, there were some bigger fish, but that wasn't the regular deal size. We have to remember the context: Dynamics wasn't really competing with SAP or Oracle back then, especially in the German market where I was working. SAP and Oracle were on a different level, catering to the massive enterprise customers. Dynamics AX was the sweet spot for the mid-market.

The Explosion of the Ecosystem (It's Not Just ERP Anymore)

If we compare the product of 2015 to what we have today, the development is tremendous. But the explosion isn't just because Dynamics 365 Finance and Operations grew in functionality. It’s because Microsoft invested heavily in getting everything integrated.

We aren't just doing ERP projects anymore. We are delivering programs that seamlessly include CRM, Field Service, Customer Service, Retail and many others.

Why? Because the platform supports it natively.

Back in the day, connecting your Retail offlince processes to your ERP was a nightmare of custom interfaces. Now, we are able to offer clients so much more value because the data flows naturally across the platform. Microsoft is now a leader in the enterprise space because they sell a connected reality, not just a finance tool.

We can criticize Microsoft for many things. But don't forget that they directly pay our bills and put food on our tables by building this product. The market is happy with it, and the evolution has been life-changing for us in the industry.

The "Luxury Problem": Growing Pains in Program Management

However, this explosion brings a new set of challenges. We are still struggling to streamline these large-scale programs effectively.

Because we grew so fast, we are facing what I call a "luxury problem." We have more tools and bigger projects than ever before, but our ability to manage them hasn't quite caught up.

I see this constantly in:

• Planning and Forecasting: It is incredibly difficult to predict timelines when you have five different workstreams (ERP, CE, Power Platform) moving at different speeds.
• Dependencies: Identifying dependencies between teams and processes is harder than ever. A decision in the Field Service app might break a posting profile in Finance.
• Communication: We aren't just sitting in one room anymore. We are managing armies of consultants.

The complexity of a modern Microsoft Dynamics 365 implementation demands a level of rigor we didn't need ten years ago.

The "All-Knowing" Architect vs. The Strategic Architect

This is why the ERP Solution Architect role had to change.

I remember back in the day working with a specific Lead Architect. He was a brilliant guy. He—and many others from that era—was so knowledgeable that I felt I could never reach that level. He knew every little parameter. He knew every checkbox. He knew every hidden function of AX 2012. It was admirable.

As a junior, you get blinded by that light. You think that is the goal.

But I’ve realized that knowing every corner of the software is not where a Solution Architect should be focused today. Today, clients aren't just asking for technical encyclopedias. They need a 360-degree perspective to handle those "luxury problems" I mentioned above.

Today, my peers and I are involved in:

• Steering committee meetings and high-level project management.
• Agility discussions and setting up DevOps.
• Architecture design (Azure, Integrations, Security).
• Advising on business best practices, not just software setup.
• Team leadership, resourcing, and interviewing.

The Methodology Shift: From Modules to Process Mining

There is another massive shift we need to talk about. Ten years ago, we scoped and structured work based on modules (GL, AP, AR). But Oracle and SAP implementations never worked that way. They always focused on Business Processes.

Over the last few years, Microsoft has pushed the Microsoft Business Process Catalog upon us. This was their way of telling us, "Hey, implementing functionality is not sufficient. You have to implement processes."

For 2026, we need to take this a step further. It is not enough to just design the process. We need to validate and optimize it using Process Mining in Dynamics 365.

We need to learn from the SAP/Oracle world here. You can have the most "shiny" functionality in the world. But if it doesn't help the business in their daily jobs, that functionality is trash. Process mining allows us to see how the system is actually being used versus how we designed it.

AI is Disturbing Our Deliverables (In a Good Way)

Finally, let's talk about AI in Enterprise ERP.

Yes, we have Copilot and the new MCP server for F&O. But AI is doing more than just adding features to the software—it is disturbing our project methodology and our deliverables.

We need to adopt AI in how we work.

Clients are demanding more value for less cost. They know AI exists. They expect us to use it to generate documentation, automate testing, and migrate data faster. If we stick to the old manual ways of doing things, we become obsolete.

However, we need a reality check on Dynamics 365 Copilot reliability. We are implementing software for enterprise applications where the success rate needs to be near 100%.

If you run an autonomous AI agent 100,000 times, what happens?

I remember years ago implementing an automatic payment settlement engine. I told the client, "We only have a 3% mismatch rate." I thought that was good. The client looked at me and said, "That is not acceptable." Why? Because 3% of 100,000 transactions is 3,000 invoices that need manual review every month.

So for 2026, we have to figure out where to use AI to drive efficiency without creating a mess in the aftermath. Specifically the week after we roll off the project... and managed services takes over ;)

Happy 2026. I’d love to hear your thoughts.