The Question Behind Every Modernization Decision
Which platform handles production scheduling? Which integration tool connects the warehouse system to the ERP? Which data platform consolidates reporting? Those are real questions, but they arrive too early. The sequence matters, and the business architecture has to come first.
Business architecture defines what the organization needs to be able to do. Application and data architecture define which systems will do it and how information will move between them. Technology architecture defines the infrastructure those systems run on. Each layer depends on the one before it. Changing the application layer without a clear business architecture means the new system may be technically sound but misaligned with how the business actually creates and delivers value.
What Business Architecture Actually Means
Business architecture is a representation of holistic, multi-dimensional business views covering capabilities, end-to-end value delivery, information, organizational structure, and the relationships among those views and the company's strategies, products, policies, and stakeholders. It is not an org chart, a process map, or a list of software systems. It is the structured answer to: what does this business need to be able to do, for whom, and how does value move through the organization to make that happen?
Each of those is a business capability. Some are supported by a single system. Many cross several applications, teams, and handoffs. The business architecture makes those relationships visible before any system change begins.
SAP's enterprise architecture methodology, which is aligned with the TOGAF standard from The Open Group, describes business architecture as the prerequisite for architecture work in any other domain. A knowledge of the Business Architecture is a prerequisite for architecture work in any other domain including data, application, and technology. That sequencing is not a formality. It reflects a practical reality: if you don't know which capabilities the business depends on and how they connect to each other, you cannot reliably decide which systems to change, in what order, or what the integration boundaries need to be.
How the Phases Connect
A phased enterprise architecture approach works because it separates what the business needs from how the technology delivers it, and then sequences the technology changes so that each phase can be validated before the next one begins.
The business strategy defines the goals and drivers and metrics for success, but not necessarily how to get there. That is the role of the Business Architecture. This distinction matters for manufacturers because a growth strategy, an acquisition, or a new product line changes the capability requirements before it changes the systems. The architecture vision translates the business direction into a set of capability and information requirements that the application and data architecture must satisfy.
The second phase designs the business architecture itself. This is where a business capability map describes the organization's ability to perform business activities successfully and a business value flow diagram illustrates value-adding business activities aimed at fulfilling specific business goals. For a manufacturer, this work can surface which capabilities are currently supported by aging custom software, which are handled by workarounds outside any system, and which are genuinely well-served by the existing ERP or specialized applications. That picture helps determine where modernization may be necessary and where it is not.
The third phase designs the application and data architecture: which systems will own which records, how data will move between them, and where integration boundaries sit. This is where ERP, a data platform, an integration layer, or custom software enters the conversation, but only as responses to the capability and information requirements already defined. The same logic applies regardless of which ERP or platform a manufacturer uses: the system selection and integration design follow the business requirements, not the other way around.
Coexistence, migration, validation, and cutover are the practical mechanics of moving from the current state to the target architecture without stopping operations. In a phased approach, the old system and the new system may run in parallel for a period while the manufacturer validates that the new capability meets the defined requirements. During that window, each system needs a defined record of authority: which version of an order, an inventory balance, or a production schedule is authoritative, and which system's data governs decisions. Validation criteria should be set before cutover begins, not after, so the team has an objective basis for deciding when the transition is complete.
The ADM is highly iterative: within phases, between phases, between cycles, with stakeholder reviews after each phase, which means a manufacturer does not need to complete a full enterprise architecture before making any system change. Each phase can be validated against operating reality before the next one begins, and the coexistence period is a deliberate part of that validation, not a sign that the migration is behind schedule.
Governance Without the Paperwork
Governance in this context means deciding who has authority over which architecture choices and making sure those decisions are visible and durable. The methodology addresses this through artifact selection: the selection of artifacts depends on the nature of the architecture project and the stakeholders involved. These should be selected for the sake of the stakeholders, not for the sake of architecture.
For a manufacturer, that principle translates directly. A business capability map is useful if the operations team and the IT team can use it together to agree on which systems own which records and which handoffs need to be engineered. A data catalog is useful if the finance team and the supply chain team can use it to agree on which version of inventory or order data is authoritative. An architecture diagram that only the technology team can read does not govern anything.
Decision rights follow from this. Each of those is a governance decision, and each needs an owner who can make it, communicate it, and enforce it when a vendor, an implementation team, or a new requirement pushes against it. Without a named owner, architecture decisions can be harder to enforce when implementation pressures arise.
Applying This to Your Modernization Decision
If you are deciding how to change ERP, cloud workloads, integrations, or custom software without disrupting customer commitments, these are the questions to work through before selecting or changing any system:
-
Which business capabilities are actually at risk? Map the capabilities behind your customer commitments, such as quoting, order confirmation, production scheduling, quality release, shipping, and invoicing. Identify which systems currently support each one and where the handoffs are manual or fragile.
-
What does the architecture vision require? Define what the business needs to be able to do differently or better. A new product line, a new customer segment, or a new fulfillment model changes the capability requirements. The system changes should follow from those requirements, not precede them.
-
Which application and data boundaries need to change? Once the capability requirements are clear, identify which systems need to own which records, which integration points need to be engineered or re-engineered, and where a data platform or custom capability fills a gap that packaged software cannot.
-
What is the coexistence plan? Define which records each system owns during the parallel-run period, how conflicts are resolved, and what the validation criteria are before cutover. Setting those criteria in advance gives the team an objective basis for deciding when the transition is complete.
-
Who owns each architecture decision? Identify the person or team with authority over each major choice: system of record for each data domain, integration design, cutover criteria, and exception handling.
-
Are the artifacts serving the stakeholders who need to make decisions? If the architecture documentation is not being used by the operations, finance, and supply chain teams to make real decisions, it is not governing anything. Simplify it until it is.