Application portfolio rationalization should not end with a list of applications to retire or replace. It should produce a clear picture of the landscape the organization is trying to build. Without that picture, individual decisions remain isolated, exceptions multiply, and teams continue making local choices that recreate the same complexity the program was designed to remove. The target-state application landscape is the operating blueprint that connects rationalization decisions to enterprise architecture, platform strategy, and business capability needs. It defines not just which applications remain, but how capabilities should be supported, where standardization matters, where variation is acceptable, and what architectural rules should govern future demand. This chapter explains how to design that landscape in a practical way: through explicit design principles, capability-based mapping, thoughtful platform choices, and clear architectural guardrails. The objective is not to create a perfect future-state diagram. It is to define a target state precise enough to guide decisions and durable enough to prevent the estate from growing back into disorder.
12.1 Target-State Design Principles
Every target-state application landscape needs a set of design principles. These principles are not slogans. They are decision rules that help the organization choose between competing options when cost, speed, business preference, and architecture do not point in the same direction. Without them, the target state becomes a collage of case-by-case compromises. With them, portfolio decisions become more consistent and easier to defend.
A good principle is specific enough to influence behavior. “Simplify the landscape” is too general to be useful. “Prefer one enterprise platform per business capability unless a clear business case for variation is approved” is much more actionable. Principles should therefore be phrased as operating rules, not aspirations. They should also be few in number. An organization rarely needs more than six to ten principles to govern the landscape well.
The most common principle is standardization where the business does not compete. Commodity capabilities such as core finance, HR administration, collaboration, case management, document handling, service management, and common workflow should normally be supported through a deliberately limited set of enterprise platforms. The goal is not uniformity for its own sake. The goal is lower cost, lower complexity, stronger control, and faster change in areas where local uniqueness rarely creates enterprise value.
A second principle is to differentiate only where business value justifies it. Some capabilities genuinely support competitive advantage, regulatory specialization, market-specific behavior, or distinct operating models. These are the places where the organization may allow more flexible tooling, more tailored workflows, or selective custom development. But the burden of proof should be explicit. Variation should be a designed choice, not the accidental result of historical purchases and local autonomy.
A third principle is to prefer configuration over customization. Excessive customization is one of the main reasons packaged platforms become expensive to maintain and difficult to upgrade. Where the business can reasonably adjust process design, configuration should be favored over bespoke code. Customization should be reserved for true differentiating needs or unavoidable regulatory requirements.
A fourth principle is to reduce the number of systems of record. Fragmented authoritative data is one of the most expensive and persistent causes of application complexity. The future state should minimize duplicate systems of record for core entities such as customer, product, employee, supplier, and financial transaction data. This does not require a single application for everything, but it does require clarity about where authoritative data lives and where it does not.
A fifth principle is to simplify integration by design. The target landscape should not merely shift complexity from applications into interfaces. When multiple platforms remain necessary, the organization should favor well-governed integration patterns, fewer bespoke point-to-point connections, and clearer ownership of cross-system data and workflow. This principle becomes especially important in hybrid estates that will continue to include a mix of SaaS, platform suites, and retained legacy assets for some time.
A sixth principle is to treat lifecycle intent as part of the architecture. Applications in contain or retire status should not accumulate new demand by default. Strategic platforms should be the default landing zone for new needs unless an exception is approved. This principle is one of the best defenses against portfolio relapse because it connects day-to-day demand decisions with the long-term target state.
A seventh principle is design for operational resilience and control, not just functional fit. An application that supports the right capability but sits outside security, identity, logging, or recovery standards does not fit the target landscape, however attractive it may look functionally. Good target-state design includes operating characteristics as first-class requirements.
Principles should be documented briefly and used actively. A one-page principle sheet reviewed in architecture, procurement, and steering forums is often enough. The real test is whether the principles resolve difficult choices. When a region asks for a separate planning tool, or a business unit wants a local workflow platform, or a program proposes a heavily customized module, the design principles should provide the answer framework. If they do not, they are too vague to govern the landscape.
It is also useful to rank principles when they are likely to conflict. For example, “protect control and resilience” may take priority over “move fast through local tooling,” and “reduce systems of record” may take priority over “preserve regional preference.” This does not eliminate judgment, but it reduces ambiguity in steering forums. Exception handling should follow the same logic. Any approved exception should name the principle being overridden, the reason, the approving authority, and the date on which the exception must be revisited.
12.2 Capability-Based Mapping of the Future Landscape
Once design principles are in place, the next step is to map business capabilities to the future-state application landscape. This is where the target state stops being conceptual and becomes operational. Capability-based mapping asks a simple question: for each important business capability, what is the intended landing zone in the future estate? In some cases the answer is a single strategic platform. In others it is a combination of platforms with clearly defined roles. In still others it is a temporary hybrid state with a time-bound path to simplification.
The advantage of capability mapping is that it keeps the future landscape tied to business needs rather than to product names. Senior leaders do not invest in software for its own sake. They invest in the ability to close the books, hire employees, plan supply, serve customers, maintain assets, manage products, and make decisions. A capability map therefore becomes the bridge between business architecture and application decisions.
The mapping exercise should start with the enterprise capability model already used in portfolio classification. For each capability, the team should identify the target support model. This usually includes four questions. Which application or platform will be primary? What secondary tools, if any, are acceptable? Where will the system of record sit? What local variations, if any, are still justified? These questions turn a generic target-state diagram into a usable operating blueprint.
Not every capability should be mapped at the same level of detail. High-cost, high-risk, or high-overlap domains deserve the most attention. Capabilities already served well by a stable enterprise standard may need only light confirmation. The effort should focus where future-state ambiguity is most likely to preserve fragmentation.
The mapping should also reflect time. Many organizations need to show both an interim state and an end state. For example, procurement may move to one enterprise platform over two waves, with an acquired business using a local system temporarily. Manufacturing may retain several plant systems for now while data and reporting are standardized first. A static picture that ignores timing can mislead leaders into thinking the future state is simpler or nearer than it really is. A better approach is to show current state, transition state, and target state for the most important capability clusters.
A strong capability map also clarifies boundaries between platforms. One of the main causes of application sprawl is ambiguous functional ownership. If the ERP platform can support workflow, reporting, master data, and local extensions, while a low-code platform can also support workflow and local extensions, and a separate SaaS tool can also manage approvals and case steps, overlap will grow again unless roles are defined. The capability map should therefore state not only where capabilities land, but also the intended responsibility of each strategic platform. This prevents the target state from becoming a new form of overlap.
It is often useful to express capability mapping through a simple matrix. Down the left side sit major capabilities. Across the top sit the strategic platforms or approved solution categories. The cells indicate which platform is primary, which is secondary, and which is prohibited or exception-only. This type of map is especially effective in executive discussions because it shows concentration, overlap, and white space quickly.
Target-state capability mapping should also address data and analytics explicitly. Many organizations rationalize transaction systems but leave a fragmented reporting landscape untouched. The future-state map should therefore show where operational reporting belongs, where enterprise analytics belongs, and how data products or shared models will reduce the need for local extracts and duplicate marts. If this is not designed up front, old reporting habits will quickly recreate complexity around newly consolidated platforms.
The purpose of capability mapping is not to predict every future tool. It is to define the intended shape of the estate so that each portfolio decision can be tested against a business-based target. When done well, the map becomes the reference point for roadmap planning, architecture review, and investment decisions long after the initial rationalization program is over.
12.3 Standardization Choices: Enterprise Platforms, Suites, and Best-of-Breed Tools
One of the most important decisions in target-state design is how far to standardize and where. In almost every portfolio, leaders face the same tension. Enterprise platforms and large suites promise simplification, integrated data, lower vendor sprawl, and easier control. Best-of-breed tools promise stronger specialized functionality, faster innovation, and a better fit for certain business needs. The right answer is rarely absolute. It depends on the capability, the operating model, the degree of required differentiation, and the organization’s ability to govern complexity.
Enterprise platforms should usually be the default choice for broad, common capabilities that benefit from consistent process, common data, and shared controls. Core finance, HR administration, procurement, sales operations, service management, and many workflow-heavy functions often benefit from a smaller number of widely adopted platforms. Standardization in these areas reduces interfaces, duplication, vendor management overhead, training burden, and local support models. It also creates leverage for process improvement because the business is working within a common structure.
Suites become especially attractive when the organization values cross-functional integration more than specialized local optimization. A suite can reduce translation cost between modules, simplify security and identity design, and create a more coherent vendor roadmap. But the case for a suite should not be accepted uncritically. Some suites appear integrated at the commercial level while still requiring significant configuration, middleware, or data work to operate cleanly in practice. The target state should therefore be based on demonstrated operating fit, not only vendor positioning.
Best-of-breed tools have a legitimate role where capabilities are genuinely specialized, rapidly evolving, or strategically differentiating. Advanced planning, pricing, laboratory management, plant operations, asset optimization, specialized customer engagement, and certain industry-specific platforms may justify more focused solutions than a general enterprise suite can provide. In these areas, forcing everything into the suite may create functional compromise, user frustration, or costly customization. The discipline is not to avoid best-of-breed tools entirely. It is to use them selectively where the business case is explicit and where the organization is willing to manage the additional architectural complexity.
Standardization choices should therefore be made capability by capability, not ideology by ideology. For each capability, the team should weigh five questions. How important is cross-functional data and process integration? How differentiated is the required functionality? How much complexity can the organization realistically govern? How mature and scalable is the enterprise standard? What is the long-term economic and architectural cost of allowing another tool into the estate? These questions usually lead to more balanced decisions than generic statements such as “suite first” or “best tool wins.”
The organization should also define tiers of approved solution types. For example, there may be tier one enterprise anchor platforms, tier two approved specialist platforms for certain capabilities, and tier three exception-only local tools with time-bound approval. This tiering makes standardization more practical because it gives teams a controlled menu rather than a false choice between total uniformity and unrestricted freedom.
Another important choice concerns platform extensibility. Modern suites and low-code platforms often encourage local extension development. This can be useful, but it can also recreate the sprawl the program is trying to eliminate. The target-state landscape should therefore distinguish between approved extensions that deepen the value of a strategic platform and uncontrolled local development that effectively creates a second application portfolio inside the first. Governance, ownership, and reuse rules are critical here.
Standardization decisions also need to reflect organizational maturity. A company with strong enterprise architecture, disciplined data governance, and effective demand management can successfully operate a more mixed landscape than a company with weak governance and heavy decentralization. In low-governance environments, the penalty for extra tools is much higher because local choice quickly turns into permanent fragmentation. In those situations, a stronger bias toward standard platforms is usually warranted.
Vendor strategy should also be considered explicitly. An organization that standardizes on a small number of major platforms gains negotiation leverage, roadmap visibility, and stronger internal expertise, but it also increases concentration risk and dependence on a few vendors’ pricing and product direction. The target state should therefore be deliberate about where concentration is acceptable and where diversification is prudent. This is another reason capability-level choices matter more than blanket rules.
The target state should therefore express not only which platforms are strategic, but why. It should show where standardization is mandatory, where specialization is allowed, and what evidence is required for exceptions. That clarity is what prevents future platform decisions from reopening settled questions every time a new requirement appears.
12.4 Guardrails for Cloud, Data, Integration, Identity, and Security Architecture
A target-state application landscape is sustainable only if it is protected by guardrails. Design principles describe the intent of the landscape. Guardrails translate that intent into architectural constraints that shape future decisions. Without them, new projects, urgent local needs, and vendor sales cycles will gradually pull the estate away from the target state, even if the initial rationalization was well designed.
Cloud guardrails should address where different kinds of applications are expected to run, what hosting models are preferred, and what conditions must be met for exceptions. A practical target state may favor SaaS for commodity capabilities, managed platform services for modern custom workloads, and limited retained infrastructure for specific regulated or operational cases. The key is not to mandate one hosting answer for everything. It is to reduce ad hoc hosting variation and ensure that new decisions align with operational, resilience, and cost expectations.
Data guardrails are equally important. The target state should define authoritative systems for major data domains, expectations for data ownership, and the approved ways data may be shared, copied, or persisted outside source systems. Without this, local reporting marts, spreadsheets, extracts, and side databases reappear quickly. Guardrails should cover master data stewardship, data product ownership where relevant, retention requirements, and the conditions under which local data stores may exist.
Integration guardrails determine how applications are allowed to connect. These rules should discourage uncontrolled point-to-point proliferation, undocumented file transfers, and business-critical logic embedded in fragile scripts. They should encourage standard APIs, managed integration platforms, event-based patterns where appropriate, and explicit ownership of interface contracts. The purpose is not architectural purity. It is to make future change safer and cheaper.
Identity guardrails are one of the most effective controls against unmanaged growth. Every target-state application should align with the organization’s identity provider, access model, privileged access approach, and provisioning standards unless a formally approved exception exists. Applications that cannot support basic identity integration, role control, and auditability should face a high bar for entry into the future estate. This principle is especially important for SaaS adoption, because ease of purchase can otherwise outrun control.
Security guardrails should specify baseline requirements for encryption, logging, monitoring, vulnerability management, backup, recovery, and third-party assessment. These are not details to be bolted on after a product is selected. They are entry conditions for participation in the target landscape. The same is true for privacy and regulatory constraints. If an application cannot meet them within reasonable effort, it should not become part of the strategic estate.
Guardrails work best when they are lightweight, visible, and tied to decision forums the business already uses. A short architecture intake checklist, procurement review triggers, platform approval rules, and exception registers are usually more effective than large policy documents no one reads. The real objective is behavioral: to make it harder for new complexity to enter by default and easier for teams to choose options that align with the target state.
In practical terms, guardrails are what convert the future landscape from a one-time program output into a living management system. They ensure that cloud choices, data choices, integration choices, identity choices, and security choices reinforce the target state instead of slowly undoing it. That is how rationalization stops being a cleanup effort and becomes an enduring discipline.
