IT Applications Transformation
Target Operating Model

CLdN’s IT Applications department has historically focused on in-house software development. The modern reality requires orchestrating a complex ecosystem of SaaS platforms, custom development, system integrations, data platforms, and cloud infrastructure. This page distils the complete transformation blueprint into a Target Operating Model with a practical, hybrid organisational structure.

“The key insight is that the organisation needs to evolve from a ‘development factory’ to a ‘technology orchestrator’ — still building some things, but increasingly integrating, configuring, and governing a complex ecosystem of internal and external systems.”

Current State

What We Have

• Head of IT Applications + Operations Manager
• Several teams led by Team Success Managers
• Teams of Developers, Testers, Functional Analysts
• Teams organised by technology or product (e.g. “Java team,” “SAP team”)
• Scrum methodology

What’s Missing

Current Capacity Allocation

Target Operating Model

The TOM is built on three organisational concepts from Team Topologies, adapted for a mid-size logistics company transitioning from pure development to hybrid orchestration:

The Hybrid Org Chart

CIO’s question: “What does an org chart look like for a hybrid IT applications department? Is there someone between the teams and me? With 2+ delivery managers, a team lead per 1–2 teams, Chris and Gill taking their part, BAs with domain responsibility, and regular BPM/teamleads/DM meetings — should that cover it?”

Recommended Structure

Yes — this can work. The key is a thin management layer between the CIO and the teams, not a heavy hierarchy. Two Delivery Managers provide the orchestration layer; Team Leads provide the technical leadership within teams. Here is the proposed structure:

Head of IT Applications (Peter)
    │
    ├── Tom (Delivery Manager 1)  ── Owns delivery cadence, cross-team dependencies,
    │       │                        stakeholder reporting, portfolio view
    │       ├── Adam (Team Lead A) ── Stream Team: Shipping & Vessel Ops
    │       │       └── BA (domain: Shipping) + Devs + Testers
    │       │
    │       ├── Dries (Team Lead B) ── Stream Team: Ports & Terminal
    │       │       └── BA (domain: Ports/TOS) + Devs + Testers
    │       │
    │       └── Team Lead C [To be hired] ── Stream Team: Finance & Reporting
    │               └── BA (domain: Finance) + Devs + Testers
    │
    ├── Delivery Manager 2 [To be hired]  ── Same role, second cluster of teams
    │       │
    │       ├── Team Lead D [To be hired] ── Stream Team: Cargo & D2D
    │       │       └── BA (domain: Cargo/Customs) + Devs + Testers
    │       │
    │       ├── Team Lead E [To be hired] ── Stream Team: Customer & CRM
    │       │       └── BA (domain: Customer) + Devs + Testers
    │       │
    │       └── Team Lead F [To be hired] ── Stream Team: HR & Internal Ops
    │               └── BA (domain: HR/Internal) + Devs + Testers
    │
    ├── Chris ──────────────── Support & Service Desk
    │       └── Service Desk, Incident Management, L1/L2 Support
    │
    ├── Gill ───────────────── Data & Analytics
    │       └── Data Engineering, Reporting, Analytics, Data Governance
    │
    ├── Platform Engineering [To be hired]
    │       └── Infrastructure, DevOps, CI/CD, Integration Platform
    │
    └── Joan ───────────────── Advisory to CIO (Peter)
            └── IT Strategy, Operational Excellence, Transformation

Green = new roles   Blue = existing/evolved roles   Gold dashed = shared/virtual roles

Key Design Decisions

Governance & Meeting Cadence

Regular touchpoints keep the hybrid model coherent without creating bureaucracy:

Key Role Definitions

Stream-Aligned Teams for CLdN

Instead of organising by technology (Java team, .NET team), organise by business domain:

Data & AI Maturity Path

Don’t skip stages. Most organisations fail by jumping to AI without data foundations.

Transition Principles

1. Invest in architecture first — hire an Enterprise Architect in month 1–2. They design everything else and prevent costly integration mistakes.
2. Start with pilots, not big bang — prove the model with 1–2 stream teams before reorganising the entire department.
3. Evolve roles, don’t replace people — developers, testers, and functional analysts are valuable. Evolve their roles into the new structure.
4. Data before AI — get to 90%+ data quality before heavy AI investment.
5. Hybrid delivery modes — Product mode (Scrum/Kanban) for ongoing work, Project mode for large SaaS rollouts, BAU mode for vendor management.
6. Business engagement from day 1 — Product Owners from the business side, not appointed from IT.
7. Build vendor management muscle — SaaS relationships need active management, not just procurement.

Source Documents

The complete transformation framework across three documents:

• Blueprint — Complete implementation framework: current state, future vision, org structure, roles, roadmap
• Deep Dives — Detailed exploration of stream-aligned teams, platform teams, and architecture function
• Appendices — Comprehensive role descriptions, job descriptions, and detailed specifications