Salesforce Is Still Part Of The Conversation. It Is No Longer The Boundary.

Matt/ July 27, 2026/ Architecture, Enterprise Architecture, Platform Modernization

Why deep platform expertise should become a foundation for broader enterprise architecture, not a permanent boundary.

Salesforce Is Still Part Of The Conversation. It Is No Longer The Boundary. - enterprise platform modernization planning session.

This article is part of the Modernizing The Enterprise Platform series, which uses Salesforce as the evidence base for a broader discussion about enterprise architecture, AI, data, integration, identity, security, governance, DevOps, and operating models in mature enterprise platforms.

My Summer ’26 Salesforce security campaign ended last week, and the thing I keep coming back to is not a specific release update, authentication pattern, or connected app setting. Those details mattered, and some of them mattered a lot, but the larger lesson was more familiar: changing a mature enterprise platform safely is rarely a narrow platform problem.

That observation started to sharpen during a LinkedIn conversation with my friend Johan Furmann, a Salesforce Certified Technical Architect. We were talking about how the Salesforce market has changed, particularly the dwindling number of genuinely new enterprise Salesforce implementations and the growing importance of modernizing the large, established orgs that already run critical parts of the business. These are not blank-slate programs where the primary question is how to configure a clean model. They are embedded platforms surrounded by integrations, identity dependencies, historical customization, operational constraints, and years of architectural decisions that may or may not still be visible.

Johan and I started referring to these mature orgs, somewhat affectionately, as “snake orgs” because you never quite know what you are going to find when you look under the hood. The phrase is informal, but the pattern is serious. A change that looks straightforward in isolation can expose weaknesses in ownership, governance, architecture, testing, data, integration, or communication. The surface area is not limited to Salesforce, even when Salesforce is where the issue first becomes visible.

That is the thesis behind the next series of articles I want to write. Salesforce remains central to my experience and credibility. I have spent 17 years building on the platform, and that depth still shapes how I see enterprise systems. What has changed is that the hardest problems I keep encountering are increasingly enterprise architecture problems that happen to be visible through Salesforce.

Security changes are a good example. On paper, a security remediation may sound like a checklist: strengthen authentication, review connected apps, reduce excessive access, tighten session behaviour, or replace an outdated integration pattern. In practice, each of those changes can force an organization to answer questions it has been avoiding for years. Who owns this integration? Which business process breaks if the credential changes? Why does this automation have broad access? Who is allowed to approve an exception? How do we test a process that crosses four systems and two teams? Where is the rollback plan if the release behaves differently in production than it did in a lower environment?

Those are not Salesforce questions in any narrow sense. They are ownership, operating model, integration, identity, security, and governance questions. Salesforce is often where the friction becomes visible because the platform sits close to business process, customer data, workflow automation, reporting, and system integration. It becomes the place where architectural decisions made elsewhere eventually show up as production risk.

What I find more interesting is that the same pattern is becoming more important as organizations move into AI. A demo can make AI look like a feature. A production implementation quickly turns it into an enterprise architecture problem. The agent needs data it can trust, permissions it should not exceed, interfaces that behave consistently, audit trails that explain what happened, and escalation paths for cases it should not handle alone. If the underlying platform is unclear, the AI layer does not make that uncertainty disappear. It usually makes the uncertainty harder to ignore.

That is why I do not see a move from Salesforce architecture into enterprise and AI architecture as a departure from the work. I see it as the natural extension of the work. Deep specialization should not become a wall around a person’s thinking. At its best, it becomes the evidence base from which broader patterns become visible.

To be clear, I am not arguing that Salesforce no longer matters. I am not arguing that platform-specific expertise is becoming less important. In many mature environments, the opposite is true. The details matter more because the consequences of getting them wrong are larger. What I am arguing is that platform expertise becomes more valuable when it is connected to the enterprise around the platform.

The architect who understands only features will eventually be constrained by the edges of the product. The architect who understands how the platform participates in identity, data, integration, compliance, security, DevOps, change management, and business operations can help the organization change more safely. That distinction matters in mature enterprises because the challenge is no longer proving that the platform can be useful. The challenge is continuing to evolve it without breaking the business it already supports.

This series is about that problem. Salesforce will continue to be the primary evidence base because it is the platform I know most deeply, but the conclusions will extend into enterprise architecture, AI, data, integration, identity, security, governance, DevOps, and operating models. The recurring question will be simple, even when the answers are not: how do you modernize a platform that the business already depends on?

I suspect that question will define a larger share of enterprise architecture work over the next several years. New implementations will still happen, but many organizations already own platforms that are too important to replace casually and too constrained to ignore. The work ahead is not only about building new capabilities. It is about improving the organization’s ability to change what already exists.

Continue The Series

Share this Post

About Matt

Matt McGuire is a Salesforce architect, AI builder, and punk musician based in Toronto. Canada's #1 certified Salesforce professional, 43× certified across architecture, development, AI, and a wide range of platform products. He's been building on Salesforce for 17 years and currently spends most of his time at the intersection of AI and the platform. The Music Intelligence Engine is his most interesting project to date. He thinks you should read the whole series.