Technology and data are no longer “IT topics.” In a target operating model, they are core design elements. But many TOM efforts either:
- Treat technology as a black box (“IT will figure it out”), or
- Dive into tools and architectures at a level of detail that business leaders cannot (and should not) manage.
The goal of this chapter is to keep the technology and data discussion at the right altitude for an executive team: precise enough to guide major bets and constraints, but framed in business terms and anchored in your value streams and operating model choices.
We will cover:
- How to link technology choices directly to value streams and journeys
- What you need to understand about core systems, platforms, and integration
- How to define data ownership, governance, and analytics priorities
- How to work effectively with IT, architecture, and security as partners in TOM design
8.1 Linking Technology Choices to Value Streams and Journeys
The most common failure pattern is starting the tech discussion from tools and platforms: CRM, ERP, RPA, data lake, AI, and so on. The TOM approach reverses this. You start from value streams and customer promises and then ask, “What technology do we need to make this way of working possible?”
For each priority value stream (e.g., “Lead to Cash”, “Order to Delivery”, “Incident to Resolution”), walk through a simple sequence:
1. Restate the customer promises and performance goals
For example, in “Order to Delivery” you might have:
- Confirm availability in real time at order capture.
- Give customers a reliable delivery window and hit it 98% of the time.
- Provide proactive alerts on delays with self-serve options.
- Confirm availability in real time at order capture.
2. Identify the key technology-enabled capabilities
For each promise, think in terms of what the system must do, not vendor names:
- Real-time inventory visibility across locations.
- Order capture that validates feasibility at the point of sale.
- Workflow orchestration across warehouse, transport, and customer communication.
- Event tracking and alerts for exceptions (delays, stock-outs, failed payments).
3. Locate those capabilities in your architecture
The same business outcome can often be enabled in multiple ways. You want to know:
- Which existing systems already support some of this capability.
- Where there are clear gaps that require new components or major upgrades.
- Where current fragmentation (e.g., three order entry tools) is the real problem.
4. Translate capabilities into technology requirements at TOM level
At TOM altitude, requirements might sound like:
- “A single order management capability that covers all sales channels.”
- “A workflow layer that routes, prioritizes, and tracks all customer incidents end-to-end.”
- “Shared customer profile accessible by all front-line systems.”
5. You do not yet decide the specific product or detailed specification; you define what must exist to support the operating model.
6. Include non-functional requirements that matter to operations
Performance, availability, and security are not “IT-only” topics. For each value stream, you should be explicit about:
- Required uptime (e.g., 24/7 vs. business hours).
- Tolerable response times (seconds vs. minutes vs. hours).
- Regulatory or security constraints (e.g., data residency, encryption, segregation).
7. These parameters drive cost and complexity; executives must consciously trade them off.
If you do this well, you end up with a technology capability map by value stream, rather than an abstract inventory of systems. This map becomes a powerful guide for:
- Prioritizing technology investments (where the capability gaps are largest)
- Simplifying overlapping tools (where multiple systems do similar jobs)
- Sequencing the tech roadmap alongside TOM waves
The central mental shift is this: technology is not a separate workstream. It is part of the design of each value stream and journey.
8.2 Core Systems, Platforms, and Integration Patterns
From an operating model perspective, you don’t need to be an architect, but you do need to understand a few structural ideas:
- What your core systems are
- Where platforms should provide shared capabilities
- How those systems are connected (integration patterns)
Think of your landscape in layers:
- Systems of record
These are the core transactional engines that “own” key data and legally relevant transactions: ERP, core banking systems, policy administration, billing, HR/payroll.
In TOM terms, you care about:- Which value streams they underpin.
- How hard they are to change.
- Where you are running multiple cores for similar purposes (a frequent source of cost and complexity).
- Systems of engagement
These are the front doors for customers and employees: websites, mobile apps, CRM, contact center tools, branch or store systems, partner portals.
TOM-relevant questions include:- Do customers and front-line staff see a coherent experience across channels?
- Are engagement systems tightly or loosely coupled to back-end cores?
- How easy is it to change customer journeys without rewriting the core?
- Systems of intelligence
These cover reporting, analytics platforms, data warehouses, data lakes, and AI/ML services.
You care about:- Whether they can access clean, timely data from the key value streams.
- Whether insights are embedded into workflows (e.g., next-best-action in CRM) or just in dashboards no one uses.
- Integration and workflow layer
This is how everything talks to everything else: APIs, integration platforms, event buses, workflow tools.
It matters because:- Point-to-point integrations (“spaghetti interfaces”) make every TOM change slow and risky.
- A clean integration layer allows you to change one part of the operating model (e.g., a channel front end) without breaking others.
In TOM design, your job is to set direction and boundaries, not to debate ESB vs. API gateway products. Examples of TOM-level choices:
- “We will move to a single global CRM platform for all segments over three years.”
- “We will treat our ERP as a stable core and build a workflow and API layer around it to support journey redesign.”
- “We will converge onto two regional core systems from the current five, and design future products on top of those cores.”
On integration, you mainly need to insist on coherence:
- Avoid new point-to-point integrations unless there is no alternative.
- Favor API-based or event-driven patterns that allow decoupling of front-end and back-end.
- Ensure that integration standards are part of the TOM guardrails—so every new initiative doesn’t reinvent them.
What you are fighting here is technical debt as operating friction. Every extra core, every custom point-to-point interface, every one-off local system makes it harder to implement TOM changes. Your design choices should progressively reduce that debt, even if you cannot fix everything immediately.
8.3 Data Ownership, Governance, and Analytics Use Cases
Data is often everyone’s problem and nobody’s job. The TOM needs to change that. From an operating model viewpoint, you should focus on three things:
- Data domains and ownership
- Lightweight but effective governance
- A sharp set of analytics use cases that matter for your value streams
Data domains and ownership
Instead of treating data as an amorphous lake, define a small number of data domains that matter most. Typical examples:
- Customer and party data
- Product and services data
- Order, contract, or policy data
- Asset or inventory data
- Financial and risk data
For each domain, answer:
- Who is the business owner of this domain? (Not IT—someone in the business who cares about how this data is defined and used.)
- What systems are the current and future systems of record?
- Where does this data need to be consistent enterprise-wide, and where can it vary?
This links directly back to your organization design (Chapter 6). If you declare “single customer view” as a pillar of the TOM, someone must own the concept of “customer” and be accountable for its quality and usage.
Data governance in TOM terms
Governance often dies in jargon. Keep it practical and minimal:
- Definitions: A small business glossary for key metrics and entities, so people stop arguing about what “active customer” or “margin” means.
- Quality rules: A handful of critical rules per domain (e.g., customer records must have valid identifiers, duplicate rate below X%, certain fields mandatory for onboarding).
- Issue management: A simple process to log, prioritize, and resolve significant data issues that affect operations or reporting.
- Access and security: Clear policies on who can see or change what data, embedded into systems (role-based access), not just documents.
From a TOM standpoint, ask:
- In which value streams does data quality directly hit customers, cost, or risk?
- Which errors are most painful (e.g., wrong address, incorrect limits, inconsistent product attributes)?
- Which minimum governance mechanisms would notice and correct these issues early?
You are designing data governance as part of how work happens, not as an extra layer of bureaucracy.
Analytics use cases
A common trap is to launch an “advanced analytics program” in parallel to TOM, producing proofs of concept that never embed into operations. Instead, let your TOM drive a focused analytics portfolio aligned to value streams.
For each priority value stream, identify:
- A few high-value decisions that would truly benefit from better prediction or optimization (e.g., lead scoring, pricing, allocation, fraud detection, maintenance scheduling).
- The minimum data and capabilities required to support those decisions.
- How insights will be consumed: in dashboards, in workflow tools, or embedded in system logic.
Examples:
- In “Lead to Cash”, analytics might support:
- Prioritizing leads for sales follow-up.
- Suggesting cross-sell products at quote time.
- In “Incident to Resolution”, analytics might:
- Predict which incidents are likely to breach SLAs.
- Recommend the best next action or resolution path.
For each use case, define:
- The business owner (not just “the data team”).
- The operational metric it should move (e.g., conversion rate, churn, days outstanding).
- How you will know it is being used (e.g., adoption metrics, decision changes).
In TOM language, you are saying: “Our operating model relies on a small number of analytics use cases being industrialized and embedded, not on generic ‘AI capability’ existing somewhere.”
8.4 Working Effectively with IT, Architecture, and Security Teams
Even a well-framed TOM can stall if the relationship with IT, architecture, and security is adversarial or fragmented. The operating model depends on how well the business and these teams work together.
Think of IT and architecture as co-designers of the TOM, not recipients of requirements. The practical ways to make that real:
1. Bring IT and architecture into TOM design early
Do not design an “ideal” TOM and then hand it off to IT to “implement somehow.” Instead:
- Involve senior IT, architecture, and security leaders in the TOM steering group.
- Include solution architects or platform leads in value stream design sessions.
- Ask them explicitly:
- Where are the hard constraints we must respect?
- Where are the biggest simplification opportunities if we make the right TOM choices?
This reduces later surprises (“that will take three years and €X million”) and surfaces creative options earlier.
2. Brief IT in outcomes and capabilities, not just features
Avoid requirement lists that read like shopping catalogs. For each TOM initiative or journey redesign, express:
- The business outcome (e.g., “reduce onboarding time from 10 days to 2”).
- The operating principles (e.g., “single data capture, straight-through processing for low-risk cases”).
- The capability needs (e.g., “a workflow that can route approvals based on rules; a single screen for front-line staff; integration to KYC and credit systems”).
Then let IT and architecture propose options within your cost, time, and risk envelope.
3. Respect architecture and security as value protectors, not blockers
Enterprise architects and security teams often get labeled as “the people who say no.” In TOM design, reframe their role:
- Architecture protects you from fragmentation and future pain by enforcing standards and patterns.
- Security protects you from events that can destroy trust and value in a day.
Practically:
- Agree on a small set of architecture and security guardrails upfront (e.g., cloud strategy, approved integration patterns, security classifications).
- Use architecture and security reviews as design support, not last-minute approvals.
- Expect them to challenge “quick and dirty” local solutions that undermine the enterprise TOM.
In return, they must also:
- Be transparent about which rules are hard (e.g., regulatory, contractual) and which are preferences.
- Provide pragmatic options, not just red flags.
4. Use cross-functional delivery models where it matters
For major TOM changes, consider using cross-functional squads aligned to value streams:
- Each squad has business, operations, IT, data, and risk participants.
- They own delivery of a specific journey or capability end-to-end.
- They work iteratively, delivering incremental improvements rather than waiting for a big-bang go-live.
From an executive standpoint, this means:
- Funding and empowering stable teams, not just projects.
- Judging them on business outcomes, not only on “on time, on budget.”
5. Be explicit about trade-offs—and decide them at the right level
Some TOM-tech decisions involve genuine trade-offs:
- Speed vs. robustness (e.g., quick customization vs. staying on a standard platform).
- Local fit vs. global consistency (e.g., country-specific solution vs. global template).
- Short-term cost vs. long-term technical debt.
IT and architecture can lay out the options and implications, but business leaders must own the trade-offs. A practical habit:
- For each major design divergence from standards, require:
- A short case: benefit, risk, and technical debt impact.
- A clear approver at executive level.
This prevents “shadow TOMs” emerging through one-off exceptions.
If you hold technology, data, and architecture at this level—anchored in value streams, expressed as capabilities, governed by clear guardrails, and co-designed with IT—you avoid both extremes: naive “IT will handle it” thinking and overwhelming technical detail.
