Why the future of systems integration may depend less on choosing the right delivery model and more on connecting business understanding, reusable capabilities and lifecycle ownership.
The ICT industry has been debating the transition from project-based delivery to product- and service-oriented business models for years.
The arguments are familiar. Projects are difficult to scale. Products offer repeatability. Services create recurring revenue and longer-term customer relationships.
But is this really a choice between three competing models?
I believe the reality is more complex.
As digital environments become increasingly sophisticated, the demand for customization, integration and industry-specific solutions is not disappearing. If anything, AI, data platforms, hybrid infrastructures and legacy modernization are creating new forms of complexity.
At the same time, technology providers face growing pressure to deliver faster, reuse existing capabilities and demonstrate measurable business value.
The real challenge is not choosing between projects, products and services. It is learning how to make them reinforce each other.
The hidden risk in systems integration
There is one particular risk I believe deserves more attention:
The greatest danger is not that a systems integrator delivers too many projects. It is that every project starts from scratch, while every product is developed and brought to market in isolation.
The first approach prevents organizations from accumulating reusable intellectual capital. Knowledge remains embedded in individual projects, teams and customer environments.
The second creates fragmented portfolios, duplicated investments and products that may struggle to achieve sufficient scale.
Interestingly, international research supports this concern.
A 2025 HFS Research study, conducted with Unqork among 123 large enterprises, found that only about one-third of code was being reused, while roughly two-thirds was rebuilt. Furthermore, 58% of respondents considered the traditional systems integration model unsustainable over the following five years.
These findings should not be interpreted as evidence that custom development is becoming obsolete.
Rather, they suggest that the economics of repeatedly rebuilding similar capabilities are becoming increasingly difficult to justify.
Customization is not the enemy of standardization
One of the most interesting developments in enterprise technology is the apparent return of customization.
Standard platforms, cloud services and AI technologies are becoming more accessible. Yet the business environments in which they must operate remain highly specific.
A financial institution, an energy company and a healthcare provider may use similar AI technologies, but their processes, data structures, regulatory obligations and operational priorities differ significantly.
This creates an important distinction.
What should be standardized is not necessarily the customer solution, but the capabilities used to build it.
Common technology platforms, integration patterns, security controls and reusable components can coexist with highly customized business solutions.
In fact, standardization at the capability level may be precisely what makes economically viable customization possible.
Research from Google’s DORA program reinforces the potential value of platform engineering while also highlighting its limitations. Shared platforms can improve productivity and organizational performance, but poorly designed platform models may introduce delivery bottlenecks and operational instability.
Standardization therefore needs to enable flexibility rather than constrain it.
Technology Product Ownership: connecting horizontal and vertical capabilities
This leads to an organizational question.
How should a systems integrator manage reusable technology capabilities while maintaining a deep understanding of customer-specific business requirements?
One possible answer is a two-dimensional Technology Product Owner (TPO) model.
Horizontal TPOs would focus on developing and managing reusable technological capabilities across the portfolio.
These could include Data & AI, application development, integration platforms, cybersecurity and other shared technology domains.
Their responsibility would extend beyond technical expertise to capability roadmaps, architectural consistency, reuse and lifecycle management.
Vertical TPOs, meanwhile, would focus on understanding business challenges within specific industries, such as healthcare, energy and defence.
They would translate industry requirements into solution concepts, identify opportunities and combine horizontal capabilities into customer-relevant offerings.
The real value would emerge where these two dimensions intersect.
Horizontal capabilities would provide technological depth and scalability. Vertical capabilities would provide business relevance and differentiation.
Projects would become an important source of learning for both.
Not every project needs to generate a new product. But every significant project should create an opportunity to identify reusable knowledge, components or solution patterns.
Importantly, this TPO structure is a proposed operating model, not an established universal industry standard. Its effectiveness would depend on clear decision rights, investment ownership and collaboration with sales, architecture and delivery teams.
From projects to services: a natural evolution
There is another dimension to consider.
Many systems integration projects do not reach the end of their economic life when the implementation is completed.
A successfully delivered application, data platform or AI solution typically requires ongoing operation, optimization, adaptation and further development.
In this sense, the transition from project delivery to continuous services is not necessarily a change of business model imposed from outside.
It can be a natural continuation of the original customer relationship.
The project establishes a capability. The service maintains and evolves it. New business requirements generate further development.
This creates a continuous value cycle rather than a sequence of disconnected transactions.
However, not every project should automatically become a managed service. The appropriate model depends on customer needs, operating responsibilities, commercial viability and the expected pace of change.
The objective should be lifecycle continuity, not service conversion at any cost.
Do project managers and service managers need new roles?
This evolution raises an important question about traditional organizational responsibilities.
Project Managers (PMs) have historically been responsible for delivering agreed scope within defined time, cost and quality constraints.
Service Managers have primarily focused on operational continuity, service levels, performance and customer satisfaction.
Both roles remain essential.
But what happens when business value increasingly depends on continuous development after implementation?
Should a Project Manager’s responsibility end with formal project acceptance?
Should a Service Manager’s role remain primarily focused on SLA compliance and operational performance?
Or should both roles become more closely connected through shared accountability for the customer’s business outcomes?
The Project Management Institute has already moved towards a broader definition of project success, emphasizing delivered value rather than execution performance alone.
This does not necessarily mean merging the two roles.
It may instead require redefining their interfaces, responsibilities and success metrics.
A Project Manager could remain accountable for successful implementation while ensuring operational readiness and measurable business outcomes.
A Service Manager could increasingly become responsible not only for service stability but also for identifying improvement opportunities and coordinating continuous evolution.
The TPO would provide technological and product direction across both phases.
Yet one question remains:
If the TPO owns technological capabilities, the PM owns delivery and the Service Manager owns operations, who owns the business outcome promised to the customer?
This may be one of the most important governance questions facing modern systems integrators.
Towards an integrated value creation model
The future of systems integration is unlikely to be defined by the disappearance of projects or the universal adoption of product-based business models.
Instead, I expect a more integrated approach to emerge.
Projects will remain essential for addressing unique business challenges and delivering complex transformations.
Products and reusable capabilities will enable scale, consistency and economic efficiency.
Services will provide continuity, operational responsibility and ongoing improvement.
The competitive advantage will come from connecting all three.
AI may accelerate this transformation by reducing the effort required for certain development activities. But it also makes architectural discipline, governance and reusable capabilities even more important.
Ultimately, the systems integrator of the future may be judged less by the number of projects delivered or products launched, and more by its ability to turn individual customer engagements into sustainable, evolving business value.
Perhaps the real transformation is not from projects to products or services, but from delivering technology to continuously creating business value.
Selected research and further reading
- HFS Research / Unqork (2025) — Escape the Code-Heavy Models Inflating Tech Debt. Research on technical debt, reuse and the sustainability of traditional systems integration models.
https://www.hfsresearch.com/research/escape-code-inflating-debt/ - Google Cloud / DORA (2024) — Accelerate State of DevOps Report. Research on platform engineering, software delivery performance and organizational effectiveness.
https://dora.dev/research/2024/dora-report/ - Project Management Institute (2025) — Maximizing Project Success. Research on moving beyond delivery metrics towards stakeholder value and business outcomes.
https://www.pmi.org/learning/thought-leadership/project-success - McKinsey & Company (2024) — Tech Services and Generative AI: Plotting the Necessary Reinvention. Analysis of the changing business models and value propositions of technology services providers.
https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/tech-services-and-generative-ai-plotting-the-necessary-reinvention - Zheng, Z. & Zwikael, O. (2025) — From Outputs to Outcomes: Meeting a Threshold of Short-Term Project Management Success as a Necessary Condition for Achieving Long-Term Impact. International Journal of Project Management.
https://doi.org/10.1016/j.ijproman.2025.102789
Leave a Reply