Operate or Orchestrate: Deciding the Right Model for Your IT Assets

Every technology leader eventually faces a portfolio question that looks simple on the surface and expensive in practice: do we keep optimizing what we already own, or do we redesign the operating model around a platform? Nike’s Converse dilemma is a useful framework here. Converse is not a “bad asset” just because growth slowed; it is an asset that may be in the wrong mode for its current economics, market position, and management attention. The same logic applies to IT assets, where the real decision is often not whether a tool is useful, but whether it should remain an independently operated node or be folded into a broader platform model.

That distinction matters because IT leaders are under pressure from all sides: reduce cost, improve interoperability, accelerate delivery, and justify every recurring subscription. In other words, this is not just a systems architecture problem; it is an IT asset strategy problem with direct consequences for resource allocation, migration risk, and portfolio returns. The best teams use a decision framework that separates assets worth operating from assets worth orchestrating. They then apply a clear cost-benefit lens to legacy systems, integrations, and future scalability.

Below is a practical, executive-level guide to making that call. We will translate the Nike/Converse portfolio dilemma into an IT decision model that helps you decide when to keep optimizing, when to centralize, and when to migrate to a platform-based operating model. Along the way, we will connect this to automation, governance, and the realities of change management using examples from automation in IT workflows and model-driven incident playbooks.

1. Why the Nike/Converse Dilemma Maps So Well to IT Assets

Portfolio thinking beats isolated optimization

The biggest mistake in IT planning is judging assets one at a time. A ticketing platform, identity provider, data integration layer, CI/CD stack, or endpoint tool may look healthy in isolation while the whole portfolio remains fragmented and costly. Nike’s challenge with Converse is similar: a single brand can be perfectly viable and still be the wrong shape for the current portfolio. In IT, that means a tool may still deliver value even if it no longer belongs in a decentralized operating model.

When leaders think in portfolios, they ask how each asset contributes to shared outcomes such as speed, reliability, governance, and economics. This is the same discipline used in other resource-constrained decisions, including portfolio optimization in financial services and negotiating better terms when demand softens. The logic is consistent: underperforming nodes may need support, but the portfolio itself should be designed for the best system-wide return.

Operate vs orchestrate is really a control question

“Operate” means you optimize an asset as a mostly independent unit. You improve its uptime, tune its licenses, train its users, and make local decisions around performance and ROI. “Orchestrate” means you manage that asset as part of a coordinated platform, with standardized governance, shared data, integration rules, and centralized lifecycle controls. The orchestrated model usually wins when the cost of duplication, fragmentation, or manual coordination becomes greater than the flexibility you lose.

This is why IT leaders should not frame the choice as “centralize everything or decentralize everything.” The better question is where control creates leverage. Some assets should remain nimble and local because they are differentiated or rapidly changing. Others should move into a shared platform because duplication is wasteful and operational risk is rising. For a useful analogy, consider workflow automation: automating local tasks is valuable, but orchestrating the whole process from intake to resolution is what really compounds value.

Converse is the warning against sentimental ownership

Organizations often keep legacy systems alive for emotional reasons disguised as pragmatism. “It still works.” “The users know it.” “Migration is risky.” Those are valid concerns, but they can become a form of portfolio drift. The Nike/Converse framework pushes leaders to ask whether an asset is still winning on its own merits or merely surviving because switching costs feel too high. That is especially relevant in IT, where technical debt accumulates quietly until a tool becomes a hidden tax on every change.

Some assets deserve continued operating investment because they have strategic differentiation. Others should be moved into a platform model because the business wants shared standards, better observability, and easier governance. This is close to the discipline behind choosing a platform in quantum hardware: buyers are not just evaluating features; they are evaluating whether the platform can support future integration, expansion, and control.

2. The Decision Framework: When to Operate, When to Orchestrate

Criterion 1: Is the asset a differentiator or a commodity?

Start by classifying the asset’s strategic role. If a tool or system directly supports a unique business capability, a specialized customer experience, or a proprietary workflow, it may be a differentiator that should stay operated locally. If it mainly provides generic capability—identity, patching, basic reporting, document management, expense processing, or collaboration—it often belongs in an orchestrated model where scale and consistency matter more than local customization.

A good litmus test is this: would two business units independently create materially different value from the same function, or are they just recreating the same wheel? If the answer is “same wheel,” orchestration usually wins. Leaders can sharpen this classification using structured comparison methods similar to the approach in side-by-side value comparisons and future-proofing budgets against price increases.

Criterion 2: What is the cost of fragmentation?

Fragmentation cost is more than licensing overlap. It includes duplicated admin work, inconsistent security posture, training overhead, support sprawl, brittle integrations, and reporting gaps. In many enterprises, these “small” costs are invisible individually but enormous in aggregate. If teams are maintaining five dashboards where one would do, or paying three vendors for the same functional layer, the case for orchestration becomes much stronger.

That said, not every consolidation saves money immediately. Some platforms add upfront implementation costs and create a temporary productivity dip during migration. So the correct analysis is not simple spend reduction; it is total cost of ownership over time, including labor, process friction, and operational risk. This is analogous to evaluating the hidden cost of a cheap camera: sticker price rarely tells the whole story.

Criterion 3: Does the asset require shared governance?

Some tools cannot be left to local autonomy because they affect identity, compliance, auditability, data classification, or incident response. These are natural candidates for orchestration. When governance requirements are high, the cost of inconsistency compounds quickly, and the business pays for it in outages, security exceptions, and audit remediation. In practice, this is why organizations centralize core platforms while allowing edge teams more freedom in adjacent tools.

If you are deciding whether to orchestrate, ask how often the asset touches regulated data, customer records, or privileged access. The more shared the risk, the more valuable standardization becomes. This logic aligns with mobile credential trust decisions, where control, assurance, and policy consistency matter more than convenience alone.

3. Cost Models: How to Compare Operating and Orchestrating

Build a total cost model, not a sticker-price model

Technology leaders sometimes compare only license spend and ignore the operating labor around a tool. That leads to distorted decisions. A local tool may appear cheaper until you count admin hours, user training, duplicate integrations, and support tickets. By contrast, a platform model may look expensive during procurement but produce a lower total cost once process standardization and shared services are included.

Build your model across three buckets: direct cost, coordination cost, and change cost. Direct cost includes subscriptions, infrastructure, and support. Coordination cost includes handoffs, duplicated processes, shadow IT, and governance overhead. Change cost includes the cost of migration, retraining, cutover, and temporary productivity loss. This approach mirrors disciplined purchase analysis in value shopping decisions, where ownership cost matters more than headline discount.

Use a 3-year and 5-year horizon

Many operating models look favorable over six to twelve months but become expensive over a multi-year horizon. Orchestration often needs time to pay back because standardization and integration effort are front-loaded. So compare both a short-term and a medium-term view. If a platform pays back only after 36 months, that may still be appropriate for a stable capability like identity or ITSM; it may be inappropriate for a fast-moving, experimental workflow.

One practical method is to score each asset on expected volatility, integration count, user breadth, and compliance sensitivity. High volatility and low breadth suggest operating. High breadth and high compliance suggest orchestration. For another perspective on balancing near-term and long-term value, see record-low deal analysis, which shows how timing and lifecycle stage affect true value.

Example: a legacy document platform

Suppose a company has three document workflows across legal, finance, and HR. Each team has a different local system, each with unique customizations. On paper, all three tools are “working.” In reality, admins maintain three permission models, three retention policies, and three integration paths into the data warehouse. The operate model preserves autonomy but multiplies complexity. The orchestrate model consolidates them into one platform with role-based access, standardized retention, and shared reporting.

In the first year, the orchestrated model may cost more because of migration and training. By year two or three, it can lower support load, improve compliance, and reduce integration fragility. That is the exact trade-off leaders should quantify in their business case.

4. Portfolio Management: Decide Based on Strategic Fit, Not Habit

Map assets by business criticality and differentiation

A good portfolio map has at least four quadrants: strategic differentiator, operational backbone, specialized exception, and candidate for retirement. Strategic differentiators are often best operated with close business ownership. Operational backbones are usually best orchestrated because standardization creates leverage. Specialized exceptions may remain local for a while, but they should be reviewed often. Retirement candidates are the tools that create more cost than value.

Portfolio management is not just a technology exercise; it is a leadership process that forces trade-offs. You cannot fund everything, integrate everything, or migrate everything at once. Teams that do this well borrow from structured resource allocation methods seen in complex portfolio optimization and from disciplined negotiation tactics when market conditions shift.

Apply the 70/20/10 rule to operating attention

One practical model is to allocate roughly 70% of platform attention to core shared systems, 20% to adjacent optimization, and 10% to experimentation. This keeps the organization stable while preserving room for innovation. If a tool is consuming more than its fair share of attention relative to its business value, it may be over-operated and under-orchestrated. In other words, the asset is getting too much local love and not enough systemic discipline.

This is especially useful in environments with many SaaS tools. Teams often confuse “ownership” with “value creation,” when in fact a mature platform model can reduce the amount of heroic work required from individual teams. That same principle appears in incident playbooks, where standardized process improves response without removing human judgment.

Watch for portfolio drift

Portfolio drift happens when assets survive because nobody has made the case to change them. Over time, the stack becomes a museum of past decisions. Drift is costly because it creates hidden dependencies and makes every new project harder. If you are seeing duplicate capabilities, inconsistent APIs, or recurring data reconciliation work, your portfolio may be telling you it wants orchestration.

To counter drift, review assets on a fixed cadence and ask: has the environment changed, has the usage pattern changed, or has the business strategy changed? If yes, the operating model may need to change too. That mindset echoes the practical skepticism in enterprise AI adoption lessons, where many tools are abandoned because the surrounding workflow was never designed for sustained use.

5. Migration Strategy: Moving From Operate to Orchestrate Without Breaking Things

Start with a coexistence plan

The most successful migrations do not attempt a cliff-edge cutover. They create a coexistence period where both models run in parallel while teams validate data, workflows, and controls. This is essential because platform migrations often expose edge cases that were never documented in the old local model. A coexistence plan reduces operational risk and gives users time to adopt the new path.

Think of the first stage as de-risking the migration, not proving the platform is perfect. The goal is to preserve business continuity while making the new orchestration layer increasingly attractive. This approach is similar to resilient operational change in automation-heavy IT environments, where incremental rollout outperforms a full replacement mindset.

Sequence migrations by dependency, not politics

When moving to a platform model, start with the assets that have the highest dependency value and the lowest business specificity. These are usually the best candidates because they create visible wins without requiring highly bespoke behavior. Save the most specialized workflows for later, when the platform is proven and the migration team has learned the traps.

This sequencing matters because platform credibility is earned through small wins. A successful migration of identity, logging, or service catalog can unlock support for more complex moves later. Leaders who sequence well are often the ones who get the strongest ROI, just as buyers who time their purchases carefully can extract more value from market shifts.

Budget for adoption, not just build

Migration plans fail when they fund engineering but starve adoption. Users need training, documentation, office hours, and migration support. Admin teams need runbooks, rollback plans, and clear escalation paths. If the new platform is harder to use than the old tool, people will route around it, and you will end up with the worst of both models: added cost plus shadow usage.

Strong orchestration requires strong enablement. The migration should be treated like a product launch, not a backend upgrade. For teams that need a template for standardized rollout thinking, the discipline in prompting frameworks and reusable templates is a useful analogy: consistency only scales when people can repeat the process reliably.

6. Where the Platform Model Wins Most Clearly

Identity, access, and policy enforcement

Identity and access management are classic orchestration candidates because the downside of fragmentation is enormous. Multiple local systems create inconsistent access controls, audit complexity, and security blind spots. A shared platform model improves governance, reduces drift, and makes lifecycle events such as onboarding and offboarding much cleaner.

If your organization has ever struggled with permissions sprawl or uncertain access ownership, you already know the value of orchestration. This is one area where “operate locally” usually becomes a false economy. The lesson is reinforced by the seriousness of trusted credentialing and access assurance.

Incident response and observability

Incident tooling is another area where orchestration shines. When logs, alerts, runbooks, and ownership are standardized, teams can respond faster and learn more from each incident. Fragmented observability often creates a false sense of control because each team sees its own data, but no one sees the whole service chain. Orchestration makes cross-team response more reliable and less dependent on tribal knowledge.

That is why model-driven playbooks are so useful: they create repeatability across systems and teams. If you are designing around service health, you should review model-driven incident playbooks and build a shared response model before an outage forces your hand.

Data integration and reporting

Data pipelines almost always benefit from orchestration because one-off point integrations become brittle as the stack grows. A platform model with shared schemas, monitoring, and lineage can dramatically reduce reconciliation work. It also improves executive reporting because decision-makers are no longer comparing apples to oranges across local systems.

Where the data has to feed finance, operations, and compliance, a platform model often becomes the default choice. If you are building a business case for this transition, the framework in replacing paper workflows with data-driven processes is a strong template for proving value.

7. When Operating an Asset Is Still the Right Move

Fast-changing, experimental, or highly specialized use cases

Not every asset should be absorbed into a platform. Some capabilities are still evolving, especially those tied to product experimentation, niche teams, or highly specialized domain work. If the cost of standardization would slow innovation more than it would save money, keep operating the asset locally for now. A local model preserves agility and allows the team to move at the pace of the problem.

This is where leaders must resist the urge to standardize just because standardization feels mature. Maturity is not the same as fit. In some cases, the right answer is to let a high-value local node thrive until the business can see repeated demand patterns.

Low-breadth tools with high user affinity

If a tool is used by a small team and has strong user satisfaction, a platform migration may not justify the effort. The key question is whether local excellence creates broader strategic risk or just local convenience. If the answer is mostly convenience, operating the asset may be entirely rational. Not every good tool needs to become enterprise infrastructure.

This is a useful correction for teams that over-rotate on centralization. Portfolio management is not about flattening every difference. It is about investing where coordination produces leverage. That principle also shows up in consumer decisions such as whether to buy a specialized device for a specific use case or a more flexible general-purpose one.

Temporary solutions with a clear sunset

Sometimes operating the asset locally is the correct bridge strategy because the business is waiting on a larger transformation. In that case, set a sunset date, define the exit criteria, and track the hidden cost of keeping it alive. A temporary local solution becomes dangerous only when it becomes permanent by neglect.

If your stack contains too many “temporary” tools, you likely have a governance problem more than a tooling problem. This is where a structured review cadence prevents drift and keeps the organization honest about whether a node should remain operated or be migrated into a platform model.

8. A Practical Comparison: Operate vs Orchestrate

The table above is the simplest way to explain the model to stakeholders. It makes the trade-offs visible without oversimplifying them. The real question is not which model sounds more advanced; it is which one fits the economics and operating realities of the asset. That mindset is consistent with choosing between managed and unmanaged spend in any resource system.

Pro Tip: If an asset requires the same policy, same reporting, and same integration pattern in multiple teams, it is usually a strong candidate for orchestration. If it needs different rules everywhere, keep it operated until the variance settles.

9. The Executive Checklist Before You Decide

Ask five hard questions

Before you choose operate or orchestrate, answer these questions honestly: Is the asset strategically differentiated? How much does fragmentation cost today? Does the asset touch shared risk or regulated data? What is the true migration cost over three to five years? And who will own adoption after the transition? If you cannot answer these clearly, the decision is probably not ready.

Good leaders do not rush this step. They build the case, test assumptions, and pressure-test the economics. That is the same discipline found in other high-stakes purchase and strategy decisions, from abandoned enterprise AI tools to platform selection in emerging tech.

Use stakeholders to validate, not veto

Stakeholder interviews are valuable, but they should not become a popularity contest. Use them to validate workflow pain, hidden costs, and likely adoption barriers. When you hear “we can’t possibly standardize,” translate that into operational requirements, exceptions, and transition needs. Often the objection is really about change management, not the underlying model.

If you turn stakeholder feedback into design constraints, the decision becomes much more executable. That reduces the risk of a technically elegant migration that fails in practice. For inspiration on structured decision-making, it helps to study how teams make repeatable choices in areas like automation design.

Document the exit criteria

Every operating or orchestrating decision should have a future review date. If you choose operate, document what would trigger a move to orchestration later. If you choose orchestrate, document what would justify reversing course or leaving an exception in place. This keeps the organization from treating today’s answer as permanent law.

The best IT asset strategies are living strategies. They are reviewed as market conditions, business priorities, and technology constraints change. That discipline keeps the portfolio healthy and prevents the kind of accumulated inertia that makes legacy systems hard to untangle.

10. Conclusion: Make the Operating Model Serve the Portfolio, Not the Other Way Around

Nike’s Converse question is not really about shoes, and your IT decisions are not really about tools. Both are portfolio decisions about how much local optimization the system can support before coordination becomes the better economic choice. In IT, the “operate vs orchestrate” decision should be made by looking at strategic differentiation, cost-benefit, governance needs, and migration feasibility together—not separately. When you do that, the right model usually becomes clearer.

Use operate when the asset is specialized, fast-moving, or low-breadth and when local agility matters more than standardization. Use orchestrate when the asset is shared, compliance-sensitive, integration-heavy, or duplicative across teams. And when in doubt, measure the hidden cost of fragmentation before assuming the status quo is cheap. Leaders who manage the portfolio this way build more resilient systems, better resource allocation, and stronger long-term returns.

If your organization is in the middle of this choice, start small: map the top ten recurring tools and systems, assign them to operate or orchestrate, and estimate the three-year cost difference. That one exercise will usually reveal where the real leverage sits. From there, you can move with more confidence, better economics, and far less portfolio drift.

FAQ

Related Reading

• Prompting Frameworks for Engineering Teams - Reusable templates and test harnesses for consistent execution.
• Model-Driven Incident Playbooks - A practical look at standardizing response across operational teams.
• Real-World Applications of Automation in IT Workflows - See where automation creates the biggest operational gains.
• Build a Data-Driven Business Case for Replacing Paper Workflows - A useful template for proving ROI on process change.
• What Quantum Hardware Buyers Should Ask Before Choosing a Platform - A platform-selection mindset that transfers well to IT strategy.