From Qualification to ProductOrder
Telecommunication architectures often struggle not with service activation or network execution, but with the very first step of the lifecycle: translating customer intent into a clean, valid order.
Many transformation programs introduce complexity at this stage by tightly coupling digital channels to backend systems, embedding business rules inside frontends, or overloading orchestration platforms with responsibilities that belong to domain boundaries.
This article explores a pragmatic approach to customer order capture using TM Forum Open APIs as stable integration contracts — focusing on how commercial validation, technical feasibility, and order submission can be implemented without creating architectural bottlenecks.
The discussion builds on the master architecture presented in TM Forum Open APIs Without the Complexity Trap and focuses specifically on the capture layer.
Diagram 1 – Customer Order Capture Flow
Architectural Scope
This article focuses on the commercial entry point of the lifecycle — the transition from customer interaction to standardized product order submission.
Core APIs covered:
- TMF620 — Product Catalog Management
- TMF679 — Product Offering Qualification
- TMF645 — Service Qualification
- TMF622 — Product Ordering Management
These APIs represent the boundary between digital engagement and downstream operational domains.
Key Architectural Principle
TM Forum APIs should act as:
- stable integration contracts
- domain boundaries
- interoperability interfaces
They should NOT:
- define internal data models
- dictate orchestration logic
- force digital channels to mirror backend complexity.
The goal of customer order capture is simple:
Produce a clean, validated ProductOrder representing commercial intent.
Everything else belongs downstream.
Engagement Layer — Digital Channel / BFF
Customer interaction begins in digital channels:
- Web portals
- Mobile applications
- Partner systems
The BFF (Backend-for-Frontend) plays a crucial role:
- Aggregates multiple backend APIs
- Shields frontend from domain complexity
- Maintains UX-specific workflows.
However, a common anti-pattern is turning the BFF into a business logic engine.
Pragmatic rule:
Validation logic lives behind TMF APIs, not inside the channel.
Product Discovery — TMF620 Product Catalog
The lifecycle begins with browsing commercial offerings via TMF620.
Responsibilities:
- Retrieve product offerings
- Resolve bundles and configurations
- Provide structured product metadata.
Architectural pattern:
TMF620 often acts as an API facade over legacy catalog platforms.
Benefits:
- Stable contract for digital channels
- Decoupling from catalog implementation
- Incremental modernization possible.
Important design choice:
The catalog provides information — it does not validate eligibility.
Commercial Qualification — TMF679 Product Offering Qualification
Product Offering Qualification validates commercial constraints:
- Customer eligibility
- Allowed configurations
- Offer compatibility rules.
Typical inputs:
- customerId
- selected offering
- requested characteristics.
Typical outputs:
- qualificationResult (qualified/notQualified)
- validation messages
- adjusted configuration suggestions.
Common complexity trap:
Embedding qualification logic inside order processing.
Pragmatic approach:
Qualification remains a separate validation boundary.
This allows:
- early failure detection
- faster UX feedback
- reduced orchestration complexity.
Technical Feasibility — TMF645 Service Qualification
One of the most important architectural separations is:
Commercial validation ≠ Technical feasibility.
TMF645 handles:
- address validation
- network coverage
- resource availability
- infrastructure constraints.
Why separate?
If technical feasibility is checked only during activation:
- orders fail late
- customer experience suffers
- orchestration becomes complex.
Using TMF645 early:
- prevents invalid orders entering lifecycle
- reduces downstream rework.
Transition Boundary — TMF622 Product Ordering
Once qualification is complete and customer confirms purchase, the digital channel submits a ProductOrder via TMF622.
TMF622 acts as:
The boundary between commercial intent and operational execution.
Responsibilities:
- Capture standardized commercial request
- Provide initial acknowledgement
- Hand ownership to order management domain.
Key design goals:
- ProductOrder payload should be minimal but complete.
- Avoid embedding downstream execution details.
Example conceptual structure:
- orderItem
- productOffering
- customer reference
- requested characteristics
- relatedParty.
Designing a Clean ProductOrder
A pragmatic ProductOrder:
- Represents what the customer wants, not how to execute it.
Avoid:
- technical resource details
- network-specific parameters
- service-level workflows.
These belong to decomposition inside Order Management.
Recommended practices:
- include clear correlation identifiers
- ensure idempotent submission
- keep optional attributes truly optional.
State Management at Capture Stage
Typical lifecycle states after submission:
- acknowledged
- inProgress.
Digital channels should:
- rely on asynchronous updates rather than polling excessively.
- treat TMF622 response as acceptance of intent, not completion.
Common Anti-Patterns
1. Fat BFF
Embedding:
- qualification logic
- catalog rules
- decomposition logic
inside the channel layer.
Result:
- duplicated rules
- inconsistent behavior.
2. TMF-First Internal Modeling
Designing internal microservices directly around TMF schemas.
Result:
- tight coupling
- inflexible evolution.
3. Central Workflow Engine Too Early
Using external BPM tools to orchestrate order capture.
Better:
Simple capture triggers domain-owned orchestration later.
Integration Pattern Summary
Customer Order Capture architecture should:
- Use TMF620 for discovery
- Use TMF679 for commercial validation
- Use TMF645 for technical feasibility
- Submit via TMF622 as standardized boundary.
This separation ensures:
- early validation
- cleaner orchestration downstream
- reduced coupling.
What’s Next
This article focused on capturing commercial intent and producing a clean ProductOrder.
In the next publications, we move inside the Customer Order Management domain and explore:
- Product-to-service decomposition
- State machines vs workflow engines
- Asynchronous orchestration patterns
- Handling partial fulfillment and failure scenarios
- Updating Product Inventory (TMF637) from lifecycle events.