The Greenfield Thought Experiment. The Architecture We Would Recommend Today.
First, an important clarification: What follows is a thought experiment, not a roadmap. We know that no company tears down its existing tool landscape and starts from scratch. But we believe this: if you do not have a clear picture of the target architecture, you cannot build a meaningful migration path. That clarity is exactly what this part is about.
And for the difficult question left open at the end of Part 1: If not the best-of-breed model of the 2000s – then what?
What Has Fundamentally Changed Since 2005
Four shifts define the picture of 2026 differently from that of 2005. Each one matters on its own. Together, they explain why the old architectural logic has become outdated.
1. Infrastructure Has Become Cloud
Twenty years ago, infrastructure was an investment decision: buy servers, set up data centers, purchase licenses. Today, it is largely a configuration decision: activate SaaS, create an account, start a subscription. The barrier to adopting new platforms has dropped dramatically. That changes more than just the acquisition cost. It changes the entire logic. Platforms are no longer assets — they are services. And that changes what it costs to correct a bad decision.
2. Integration Has Become API-Driven
Twenty years ago, every integration had to be developed individually — its own project with its own budget. Today, practically every relevant platform offers open APIs, commercial iPaaS solutions handle data routing, and event-driven architectures enable loose coupling. What used to be the most expensive trap of the best-of-breed approach — interface spaghetti — has become its own architectural layer that can be designed deliberately.
3. Data Has Become Its Own Discipline
Twenty years ago, data was a byproduct of applications — it lived inside the database of the respective system. Today, we think about data separately from applications: centralized data warehouses, data lakes, and master data management as dedicated platforms. This is not academic. Companies that keep master data in a separate layer can replace applications without losing their data. Those that do not create a lock-in that becomes more expensive every year.
4. AI Has Changed the Economics of Custom Development
This is the newest and most immediate shift. What was unquestioned until 2022 — standard software is cheaper than building your own — is now a more nuanced calculation. AI-assisted development shifts the break-even point where custom development becomes worthwhile. But that is material for Part 3 of this series.
These four shifts work together. No single one explains on its own why the best-of-breed logic of the 2000s no longer works — but together they fundamentally change the assumptions on which that logic was built.
The Greenfield Architecture as a Hypothesis
If we were designing a tool architecture today for a typical mid-sized company, it would look something like this: a layered model with five levels and clear separation of responsibilities.
The Core Layer: Four to Six Platforms
At the center is a modern ERP system as the backbone — the single source of truth for finance, procurement, inventory, and production. Alongside it sits a CRM for sales, service, and marketing. Depending on the business model, this is complemented by a PLM system (for product data and engineering processes — often indispensable in manufacturing and industrial companies) and an MES for production execution. On top of that sits a data and BI platform for analytical insights across all systems.
That is four to six platforms — not 47. Each with a clearly defined functional responsibility. Each with a defined data model. Each with an accountable operational owner. This is not less differentiation compared to the zoo. It is more.
The Integration Layer: A Deliberate Architecture
Instead of point-to-point connections, there is an iPaaS solution or an event backbone. Data flows through a central routing layer — no direct database-to-database connections. This brings two major advantages. First, it becomes transparent which data flows where. Second, a single platform can be replaced without the entire interface landscape collapsing with it. This is the structural answer to the biggest risk of the old best-of-breed approach.
The Data Layer: A Centralized Model
Master data does not live in the ERP or CRM — it lives in its own master data layer and is distributed from there to the applications. Customers, materials, and suppliers each have an owner — one platform that serves as the leading source — while all other systems receive synchronized copies. This is the organizational response to the master data chaos we encounter in almost every assessment.
The Extension Layer: Low-Code and Targeted Custom Development
Not every workflow needs to live inside a standard platform. Specialized workflows that affect only a small user group or are highly company-specific belong in a low-code platform or a controlled custom-built solution — but intentionally, not as shadow IT. This layer is the answer to the demand for flexibility without falling back into uncontrolled sprawl.
The Experience Layer: Portals, Mobile Apps, Self-Service
This is the layer the user actually sees. Ideally, employees, customers, and partners do not access the core systems directly. Instead, they interact with task-specific interfaces that display exactly what they need for the job at hand. This reduces training effort and protects the core systems from overuse.
Five layers, four to six core platforms, and a clear separation of responsibilities. That is the picture of the Greenfield architecture we would recommend today.
→ We would no longer recommend a zoo. But we would not recommend a monolith either.
Composable or Suite – The Strategic Choice
At this point, we arrive at the most important strategic decision: Who builds the core layer? There are two extreme approaches – plus one pragmatic middle ground.
The Suite Strategy
All core functions come from one vendor. An integrated ERP that also includes CRM, PLM, and potentially MES capabilities. Vendors such as SAP S/4 or Microsoft Dynamics 365 follow this approach. The advantage: fewer interfaces, a shared data model out of the box, and one contractual partner. The downside: strong vendor lock-in, often mediocre best-of-breed functionality, and high licensing costs for modules that may never be fully used.
The Composable Strategy
Each core function is covered by the strongest platform available. ERP from vendor A, CRM from vendor B, PLM from vendor C – connected through the integration layer. The advantage: genuine best-of-breed functionality, high flexibility, and lower dependency on individual vendors. The downside: discipline is required. Without a clear integration architecture, you end up back in the zoo within five years.
Our Honest Recommendation: Hybrid with Discipline
A suite for core processes where integration and data consistency are critical — ERP plus CRM from the same ecosystem is often the right choice. Best-of-breed solutions for strategically differentiating capabilities where specialized functionality creates value — PLM in engineering and manufacturing, MES in production, or BI platforms with unique analytical strengths.
This is not the old best-of-breed model repackaged. The difference lies in the deliberate integration layer and the centralized data layer. We no longer let best-of-breed grow accidentally – we design it intentionally.
→ The real question is not which system to choose, but which architectural principles to follow.
Three Non-Negotiable Design Principles
No matter which platforms are selected, three principles are, in our view, non-negotiable. They are what distinguish the new Greenfield architecture from the old best-of-breed logic.
One Source of Truth per Data Object
For every business-critical data object – customer, material, supplier, order – there must be exactly one system that holds the authoritative truth. All other systems receive synchronized copies. If customer data is maintained independently in three systems, the next zoo is already being built. Accepting this principle requires an organizational decision about who owns which data object – and that is far more than a technical question.
APIs Before Database Access
If System A needs data from System B, it should access it through System B’s API – never directly through the database. That sounds obvious, but reality often looks different: reporting tools connect directly to ERP databases, migration utilities bypass application logic, BI systems read from replicas. Every direct database connection is architectural debt that becomes expensive the moment the source system needs to be replaced.
Clear Domain Ownership
Every business process must have a business-side owner – not an IT owner – and must be clearly assigned to one platform. If three platforms simultaneously model the purchasing process, no one retains authority over how that process should actually work. Architectural clarity follows organizational clarity, not the other way around.
These three principles are what keep the Greenfield architecture alive after it has been built. Without them, even the best architecture becomes the next zoo within five years.
But Wait – With AI, Can’t We Just Build Everything Ourselves?
This is the uncomfortable question we hear frequently, and we do not want to avoid it. If AI dramatically reduces the cost of custom software development, why use platforms at all? Why not build everything yourself?
The answer deserves its own article. That is why it will be Part 3 of this series. But one thing up front: the shift in the economics of development through AI does indeed change the make-or-buy equation — but it does not make “build everything yourself” the smart strategy. It simply moves the boundary where custom development becomes worthwhile.
Which areas those are, which new risks emerge, and how this fits into the architecture described here – that is what we will explore in two weeks.
What Remains from This Part
For now, this is the picture that remains: Five layers. Four to six core platforms. A deliberate integration and data layer. Three non-negotiable principles.
That is the recommendation we would give today if someone came to us with a blank whiteboard. And to everyone thinking, “In reality, nobody starts from a true greenfield”: correct.
Which is exactly why Part 5 of this series will focus on the real challenge — how to move from today’s application zoo toward a target architecture without a big bang and without disrupting day-to-day operations. But before we can design the migration path, we first need a clear target architecture. That target was the purpose of this part.
And the most important question to take away: If you were to run an architecture workshop in your company today — how many layers and core platforms would end up on the whiteboard?