This page stays with details I can share and verify. I’ll add the fuller decisions, collaboration and lessons once I have written them from my own experience.
The customer, commercial details and proprietary implementation information have been intentionally omitted or generalised.
The work
Before anything could be built, the work involved listening carefully, finding the constraints and turning them into something concrete enough to test. I contributed substantially to Swisscom’s proposal for a major enterprise multi-domain service orchestration programme.
The proposal did not become a delivered Swisscom programme. This retrospective is about the engineering and customer-facing solution work—not a claim of procurement success.
Why it was difficult
The customer needed to move from legacy network and service representations towards a more fully modelled next-generation environment. The solution had to connect network-element modelling, service provisioning, migration, inventory, zero-touch installation and operational delivery across multiple technical domains.
The hard part was not producing an isolated architecture diagram. It was translating detailed operational and network requirements into a solution that could be explained, demonstrated and connected to a credible migration and delivery approach.
Where I helped
My work covered:
- orchestration architecture and migration concepts;
- requirements analysis and compliance responses;
- CI/CD and API integration;
- technical demonstrations;
- operational concepts and delivery considerations;
- translating customer requirements into implementable technical options.
I represented Swisscom during a five-day technical dialogue with the customer. The dialogue required moving between detailed railway-network requirements and practical solution concepts around provisioning, inventory, migration, security-zone orchestration and scalable service delivery.
Making the idea tangible
I helped design and demonstrate orchestration concepts involving hundreds of live IP/MPLS services and network-element configurations moving from legacy representations towards a fully modelled network.
The demonstration made the architecture testable as a delivery idea. It raised questions about modelling, interfaces, migration sequence, operational responsibility and the behaviour of the complete service lifecycle.
The translation work
This work required several forms of translation at once:
- customer language into technical requirements;
- network behaviour into orchestration models;
- target architecture into migration steps;
- engineering capability into operational concepts;
- proposal commitments into evidence that could be demonstrated.