From Enterprise Relationships to Technology Portfolios: A New Strategy for Indian IT
1. Indian IT Does Not Need Another Crisis Response
For much of its history, the Indian IT industry has demonstrated a remarkable ability to respond to technological and market disruptions. The industry has repeatedly adjusted its service offerings, acquired new capabilities, retrained employees, entered new technology domains, and changed its delivery models as the global technology landscape evolved. This adaptability has been one of its greatest strengths.
But adaptability can become a weakness if it is reduced to a succession of reactions.
The technological environment facing IT companies today is changing at a pace and with a breadth that makes repeated, crisis-driven adaptation increasingly risky. Artificial intelligence is only the most visible part of this change. Computing architectures are evolving, chips and chiplets are changing, AI models are proliferating, enterprise software is being transformed, edge computing is expanding, data-centre architectures are becoming more specialised, and new forms of software and machine intelligence are emerging. At the same time, the commercial environment is changing: enterprises are building their own technology capabilities, GCCs are expanding, labour mobility is becoming politically more contested in some markets, and clients are becoming more demanding about the value they receive from technology expenditure.
An IT company can respond to each development as it appears. It can create another practice, sign another partnership, retrain another cohort, acquire another specialist company, or restructure another delivery unit. But there is a limit to how many such adjustments an organisation can absorb while retaining strategic coherence.
There is a simple way of thinking about the problem. A boatman cannot realistically measure the size and danger of every large tide before deciding how to respond to it. If the boat is designed only for calm water, every major tide becomes a crisis. A more durable strategy is to build a boat capable of handling different tides before they arrive.
Indian IT therefore needs to think beyond its 'ability' to respond to technological disruption. It needs to build an organisational structure that can absorb technological disruption.
This does not mean attempting to predict which model company, semiconductor architecture, cloud provider, data-centre design, or software platform will dominate the future. Nor does it mean that IT companies should try to own every layer of the technology stack. Such technological autarky would be both prohibitively expensive and strategically unnecessary.
There is, however, a potentially powerful alternative.
Indian IT companies already possess an extraordinary downstream asset: decades of relationships with enterprises across industries and geographies. They have accumulated knowledge of enterprise processes, industries, legacy systems, technology requirements, procurement structures, and organisational realities. Rather than treating this downstream position simply as the market in which their services are sold, they could use it as a lever for building a much broader technological capability upstream.
The proposition of this article is therefore straightforward, although its implications are substantial:
Indian IT companies should retain and deepen their enterprise relationships while deliberately building diversified upstream technology partner portfolios across data infrastructure, compute, chips and chiplets, software, AI models, agents, enterprise platforms, edge technologies, and other enabling technologies.
The objective would not be to own these technologies, nor to become dependent upon any particular provider. It would be to create technological optionality: the ability to combine, substitute, experiment with, and continuously reconfigure technologies as enterprise requirements and the technology frontier change.
This could allow Indian IT to move from a business model centred primarily on the deployment of human expertise towards one in which people, technology partnerships, infrastructure access, engineering capability, and accumulated enterprise knowledge operate together as a continuously evolving delivery system.
The question, therefore, is not whether Indian IT should become an AI company. It is whether Indian IT can use what it already does exceptionally well—building and sustaining enterprise relationships—to construct a more resilient, more technologically plural, and ultimately more product-oriented business model for the decades ahead.
2. Start With What Indian IT Already Has: The Enterprise Relationship
The starting point for this strategy should not be a technology that Indian IT does not yet possess. It should be an asset that the industry has spent decades building: its relationships with enterprises.
The largest Indian IT companies are embedded in the technology and organisational architectures of businesses across the world. Their relationships with major banks, manufacturers, retailers, telecommunications companies, energy companies, healthcare organisations, governments, and other institutions have often lasted for decades. These are not simply commercial relationships in which one party supplies software and the other pays for it. They involve accumulated knowledge of how organisations function: their processes, systems, data, regulatory constraints, technology estates, procurement practices, organisational structures, and, importantly, the problems that repeatedly resist technological solutions.
That accumulated knowledge has economic value.
Yet the conventional IT-services model has tended to treat the enterprise relationship primarily as a downstream channel for deploying people and technologies. The client has a problem; the IT company supplies consultants and engineers; a technology is implemented; the project is completed; and the relationship moves on to the next requirement. Even when the relationship becomes long-term, the underlying logic can remain centred on the deployment of human capacity.
The changing technology environment creates an opportunity to use the relationship differently.
An IT company that has worked with hundreds of enterprises in a particular industry is in a privileged position to see patterns that individual technology vendors may not see. A semiconductor company understands its chips. A model company understands its models. An enterprise-software company understands its platform. A data-centre operator understands its infrastructure. But an IT company working across many enterprises can potentially see how all these technologies interact with actual organisational requirements.
That is a distinctive form of knowledge.
Consider a manufacturing enterprise. Its requirement may not be for an AI model in isolation. It may need a combination of enterprise software, industrial software, machine-vision capability, edge computing, specialised accelerators, central compute, cybersecurity, data management, and human oversight. The appropriate combination will depend upon the production process, existing systems, regulatory requirements, latency requirements, cost constraints, and the organisation's own capabilities.
An IT company that already understands the enterprise is unusually well placed to understand that combination.
This suggests a strategic inversion.
Instead of asking only:
What technologies can we sell to our enterprise clients?
the IT company could increasingly ask:
What technologies will our enterprise clients need, and which relationships should we build upstream so that we can assemble those technologies into better solutions for them?
That is a different conception of the enterprise relationship. The relationship becomes not merely a source of revenue, but a source of demand intelligence.
Demand intelligence can then shape the company's technology strategy. If an IT company identifies recurring requirements among its automotive clients, for example, it can seek upstream relationships that enable it to address those requirements repeatedly and more effectively. If it sees common requirements across banks, pharmaceutical companies, logistics operators, or telecommunications firms, it can build corresponding technology capabilities around them.
The downstream relationship thus becomes the foundation for upstream expansion.
This is important because the strategy does not require Indian IT companies to guess where technology is going. They can begin from something they already know: what their clients are trying to accomplish. They can then build relationships with technology providers that help them accomplish those objectives.
The result could eventually be a virtuous cycle. Enterprise relationships generate knowledge of demand; that knowledge informs technology partnerships; those partnerships expand the technologies available to serve clients; deployments generate further organisational learning; repeated solutions can become platforms and products; and better products strengthen the enterprise relationship.
The strategic objective, therefore, is not to move away from the enterprise. It is precisely the opposite.
Indian IT should hold on to its downstream strength—and use that strength to reach upstream.
3. The Strategic Inversion: Build Upstream Relationships
If the enterprise relationship is Indian IT's principal downstream asset, the next question is simple: why should the industry not use the same strategic energy to build relationships upstream?
Indian IT companies have spent decades learning how to establish trust with enterprises, understand their requirements, work across their technology environments, and sustain relationships through successive generations of technology. There is no obvious reason why a comparable relationship-building effort cannot be directed towards the companies producing the technologies on which those enterprises will increasingly depend.
This does not mean that every IT company should attempt to become a semiconductor company, a foundation-model company, a cloud provider, or a data-centre operator. Nor does it mean acquiring upstream companies simply to bring their technologies inside the corporate boundary. The more interesting possibility is strategic partnership without technological ownership.
The concept proposed here is an upstream technology partner portfolio: a deliberately assembled set of strategic relationships across several layers of the technology ecosystem.
Such a portfolio could include partnerships with:
- data-infrastructure and data-centre companies;
- semiconductor and chiplet companies;
- accelerator and compute-system providers;
- cloud providers;
- AI model and AI software companies;
- enterprise-software companies;
- agent platforms and specialist AI companies;
- networking and cybersecurity companies;
- edge-computing and industrial-AI companies;
- and other specialised technology providers.
The word portfolio is important here. The objective is not to identify one technology provider and make it the technological foundation of the company's future. It is to develop sufficient relationships across the technology ecosystem to give the IT company choices.
Nor would every relationship need to have the same character. Some could involve licensing. Others could involve preferential access, long-term procurement, joint development, co-investment, technology integration, managed infrastructure, or commercialisation arrangements. The appropriate relationship would depend upon the technology and the strategic importance of the capability.
The underlying principle is therefore not ownership but access combined with architectural knowledge.
This would also change the nature of the relationship between an IT company and an upstream technology provider. Instead of simply purchasing a technology and passing it on to a client, the IT company could bring something valuable of its own: a large and diverse enterprise demand base.
An AI company may have a powerful model but limited access to the operational complexity of thousands of enterprises. A chip company may have a highly capable accelerator but need workloads at scale. A data-centre company may have substantial compute capacity but need sustained demand. An enterprise-software company may have a sophisticated platform but need deeper integration into particular industries.
An IT company can potentially connect these capabilities to actual enterprise requirements.
This creates the possibility of co-development. The IT company could identify a recurring requirement among its clients, bring that requirement to an upstream technology partner, and work with it to adapt the technology, architecture, deployment model, or commercial proposition. The resulting solution could then be deployed across a larger group of enterprises.
The IT company would consequently become more than a reseller or systems integrator. It could become a technology-demand aggregator and solution architect.
This is particularly important because the technology environment is becoming too diverse for a single supplier to provide everything an enterprise may need. The future enterprise AI environment is unlikely to consist of one model, one agent, one accelerator, one software platform, and one infrastructure configuration. It is more likely to contain combinations of technologies from multiple providers.
That fragmentation could threaten the traditional intermediary role of IT companies. But it could also strengthen it.
If enterprises increasingly face a bewildering choice of technologies, an IT company that can evaluate, combine, integrate, operate, and assure those technologies becomes more valuable—not less.
The strategic inversion is therefore this:
Indian IT should not respond to technological fragmentation by trying to eliminate it. It should learn to orchestrate it.
Its downstream enterprise relationships provide the demand intelligence. Its upstream technology partner portfolio provides the technological choices. The strategic capability lies in connecting the two.
4. From Risk Concentration to Technological Optionality
Building an upstream technology partner portfolio, however, is not simply a matter of establishing as many partnerships as possible. Its strategic purpose is to spread technological risk.
This is particularly important because the technologies on which AI-enabled enterprise systems will depend are not static. The semiconductor industry is a conspicuous example. Chip companies are continuously changing architectures, packaging technologies, memory configurations, interconnects, and the balance between general-purpose and specialised compute. Chiplets are making systems increasingly modular, while rack-scale architectures are making the distinction between an individual chip and the larger computing system increasingly blurred. AMD, for example, is combining chiplets, advanced packaging, high-bandwidth memory, interconnects, and rack-scale systems in its latest AI architecture, while Intel is explicitly developing AI systems around heterogeneous compute, advanced packaging, and open chiplet interconnects.
This creates an obvious risk for an IT company that commits too heavily to one computational trajectory. A large data centre built around a particular generation of hardware may remain physically useful, but the economics and capabilities of the technology inside it can change substantially. Even within a single supplier's ecosystem, the optimal configuration can evolve as workloads change. NVIDIA's own architecture, for example, increasingly encompasses not merely GPUs but CPUs, networking, interconnects, software, and integrated AI-factory systems.
The same problem, however, extends well beyond chips.
An IT company could become dependent upon a particular cloud architecture, only to find that another configuration becomes more economical or better suited to a new class of workload. It could build an offering around an AI software platform whose strategic direction subsequently changes. It could become deeply embedded in one enterprise-software ecosystem and find substitution increasingly difficult. It could establish its AI services around one model provider whose commercial terms, technical roadmap, or enterprise strategy later changes. Even data-centre infrastructure itself is evolving: power and cooling requirements, rack architectures, networking, memory, storage, and the balance between centralised and edge computing can all change as workloads evolve.
The problem, therefore, is not simply chip lock-in. It is technological concentration across the stack.
That makes diversification qualitatively different from ordinary vendor management. The objective should not be to maintain a list of alternative suppliers merely to negotiate better prices. It should be to preserve the ability to change the technological composition of an offering without having to reinvent the offering itself.
This is where an upstream technology partner portfolio creates what can be called technological optionality.
The portfolio is the collection of relationships. Optionality is what those relationships enable the IT company to do.
An IT company with meaningful optionality could, for example, combine different classes of accelerators with different models, software platforms, and infrastructure configurations according to the workload. It could use one architecture for large-scale training, another for inference, another for an edge application, and a different model or software stack where the economics or regulatory requirements justify it. It could also shift between infrastructure providers or configurations as enterprise requirements, technology performance, and costs change.
This does not mean that every enterprise solution should contain technologies from multiple vendors. Sometimes a tightly integrated stack from one provider will be the best answer. The strategic point is that the IT company should choose that integration rather than be trapped by it.
This is particularly important as AI systems become increasingly co-designed. A model company may work closely with a chip company; a chip company may develop customised interconnects or semi-custom silicon; a data-centre provider may optimise its infrastructure around a particular architecture; and software may be optimised for a particular combination of hardware and models. NVIDIA's work on chip-to-chip integration, for example, explicitly enables custom silicon to be connected with its CPUs and GPUs, while AMD is building increasingly integrated rack-scale systems across compute, networking, memory, and software.
Such integration can produce powerful performance advantages. It also means that the boundaries between technologies are themselves becoming strategic.
An IT company therefore needs enough depth in its upstream relationships to understand these trade-offs, without attempting to own every component. Its strategic advantage would lie in knowing when to accept an integrated stack, when to seek interoperability, when to substitute a component, and when to combine technologies from different partners.
This leads to a useful distinction.
Technological autarky would mean attempting to own the technologies required for the entire stack.
Technological concentration would mean becoming excessively dependent upon a particular technology provider, architecture, or infrastructure configuration.
The proposed strategy seeks neither.
It seeks architectural ownership with technological optionality.
The IT company should understand and, increasingly, own the architecture of the enterprise solution: what the enterprise needs, how its systems should interact, what performance and assurance standards must be met, and how the resulting system should evolve. The underlying technologies can remain distributed among specialist partners.
The strategic objective is therefore not to predict the technological winner. It is to remain capable of using the winner—and, where necessary, combining several winners—whenever the technology frontier moves.
That is what makes the upstream technology partner portfolio more than a collection of commercial alliances. It becomes an instrument for making the IT company structurally less vulnerable to technological change.
5. From Technologies to Enterprise Products: Multi-Technology, Multi-Tier, Multi-Offering
The purpose of an upstream technology partner portfolio is not to give an IT company an impressive collection of partnerships. Its purpose is to change what the company can deliver.
This distinction matters. An IT company could accumulate partnerships with semiconductor companies, cloud providers, AI model companies, enterprise-software vendors, cybersecurity firms, and data-centre operators, yet remain essentially the same services company if those relationships merely add more technologies to an existing catalogue of offerings. The strategic opportunity lies elsewhere: in combining technologies from different partners into coherent solutions for particular enterprises, industries, functions, and geographies.
This would make the IT company's portfolio multi-technology, multi-tier, multi-offering, and eventually multi-product.
The first dimension is multi-technology. An enterprise solution may involve chips or chiplets, compute systems, data infrastructure, cloud services, enterprise software, AI models, specialised small language models, agents, databases, cybersecurity, networking, edge platforms, and industrial software. The IT company does not have to manufacture these technologies. Its distinctive capability can lie in determining which technologies should be used, how they should interact, and how they should be adapted to the enterprise's requirements.
The second dimension is multi-tier. The relevant technology stack increasingly extends from physical infrastructure to compute, software, AI, orchestration, applications, and ultimately enterprise operations. A conventional IT service may occupy only some of these layers. A technology-oriented IT company could increasingly connect them.
The third dimension is multi-offering. The same technological ecosystem could support consulting, implementation, Forward Deployed Engineering, managed services, AI assurance, industrial AI, technology portfolio management, workforce capability development, and other forms of continuing engagement. These should not necessarily remain separate practices. They can become components of an integrated enterprise offering.
The fourth dimension is multi-product. This is perhaps the most important transition.
The word product may sound unusual in the context of IT services, but there is a useful analogy in banking. A bank does not manufacture the money that it deploys. It transforms capital obtained from depositors, investors, and other sources into financial products suited to different needs: working-capital finance, mortgages, project finance, trade finance, credit cards, and many others.
An IT company could perform an analogous transformation with technology.
Technology companies manufacture technologies. IT companies could increasingly transform those technologies into enterprise products.
The product need not be a piece of software in the conventional sense. It could be a carefully engineered combination of infrastructure, compute, software, AI, data, domain expertise, human intervention, and ongoing operations, designed to produce a particular enterprise outcome.
Consider a manufacturing enterprise. Its requirement might be a system for predictive maintenance across a group of plants. The underlying product could combine an industrial AI model, machine-vision software, edge accelerators, factory connectivity, a digital-twin environment, central compute, cybersecurity, existing enterprise systems, and human operational oversight. None of these components necessarily belongs to the IT company. Yet the combination, its deployment architecture, its operating model, and the accumulated knowledge of how to make it work could become the IT company's product.
This changes the source of value.
The IT company's contribution becomes:
selection + combination + integration + customisation + deployment + operation + assurance + domain knowledge.
It is therefore no longer necessary to define the product by the technology that sits at its centre. The product can instead be defined by the enterprise capability it creates.
This is particularly important as AI becomes more accessible. If models, agents, software components, and computing capacity become increasingly available from multiple providers, the scarcity may shift from access to individual technologies towards the ability to combine those technologies reliably and economically around a real business problem.
That could also change the relationship between services and products. Services would not disappear. They would become the deployment and learning engine for products.
A customised enterprise deployment can reveal a recurring problem. A recurring problem can reveal a recurring technological configuration. That configuration can become a reusable architecture. The architecture can become a platform. And a platform can eventually become a product that can be deployed across many enterprises with appropriate configuration.
This is not a rejection of bespoke work. It is an attempt to ensure that bespoke work does not remain economically trapped as bespoke work.
The strategic ambition, therefore, is not simply to offer clients more technologies. It is to develop the capability to turn an expanding universe of external technologies into increasingly sophisticated, repeatable enterprise capabilities.
That is how an upstream technology partner portfolio can eventually become something much more valuable than a partnership catalogue: a product engine.
6. The Product Engine: Enterprise Problem to Technology Combination to Reusable Product
If the transformation from services to products is to be more than an aspiration, Indian IT companies will need to change how they treat the knowledge generated by individual client engagements.
The conventional services model tends to regard a completed project as an endpoint. A client has a problem, a team develops and implements a solution, the system is handed over or moved into managed operation, and the team proceeds to the next engagement. Some knowledge is undoubtedly retained, but much of the economic value of the experience can remain attached to the particular project and the people who worked on it.
A product-oriented IT company would treat every significant deployment differently.
The sequence should become:
Enterprise demand → technology selection → technology combination → deployment → recurring pattern → reusable architecture → platform → product.
The first step is understanding the enterprise problem rather than beginning with a technology. The second is identifying which combination of technologies can address it. This is where the upstream technology partner portfolio becomes important. The IT company can evaluate different models, software platforms, compute architectures, infrastructure configurations, and specialist technologies rather than beginning with the assumption that a particular vendor's technology must be used.
The third step is deployment. This is where engineering, domain expertise, and Forward Deployed Engineers become important. Technologies that appear compelling in isolation may behave differently when confronted with legacy systems, organisational processes, regulatory requirements, physical infrastructure, imperfect data, or the everyday constraints of an enterprise.
Deployment therefore produces something that cannot be obtained entirely through laboratory testing: organisational knowledge.
The company should deliberately capture that knowledge.
Suppose an IT company deploys an AI-enabled procurement system for one large manufacturer. It learns how the system interacts with the client's ERP, procurement rules, supplier databases, security architecture, approval processes, and employees. A second deployment reveals which elements are common and which are specific to the first enterprise. A third begins to reveal a recurring architecture.
At that point, the company has something more valuable than three successful projects. It has the beginnings of a reusable pattern.
The reusable pattern can become a reference architecture. The reference architecture can be turned into a platform, with configurable modules and interfaces. The platform can eventually become a product that can be offered to many enterprises in the same industry or facing the same functional problem.
This is the mechanism through which services can generate intellectual property rather than simply revenue.
The process also changes the meaning of organisational learning. Learning should not remain inside the heads of the employees who happened to work on a project. It should move through the organisation:
individual experience → team knowledge → organisational knowledge → reusable architecture → platform → product.
The upstream technology portfolio makes this learning process even more valuable because the company is learning not only about enterprise processes but also about technology combinations.
It may discover that a particular class of accelerator works exceptionally well for a particular inference workload. It may discover that a smaller model is preferable to a frontier model for a particular function because of cost, latency, privacy, or reliability. It may discover that an edge deployment combined with central compute produces better economics than a wholly centralised architecture. It may discover that two software platforms complement each other unusually well.
Those discoveries can themselves become part of the company's intellectual property and delivery methodology.
This creates a feedback loop:
Enterprise deployment → technology learning → organisational learning → reusable architecture → product → further deployment → further learning.
Over time, the IT company could therefore become progressively less dependent on starting from zero for every engagement.
This is also where the distinction between a service and a product becomes less rigid. A product may initially require considerable customisation and human engineering. As the company learns, more of its architecture becomes standardised, while the remaining customisation becomes easier and more valuable. The product can consequently evolve without becoming a rigid piece of software.
The objective is not to eliminate human expertise. It is to capture and multiply human expertise through reusable technological and organisational assets.
That is the crucial economic transition.
A company that sells only labour must repeatedly sell the same underlying unit of capacity. A company that converts experience into platforms and products can increasingly sell the accumulated result of previous work.
The long-term ambition, therefore, should be to make every major deployment contribute to the next generation of the company's products.
The project should not end when the project ends. It should leave behind something that makes the next project better.
7. Industrial AI: Taking the Strategy Into the Physical Economy
The opportunity for Indian IT should not be confined to the transformation of office work. If the industry is to build a durable position in the emerging technology economy, it will also need to move deeper into the physical economy through industrial AI.
This matters because the physical economy presents a fundamentally different technological challenge from connecting an AI model to an office database. A factory, power plant, telecommunications network, warehouse, port, mine, hospital, or transport system contains machinery, sensors, legacy software, operational processes, safety requirements, regulatory constraints, and workers whose activities are intertwined with the technology.
The difficulty of deploying AI in such environments is precisely what can make the opportunity valuable.
A general-purpose model may possess impressive reasoning or language capabilities, but it does not automatically know how a particular production line operates, how a chemical process responds to changes in temperature and pressure, how a power network should be managed, how a machine's vibration patterns indicate an impending failure, or how a logistics system should respond to disruptions in real time. These problems require combinations of domain knowledge, software, sensors, compute, networking, AI, human judgement, and physical deployment.
This is where the proposed upstream technology partner portfolio becomes particularly useful.
Industrial AI may require a combination of specialised chips or accelerators, edge-computing platforms, industrial software, computer vision, digital twins, small domain-specific models, central AI infrastructure, enterprise software, cybersecurity, networking, and conventional automation systems. Different industrial workloads may require entirely different combinations.
An IT company does not need to manufacture all these technologies. Its opportunity lies in assembling them around the operational requirements of the industrial enterprise.
Consider a manufacturing plant. One application may require computer vision at the production line, where latency makes edge processing important. Another may require predictive maintenance based on historical machine data and therefore benefit from a larger model running on central infrastructure. A third may involve optimisation across several plants and require integration with enterprise resource planning and supply-chain systems. The solution could consequently involve different chips, models, software, and infrastructure at different points in the same enterprise.
This is precisely the kind of heterogeneous environment in which technological orchestration becomes valuable.
Industrial AI also introduces what might be called industrial friction. Software deployed in an office can often be updated, reconfigured, or replaced without directly affecting a physical process. A system controlling or influencing an industrial operation cannot always be treated in the same way. Reliability, safety, latency, interoperability, cybersecurity, regulatory compliance, and continuity of operations matter much more.
That friction should not necessarily be regarded as a barrier to IT companies. It can become a source of competitive advantage.
An IT company that has learned how to make AI work reliably within a chemical plant, an automobile factory, a telecommunications network, or a logistics operation accumulates knowledge that is difficult to reproduce through a generic AI platform. It learns how technologies interact with physical processes, organisational routines, legacy systems, and human operators.
This is also where the boundary between IT and engineering begins to blur.
Industrial AI will require software engineers to work with electrical engineers, mechanical engineers, process engineers, data scientists, domain specialists, and operations personnel. The IT company will need to understand not only the software stack but the physical system into which the software is being inserted.
This would also change the geography of Indian IT.
The traditional IT-services model allowed a substantial proportion of delivery work to be concentrated in large technology centres. Software could be developed, tested, managed, and supported from locations far removed from the enterprise whose systems it served. That model remains valuable, but it becomes less sufficient when the technology being deployed interacts directly with factories, machines, warehouses, power systems, telecommunications networks, transport infrastructure, and other physical environments.
Edge AI makes this particularly apparent.
An edge-AI system may have to be installed on or near a production line, integrated with existing industrial equipment, tested under actual operating conditions, monitored, maintained, and periodically reconfigured. Industrial software may require similar physical engagement. A digital twin may require detailed understanding of the physical process it represents. A machine-vision system may require engineers to understand lighting, camera placement, production speeds, equipment variation, and the consequences of false positives or false negatives.
These are not problems that can always be solved effectively from a distant delivery centre.
Indian IT companies may therefore need a more distributed physical footprint: small, specialised technology presences in or near important industrial clusters.
These need not resemble the large campuses associated with conventional IT services. Their purpose would be different. They could function as field-engineering, Forward Deployed Engineering, industrial-AI, testing, integration, and support nodes, connected to the company's larger engineering and computing centres.
An automotive cluster could have a specialised team working on industrial vision, manufacturing analytics, robotics, and supply-chain intelligence. A pharmaceutical cluster could have teams working on process optimisation, quality systems, laboratory automation, and regulated AI. A metals or chemicals cluster could require expertise in process control, predictive maintenance, energy optimisation, and industrial safety. Ports and logistics clusters could require edge intelligence, fleet optimisation, warehouse automation, and computer vision.
The precise configuration would vary by industry and geography. The important point is that industrial AI creates a reason for IT companies to become physically closer to the industries they serve.
This could produce a new spatial architecture for IT:
large technology and compute hubs → regional engineering centres → industrial-AI nodes → factories and physical enterprises
The smaller nodes would not replace the large delivery centres. They would complement them.
They could also strengthen the role of Forward Deployed Engineers. An FDE working with an industrial customer may need to spend meaningful time at the customer's site, understand its processes, work with local engineers and operators, and translate those observations into changes in the technology architecture. Once a solution becomes mature, some of that knowledge can flow back to the larger engineering organisation and become part of a reusable product or platform.
There is consequently a two-way flow:
central technology capability → industrial deployment
and
industrial experience → central organisational learning
That is important for productisation. The company cannot reliably develop industrial products solely from a central office and then expect them to work everywhere. The physical world introduces too much variation. But neither should every industrial deployment remain entirely bespoke. Local industrial nodes can capture the variation while the larger organisation turns recurring patterns into reusable architectures and products.
This distributed presence would also have a workforce implication. Employees working in these nodes would need a different mixture of capabilities from those in conventional software-delivery centres. They might combine software and AI expertise with mechanical, electrical, electronics, process, manufacturing, logistics, or other domain knowledge.
Industrial AI therefore becomes more than another service line. It begins to reshape the technology stack, the workforce, the organisation, and the geography of the IT company.
Indian IT would have large centres for scale, regional centres for engineering depth, and industrial nodes for physical-world deployment and learning. Together, they could provide the organisational infrastructure required to connect upstream technology portfolios with downstream industrial applications.
The industry's role would consequently begin to change: from delivering software to enterprises from afar towards embedding technological capability within the enterprises and industries themselves.
8. The AI Companies' Commercialisation Problem Is an Opportunity for IT
The proposed upstream strategy also becomes more compelling when viewed from the perspective of the technology companies themselves. AI model companies, semiconductor companies, software providers, and data-infrastructure companies have committed enormous amounts of capital to building the technologies required for the next generation of computing. Their challenge is increasingly moving from technological capability to commercial utilisation: how to convert that capability into sustained enterprise demand, recurring workloads, and credible pathways to returns.
This creates a potential opportunity for IT companies.
A chip company may be able to produce a highly capable accelerator, but it needs workloads that justify its deployment. An AI model company may develop an impressive model, but it needs enterprises willing to integrate it into actual business processes. A data-centre operator may build substantial capacity, but ultimately needs sustained demand for that capacity. An enterprise-software company may develop sophisticated functionality, but needs organisations to incorporate it into their operations.
The Indian IT industry's accumulated enterprise relationships could provide a bridge between these upstream capabilities and downstream demand.
This would be considerably more valuable than simply acting as a reseller.
An IT company could bring to an upstream partner a large base of enterprise requirements, industry knowledge, engineering capability, integration expertise, and deployment capacity. In return, the upstream partner could provide access to specialised technology, engineering support, preferential commercial arrangements, co-development capabilities, or early access to new products and architectures.
The relationship could therefore become mutually reinforcing.
Consider a hypothetical industrial-AI product. An IT company might identify a recurring requirement for real-time machine vision across a particular manufacturing segment. It could work with a semiconductor company providing edge accelerators, an AI company providing a suitable vision model, an industrial-software company providing the application layer, and a data-infrastructure partner providing the necessary central computing environment. The IT company could integrate these components, deploy them through its industrial engineering teams, operate the resulting system, and eventually turn the recurring architecture into a product.
The upstream companies would gain commercial utilisation of their technologies. The IT company would gain a higher-value product and deeper technological capability. The manufacturing customer would gain a system designed around an actual operational problem.
This is where the distinction between technology supply and technology commercialisation becomes important.
The upstream companies can create increasingly sophisticated technologies. But technologies do not automatically become economically valuable merely because they exist. They need to be integrated into organisations, adapted to workflows, connected to legacy systems, deployed at scale, operated reliably, and continually improved.
These are precisely the areas in which IT companies have accumulated experience.
The opportunity is therefore not simply to help AI companies sell their technologies. It is to help them commercialise those technologies through enterprise systems.
This could become particularly important as AI companies themselves move downstream. Some are establishing forward-deployment teams, building enterprise services, developing specialised infrastructure, and forming increasingly direct relationships with major customers. That creates a competitive uncertainty for IT companies: the technology providers may not always be content to remain upstream suppliers.
The answer cannot be to assume that the intermediary role is permanently protected.
Instead, Indian IT companies should make themselves valuable precisely because they can operate across multiple upstream technologies and multiple downstream enterprises. Their advantage would not be that they own the best model or accelerator. It would be that they can determine which combination of technologies is appropriate for a particular enterprise and then make the combination work.
That could also give the IT company greater bargaining power upstream. A technology provider may be willing to offer more favourable commercial terms, joint development, or specialised support to a partner capable of bringing substantial and recurring enterprise demand.
The relationship could even become a form of shared risk-taking. Instead of an IT company merely purchasing technology and hoping that clients will adopt it, the technology provider and IT company could jointly identify enterprise applications, develop reference architectures, and build commercial propositions around them.
This is particularly relevant to India's emerging technology ecosystem. Indian AI companies and semiconductor companies may not initially possess the global enterprise reach of the largest technology corporations. Indian IT companies, by contrast, possess substantial relationships with global enterprises. Bringing the two together could create a domestic technology ecosystem in which technology creation, technology integration, and technology commercialisation reinforce one another.
The same logic applies to data infrastructure. India's growing data-centre ecosystem can provide the physical foundation for increasingly compute-intensive enterprise workloads, while IT companies can provide the applications, integration, operations, and enterprise demand that turn that capacity into productive economic activity.
The strategic possibility is therefore broader than an IT company helping a chip or AI company find customers.
It is the creation of a commercialisation bridge:
upstream technological investment → technology partner → IT-company integration and orchestration → enterprise deployment → recurring utilisation → measurable enterprise ROI
If this bridge becomes sufficiently effective, Indian IT companies could become valuable not merely because they employ large numbers of engineers, but because they help convert the enormous technological investments being made upstream into productive, recurring economic activity downstream.
That would give the upstream technology partner portfolio a second purpose. It would not merely protect the IT company against technological disruption. It could make the IT company an important part of the mechanism through which the next generation of technologies reaches the real economy.
9. GCCs, Localisation, and the Changing Competitive Landscape
The strategic case for changing the Indian IT model becomes stronger when the industry's competitive environment is considered. Two developments are particularly important: increasing political and regulatory sensitivity around the cross-border movement of IT specialists, and the continuing expansion of Global Capability Centres (GCCs) by multinational companies, including in India.
The first creates a potential constraint on one of the traditional foundations of Indian IT's international delivery model. In the United States, for example, there has been growing political opposition to the use of foreign IT specialists at client locations. Similar pressures could emerge in other markets. The precise form and intensity of such restrictions will vary by country, but the strategic question for Indian IT is broader than any individual policy:
how dependent should its international business remain on the ability to move Indian specialists across borders?
One response is straightforward localisation: hire more people in each market and establish larger local delivery capabilities. That will undoubtedly be necessary in some circumstances, and local knowledge can itself be valuable. But if localisation simply reproduces the conventional people-intensive services model in every geography, it may solve a labour-mobility problem without solving the deeper strategic problem.
The alternative is to make the technology architecture itself a more important component of delivery.
An IT company with a diversified upstream technology partner portfolio could combine locally based employees with shared engineering capabilities, specialised technology platforms, managed infrastructure, AI systems, FDEs, and reusable products. The objective would not be to eliminate local employment, but to reduce the extent to which the company's international delivery model depends on physically moving large numbers of specialists from India to client locations.
This becomes even more relevant in the context of GCCs.
Multinational companies are increasingly establishing or expanding their own technology and engineering centres in India. These centres can perform work that Indian IT companies traditionally provided as external services, including software engineering, data and analytics, AI development, cybersecurity, product engineering, and increasingly sophisticated research and development.
From the perspective of India, this is largely positive. GCCs bring investment, high-value employment, technological capabilities, managerial experience, and integration into global corporate innovation systems. They can deepen India's position in the global technology economy.
For Indian IT companies, however, the picture is more complicated.
GCC expansion means that some enterprise technology work is moving from external vendors into the enterprise itself. Indian IT cannot reasonably assume that its historic role as the external technology workforce provider will remain unchanged simply because its client relationships are long-standing.
But GCCs need not be regarded only as competitors.
A multinational may build a GCC precisely because it wants greater control over its technology capabilities, while still requiring external partners for specialised technologies, complex integration, industrial deployment, infrastructure, cybersecurity, AI platforms, or capabilities that it does not wish to build internally.
This creates an opportunity for a different kind of relationship.
An Indian IT company that continues to offer primarily labour capacity may increasingly find itself competing with the GCC's own employees. An IT company that offers technology capability can instead become a partner to the GCC.
It could provide an industry-specific AI platform, or a multi-agent architecture, or an industrial-AI system, or an AI-assurance capability, or a specialised engineering service, or a product assembled from several upstream technologies. It could also help a GCC evaluate and integrate technologies that are evolving too rapidly for the GCC to develop expertise in every component itself.
The distinction is therefore significant:
The competitive question is not whether GCCs can do work that IT companies currently do. It is whether IT companies can develop capabilities that remain valuable even when enterprises internalise more of their technology work.
This is where the proposed transition from services to products becomes important.
A product can be sold to a GCC in much the same way that it can be sold to a conventional enterprise. A technology platform can be integrated into a GCC. A specialised industrial-AI system can be deployed alongside the GCC's own engineering teams. An FDE can work with the GCC to configure and operate a solution. A multi-technology architecture can be provided without requiring the client to employ specialists in every underlying technology.
The relationship consequently becomes less about supplying people and more about supplying capability that the client may choose to consume, integrate, operate, or co-develop.
This also creates a potential role for Indian IT companies in the growth of GCCs within India itself. Rather than seeing every new GCC as another piece of work removed from the addressable market, IT companies could seek to become technology partners to these centres, particularly in areas where the rapid pace of technological change makes complete internalisation difficult.
The same logic applies to international markets. If political pressures constrain the deployment of Indian specialists, the answer should not be limited to reproducing the same business model with local employees. The company can progressively shift the composition of its offering towards technology-enabled products, platforms, managed capabilities, and local FDE-based deployment.
This would not make localisation irrelevant. On the contrary, it could make local hiring more strategically useful. Local employees can provide market knowledge, regulatory familiarity, domain expertise, customer proximity, and physical deployment capability, while the wider organisation provides access to its upstream technology portfolio, engineering resources, and accumulated product knowledge.
The resulting model could therefore be more distributed without becoming fragmented:
global technology partnerships + central engineering capability + local specialists + regional FDEs + reusable products
Such a model would represent a significant departure from the classic labour-arbitrage structure of Indian IT.
It would also make the industry's existing enterprise relationships more valuable rather than less. If an IT company can tell an enterprise "We understand your business, we have access to a broad portfolio of technologies, we can configure them for your requirements, deploy them locally, operate them, and continuously update the system as the technology changes," - its proposition is fundamentally different from simply offering additional engineers.
The strategic transition can therefore be expressed quite simply:
From selling labour capacity to selling technological capability.
That transition will not eliminate competition from GCCs, nor will it remove the need for local employees. But it can give Indian IT a way to remain strategically relevant even as enterprises become more technologically self-sufficient and labour mobility becomes more constrained.
In that sense, the rise of GCCs and the pressures around cross-border IT employment should not be viewed merely as threats to the existing Indian IT model. They are signals that the model itself may need to evolve.
10. The CTO as Architect of the Technology Ecosystem
Such a transformation would require changes not only in what Indian IT companies sell, but also in how they organise themselves. One particularly important change could occur in the role of the Chief Technology Officer.
The CTO of large IT companies has traditionally had responsibility for technology strategy, engineering standards, internal platforms, emerging technologies, and, increasingly, the development of technology offerings for clients. But a company pursuing the strategy outlined here would need its CTO function to become considerably more outward-looking and more deeply connected to the commercial organisation.
The CTO function would need to understand two continuously changing environments.
The first is enterprise demand: what clients in different industries are trying to achieve, which functions are being transformed, which technologies are becoming strategically important, and where existing systems are reaching their limits.
The second is technology supply: which chip architectures are emerging, which AI models and software platforms are becoming capable, how cloud and data-centre architectures are changing, what new edge platforms are available, and which technologies are sufficiently mature to be incorporated into enterprise systems.
The CTO function would therefore sit at the intersection of:
technology supply ↔ organisational capability ↔ enterprise demand
This is a considerably broader role than technology procurement.
The question would not simply be, "Which technologies should we buy?" It would be:
"Which technological capabilities should this company be capable of delivering to its enterprise clients over the next several years, and which combination of partnerships, infrastructure, software, engineering capabilities, and workforce development will allow it to do so?"
That question requires continuous technology scouting.
A new accelerator architecture may alter the economics of an AI workload. A new model may make a previously expensive application viable. An edge platform may make industrial deployment possible where centralised computing was impractical. A new enterprise-software platform may change how an organisation's data and applications are integrated. A new data-centre configuration may make a particular class of workload substantially more economical.
The CTO function would need to monitor these developments not as isolated technological news, but in relation to the company's enterprise portfolio.
This would also change the nature of upstream partnerships.
Technology partnerships should not be left entirely to procurement or business-development teams. Commercial teams can negotiate contracts, and procurement can manage suppliers, but the strategic question is architectural: what role should a particular technology play in the company's future delivery system?
That requires technological judgement.
It also requires a willingness to maintain relationships with competing technologies. A CTO function may deliberately maintain relationships with several chip companies, several AI-model providers, several software ecosystems, or several infrastructure providers because the purpose of the portfolio is not to identify a permanent winner in advance.
The company may eventually choose one technology for a particular workload. But it should be able to reconsider that choice when technological or economic conditions change.
This is where the CTO function connects directly with the company's product strategy.
Suppose enterprise demand reveals a recurring requirement in a particular industry. The CTO function can identify the technology architecture required to address it, determine which upstream partners can provide the necessary components, and work with engineering teams to develop a reference architecture. If that architecture is repeatedly deployed, the organisation can help turn it into a platform or product.
The direction of knowledge therefore runs both ways:
enterprise demand → technology strategy
and
technology capability → enterprise product development
The CTO becomes an important institutional bridge between the two.
But this function should not be based entirely on watching technologies from a distance. An IT company intending to recommend a technology to its clients should, wherever practical, first become its client zero.
This does not mean putting the entire organisation into permanent experimental mode. An IT company has production systems, contractual obligations, cybersecurity responsibilities, regulated operations, and client commitments. Continuous experimentation across the entire organisation would be neither practical nor desirable.
Instead, the company could establish controlled technology sandboxes and bounded internal environments in which new technologies, or modular combinations of technologies, can be tested.
A new AI model, accelerator, agent framework, edge-AI platform, enterprise-software system, or data-centre configuration could first be evaluated in a technology sandbox. If it demonstrates sufficient technical promise, it could then be deployed against a defined internal use case. Only after gaining operational experience might it move into selected client environments.
The progression could be:
technology sandbox → bounded internal deployment → controlled client deployment → reference architecture → productisation
This creates a technology-maturity pipeline rather than a perpetual culture of experimentation.
It also allows competing technologies to be evaluated against one another. An IT company might test different models for the same workload, different accelerator architectures for the same inference requirement, or different combinations of edge and central computing. Such experimentation could generate empirical knowledge about performance, reliability, integration, security, and economics before the technology is recommended to clients.
Client-zero experimentation would also become an important component of workforce learning. Employees could acquire practical knowledge of new technologies within controlled environments rather than learning about them only through courses or presentations. An engineer could work with a new accelerator architecture; an FDE could test an industrial-AI stack before deploying it in a factory; an architect could compare different model-and-infrastructure combinations; and a product team could determine whether a recurring solution is sufficiently mature to become a commercial offering.
The sandbox therefore becomes more than a technical facility. It becomes part of the company's organisational learning infrastructure.
It also gives the upstream technology partner portfolio a mechanism for self-selection. Not every partnership needs to become a commercial offering. Internal experimentation may reveal that a technology is immature, uneconomical, difficult to integrate, insufficiently secure, or simply not valuable for the company's enterprise base. Other technologies may prove sufficiently useful to warrant deeper partnerships and product development.
The IT company can consequently learn before it commits at scale.
Technology strategy therefore generates workforce strategy, while workforce capability can influence which technologies the company is able to absorb effectively. A new industrial-AI platform may require electronics and mechanical expertise alongside software skills. A new AI architecture may require different engineering capabilities. A new data-centre configuration may require knowledge of infrastructure, networking, power, cooling, and systems engineering.
The CTO function consequently becomes part of a continuous cycle:
technology scouting → partner evaluation → enterprise demand assessment → sandbox experimentation → architecture → capability mapping → workforce development → deployment → feedback → portfolio revision
This is fundamentally different from a periodic exercise in identifying the "next big technology".
The company would instead develop an institutional capacity to continuously absorb technological change.
That may ultimately be one of the most important strategic functions of the CTO in an IT company. The CTO would not simply be responsible for ensuring that the organisation keeps up with technology. The CTO would help determine how the organisation should continuously reorganise its technological relationships, workforce capabilities, and product architecture as technology itself keeps changing.
In that sense, the CTO becomes not merely the custodian of technology, but an architect of the company's technological ecosystem.
11. Workforce Learning as a Sociological Strategy
The technological transformation described above cannot be sustained through a conventional workforce-transformation programme. A large IT company cannot periodically declare a new technological priority, train its employees for it, and then assume that the organisation is prepared for the next phase of change. The underlying problem is that both sides of the company's strategic environment are continuously changing.
Downstream demand will change as enterprises adopt new technologies, reorganise functions, build GCCs, and move into industrial AI. At the same time, the upstream technology partner portfolio will change as new chips, models, software platforms, infrastructure configurations, and edge technologies emerge.
Workforce learning therefore cannot be treated as a one-time response to AI.
A generic AI-orientation program can certainly be useful. It can give a large workforce a common understanding of new technologies and their implications. But orientation is different from capability. Capability has to be continuously developed because the technologies employees are expected to work with, and the problems clients expect them to solve, will themselves keep changing.
This has a deeper sociological implication for the IT company.
The conventional services model tends to regard the employee primarily as a unit of deployable and billable capability. The organisation recruits people with particular skills, assigns them to projects, measures utilisation, moves them between engagements, and seeks to maintain a high proportion of productive time.
Within such a system, the employee between projects can easily become the "bench"—a person whose productive value is temporarily suspended because there is no immediate client assignment.
The strategy proposed here requires a different conception.
The employee should increasingly be regarded as a structural capability of the organisation, rather than merely as a bundle of currently billable skills.
That distinction matters because an employee's value should not be exhausted by what he or she can deliver today. Part of the company's productive capacity lies in the ability of its people to learn what the company will need tomorrow.
This changes the meaning of time between projects.
A person who is not currently assigned to a client engagement need not necessarily be considered idle. Within a structured capability-development system, that person could be learning an upstream partner's technology, experimenting in a technology sandbox, developing a reusable component, studying a new industry, participating in an FDE simulation, working on an AI-assurance framework, or contributing to the productisation of knowledge generated by previous deployments.
The important qualification is that this cannot become a euphemism for an enlarged bench.
The company would need to establish deliberate capability-building environments, with identified technologies, learning pathways, practical assignments, mentors, assessment mechanisms, and links to future enterprise demand. Time spent outside a client project would thereby have the possibility of generating future productive capacity.
The organisational cycle would change accordingly:
learning → deployment → experience → organisational learning → capability development → redeployment → productisation
The distinction between individual learning and organisational learning is particularly important.
If an employee learns how to deploy a new AI architecture and that knowledge remains with the employee, the organisation has gained only partially. If the knowledge is documented, incorporated into reference architectures, shared through training, embedded in platforms, and used in subsequent deployments, it becomes an organisational asset.
The company should therefore seek to move knowledge through a chain:
individual experience → team knowledge → organisational knowledge → reusable architecture → platform → product
This is where continuous workforce learning connects directly with the upstream technology partner portfolio.
A change in the partner portfolio should automatically create questions about workforce capability. If the company develops a strategic relationship with an accelerator provider, who understands the architecture? If it adopts a new AI software platform, who can deploy and assure it? If it expands into industrial AI, does it possess sufficient mechanical, electrical, electronics, process, manufacturing, or logistics expertise? If a new data-centre architecture becomes strategically important, does the workforce understand networking, power, cooling, systems engineering, and infrastructure management?
Technology strategy therefore becomes workforce strategy.
The reverse is also true. The capabilities already present within the workforce can influence which technologies the company can absorb effectively. A technology partnership that looks attractive on paper may produce little value if the organisation lacks the people capable of integrating and deploying it.
This suggests a different approach to hiring as well.
Indian IT companies may increasingly need to look for disciplinary depth combined with learnability, rather than simply candidates who possess the currently fashionable technology skills.
A candidate with a strong foundation in mechanical engineering, electrical engineering, electronics, chemical engineering, materials, manufacturing, logistics, finance, life sciences, or another relevant discipline may bring something that a short technology-training programme cannot easily reproduce: an understanding of the underlying system in which technology will operate.
That disciplinary foundation can then be combined with computational literacy and continuous technology learning.
This is particularly important for industrial AI. The person who understands a manufacturing process, electrical system, chemical process, logistics network, or machine may be able to learn the relevant AI and software technologies more effectively than a generic technology specialist attempting to learn the physical system from scratch.
Apprenticeship could therefore become increasingly important.
A possible pipeline would be:
university → disciplinary foundation → apprenticeship → technology-portfolio learning → deployment → specialisation → continuous learning
Apprenticeships would provide an intermediate environment in which candidates could demonstrate not only what they already know, but how quickly and effectively they can learn, apply, collaborate, and adapt.
A relatively broad apprenticeship base could then feed a smaller permanent workforce, alongside selective direct recruitment of exceptional candidates.
This changes the sociology of the employment relationship.
The company is no longer simply purchasing a fixed quantity of skills from employees. It is participating in the continuous creation of capabilities—for the employee, for the team, and for the organisation itself.
That, in turn, changes what workforce productivity means.
Traditional utilisation metrics ask:
"How much of this person's time is currently billable?"
A technology-oriented IT company would also need to ask:
"What new capability did this person's time create?"
That capability might not generate revenue immediately. It might emerge as a new technology skill, an industrial reference architecture, a reusable software component, a product prototype, a new FDE methodology, or organisational knowledge about a technology partner.
Some of these investments will fail. That is unavoidable. A company that continuously learns will also continuously discover technologies that are unsuitable, immature, uneconomic, or irrelevant to its clients.
But the objective is to make learning itself part of the productive architecture of the company.
This is why workforce transformation should not be understood merely as preparing employees for an AI-powered future. The deeper objective is to create an organisation in which people and technology continuously adapt to one another.
The employee is not simply trained to operate the next technology.
The employee participates in discovering how the company should use it, how it should be combined with other technologies, where it creates value, where it fails, and how the resulting knowledge can be converted into organisational capability.
That is a fundamentally different sociology of the IT company — and potentially one of the most important foundations of its long-term resilience.
12. The IT Company as the AI Value-Chain Bridge
The preceding arguments point towards a broader role for Indian IT: not simply as a provider of technology services, but as a bridge between different layers of the emerging technology economy.
The relevant value chain is becoming increasingly complex:
chips and chiplets → compute systems → data infrastructure → software → AI models and agents → orchestration → office and industrial applications → enterprise outcomes
No single company is likely to dominate every layer. Indeed, the increasing specialisation of technology companies may make such vertical integration less likely. Semiconductor companies are concentrating on increasingly sophisticated compute architectures; AI companies are developing models and agents; software companies are building specialised platforms; data-centre companies are investing in increasingly powerful infrastructure; and industrial and enterprise companies are developing applications around their particular operational requirements.
The challenge is therefore not necessarily a shortage of technology.
It is the difficulty of connecting technologies across layers and converting them into useful economic capability.
This is where Indian IT could occupy a distinctive position.
Its historical strength has been precisely the ability to connect technology with organisations. It understands enterprise processes, integrates heterogeneous systems, manages large-scale technology deployments, supplies engineering capabilities, and remains involved after implementation. The strategy proposed here would extend that role upstream and downstream.
Upstream, the IT company would maintain relationships with:
- semiconductor and chiplet companies;
- compute and infrastructure providers;
- data-centre operators;
- cloud companies;
- AI-model and AI-software companies;
- enterprise-software providers;
- cybersecurity companies;
- edge-AI and industrial-technology companies.
Downstream, it would maintain relationships with enterprises across industries and functions.
Between the two, it would build the capabilities to select, combine, integrate, deploy, operate, assure, and continuously improve the technologies.
The resulting role is different from that of a conventional systems integrator. The company would not merely connect technologies because a client has instructed it to do so. It would increasingly possess the knowledge to determine which combination of technologies should be used in the first place.
This distinction becomes important as technological choice expands.
An enterprise may soon be able to choose among multiple models, multiple agents, multiple enterprise-software platforms, multiple accelerators, different cloud configurations, central and edge computing, and different data-infrastructure arrangements. The abundance of choice can itself become a problem.
The enterprise does not necessarily want to become an expert in every technology.
It wants a system that works.
The IT company's value therefore shifts towards technological mediation: understanding the available technologies well enough to assemble the appropriate combination around the enterprise's actual requirements.
This is particularly relevant to industrial AI, where the number of interacting layers can be even greater. A factory may require sensors and industrial equipment, edge computing, specialised accelerators, machine-vision software, AI models, networking, cybersecurity, central data infrastructure, enterprise software, and human oversight. The commercial value does not lie in any one component. It lies in making the entire system work reliably.
The same principle applies to office-based enterprise AI. A financial-services company may require a combination of enterprise data systems, specialised models, agents, cybersecurity, workflow software, human approval mechanisms, and assurance systems. Again, the outcome depends upon the architecture rather than any individual technology.
This creates a potential alignment of interests across the technology ecosystem.
Chip companies need meaningful workloads and sustained utilisation.
AI companies need enterprise adoption and recurring usage.
Software companies need their platforms embedded in business processes.
Data-infrastructure providers need sustained compute demand.
IT companies need higher-value, more defensible offerings.
Enterprises need measurable returns from their technology investments.
The IT company could therefore become a mechanism through which these interests reinforce one another.
This is also why the earlier emphasis on technological optionality is important. The bridge should not be built around a single upstream technology supplier. If it is, the IT company merely becomes another distribution channel for that supplier.
The strategic advantage arises when the bridge can connect multiple upstream technologies to multiple downstream requirements.
The company can then mix and match.
A particular industry may require one class of model and accelerator. A particular function may require another. A particular geography may impose data-residency or infrastructure requirements that favour a different architecture. A particular industrial application may require edge computing rather than centralised processing. A high-volume, low-complexity workload may favour a smaller model, while another may justify a more capable system.
The IT company's technology portfolio provides the choices. Its enterprise knowledge provides the context. Its engineering capability provides the means of integration. Its workforce-learning system provides the capacity to keep adapting. Its productisation engine converts repeated combinations into reusable offerings.
The result is a potentially powerful position in the middle of the technology ecosystem.
But "middle" should not be understood as an intermediary position in the traditional sense. The objective is not to become a passive layer between technology vendors and enterprises. It is to become the architectural and operational bridge through which technologies acquire context, integration, and economic purpose.
That could give Indian IT a particularly important role in India's emerging technology ecosystem.
India is simultaneously building capabilities in AI, semiconductors, data infrastructure, electronics, industrial technology, and digital public infrastructure. These capabilities will not automatically connect themselves to the country's factories, logistics systems, financial institutions, hospitals, utilities, and other enterprises.
Indian IT companies possess something that many technology manufacturers do not: large-scale experience of connecting technology to organisations.
If they can combine that downstream strength with a diversified upstream technology partner portfolio, they could become one of the mechanisms through which India's expanding technology supply is converted into enterprise and industrial capability.
The strategic proposition can therefore be stated quite simply:
Indian IT can become the bridge between AI technology and the real economy—not by owning every technology, but by becoming exceptionally good at connecting the right technologies to the right enterprises, industries, and applications, and ensuring that the resulting systems generate sustainable returns.
That would represent a significant evolution of the industry's traditional role.
It would also give the industry a purpose beyond merely surviving technological disruption. It would position Indian IT as one of the institutions responsible for turning technological abundance into productive capability.
13. The Strategic Architecture—and the Sociological Challenge for the Board
The strategy proposed here can now be viewed as a connected architecture rather than a collection of individual initiatives.
At its foundation is the enterprise relationship. Indian IT already possesses decades of relationships with enterprises across industries and geographies. Those relationships provide knowledge of downstream demand: what enterprises need, where their existing technology systems are inadequate, which functions are changing, and where new technological capabilities could generate value.
That downstream knowledge can then inform the company's upstream technology partner portfolio.
The portfolio can span data infrastructure, chips and chiplets, compute, cloud, enterprise software, AI models, agents, cybersecurity, networking, edge platforms, and industrial technologies. Its purpose is not to accumulate partnerships for their own sake, but to create technological optionality: the ability to select, combine, substitute, and continuously reconfigure technologies as both enterprise demand and the technology frontier evolve.
Those technologies then become inputs into a broader technology architecture.
The architecture connects:
data infrastructure → compute → software → models and agents → orchestration → enterprise and industrial applications
The IT company does not have to own every layer. Its strategic role is to understand the relationships between them and determine how they should be assembled for particular enterprise requirements.
That architecture then becomes the foundation for deployment.
Conventional engineering teams can develop and operate large-scale systems, while Forward Deployed Engineers and specialised industrial-AI teams can take technology into enterprises and physical environments. Industrial nodes can provide proximity to factories, logistics systems, energy infrastructure, telecommunications networks, and other physical operations.
Deployment, in turn, generates organisational learning.
The company learns which technologies work, which combinations work, where they fail, what enterprises actually need, how physical environments differ from theoretical architectures, and what kinds of human intervention remain necessary.
That learning should not disappear when the project ends.
It should move through:
deployment → organisational learning → reusable architecture → platform → product
The workforce is part of this architecture rather than a separate support function.
Employees continuously acquire knowledge of the changing upstream technology portfolio and changing downstream requirements. Technology sandboxes provide controlled environments for experimentation. Apprenticeships and disciplinary hiring provide new sources of talent. FDEs and industrial teams develop domain knowledge. Employees between projects can participate in structured capability development rather than simply being treated as unused capacity.
The resulting architecture can therefore be represented as:
Enterprise relationships
↓
Demand intelligence
↓
Upstream technology partner portfolio
↓
Technological optionality
↓
Technology architecture and orchestration
↓
Engineering and FDE deployment
↓
Organisational learning
↓
Reusable architectures and platforms
↓
Industry-specific and function-specific products
↓
Enterprise outcomes and recurring revenue
There is also a second loop running through the system:
Upstream technology innovation
↓
IT-company experimentation and client-zero deployment
↓
Workforce learning
↓
Enterprise deployment
↓
Technology utilisation and commercialisation
The two loops reinforce each other.
The first is driven by enterprise demand.
The second is driven by technological change.
The IT company's strategic capability lies in connecting the two.
This is why the strategy should not be understood simply as diversification into more services. It is a change in the architecture of the firm.
It changes what the company regards as a strategic asset. It changes how it relates to technology suppliers. It changes how it uses its workforce. It changes how it treats learning. It changes where it operates geographically. It changes how it develops products. And it changes what it considers productive organisational activity.
That brings the strategy to its most difficult question: the board's conception of the company itself.
A technological transformation of this scale cannot be achieved simply by adding a new AI business unit or appointing a new technology leader. The board would have to alter several deeply embedded assumptions about how an IT-services company creates value.
The first is the conception of the employee.
If the employee is primarily regarded as a billable input, continuous learning will always appear to compete with utilisation. Time spent experimenting with a new technology, learning an upstream partner's platform, or developing a reusable architecture can appear unproductive because it does not immediately generate a client invoice.
If, however, the employee is understood as a structural capability of the organisation, learning becomes part of productive capacity.
The second is the conception of technology.
Technology cannot remain merely an input that enables employees to deliver services. Under the proposed model, access to technology through strategic partnerships, infrastructure arrangements, software relationships, and specialised engineering capabilities becomes part of the firm's productive architecture.
The third is the conception of partnership.
An upstream technology partner should not necessarily be treated simply as a supplier. A strategically important partner can contribute to product development, workforce learning, experimentation, commercialisation, and access to new technological capabilities. The relationship can therefore become part of the company's long-term strategic architecture.
The fourth is the conception of productive time.
Traditional utilisation measures ask how much of an employee's time is currently billable. A technology-oriented company must also ask what capabilities are being created during time that is not immediately billable.
A sandbox experiment that prevents a costly technology mistake can be productive.
A workforce-development programme that creates a new engineering capability can be productive.
An FDE deployment that reveals a reusable industrial architecture can be productive.
A product prototype that eventually fails but reveals that a technology is commercially immature can also produce valuable organisational knowledge.
This does not mean abandoning financial discipline or allowing unlimited experimentation. It means recognising that some strategically necessary forms of production precede revenue.
The board's challenge is therefore sociological as much as technological.
It must change the organisation's underlying understanding of:
what the company is, what its employees are, what technology is, what partnerships are, and what productive work means.
The company would no longer be primarily a mechanism for converting skilled human labour into billable services. It would increasingly become a continuously learning institution that connects enterprise demand with a changing global technology supply.
That does not make human capability less important. Quite the opposite. It makes human capability more structural because people become the mechanism through which the organisation understands, tests, combines, deploys, and learns from technologies.
Nor does it make technology partners more important than the enterprise client. The enterprise relationship remains the anchor. The difference is that the relationship now becomes the starting point for building a broader technological system around the client.
The board therefore needs to ask questions that go beyond conventional utilisation, revenue growth, and headcount:
- How diversified is our upstream technology partner portfolio?
- How much technological optionality do we possess?
- How quickly can we absorb a new technology?
- How much enterprise knowledge becomes reusable organisational knowledge?
- How much of our work is becoming platforms and products?
- How effectively can we combine different technologies for different enterprise requirements?
- How much of our workforce is continuously acquiring capabilities relevant to future demand?
- How much of our non-client time is generating future productive capability?
- How resilient is our architecture if a major technology provider changes its strategy?
- How effectively are we converting upstream technological innovation into downstream enterprise value?
These questions point towards a different conception of corporate resilience.
Resilience would no longer mean simply having enough cash, employees, clients, or geographical diversification to survive a downturn. It would also mean possessing the technological optionality, organisational learning capacity, enterprise knowledge, and workforce adaptability to change direction without having to reinvent the company each time the technology frontier moves.
That may ultimately be the deepest strategic proposition of the model.
Indian IT does not need to know precisely which technologies will dominate the next decade.
It needs to build an organisation capable of learning, choosing, combining, deploying, and replacing technologies throughout the decade.
The board's task is therefore not merely to approve another technology strategy.
It is to create the organisational conditions under which continuous technological adaptation becomes a permanent capability of the firm.
14. Conclusion: Build the Bridge Before the Next Tide
Indian IT does not need to abandon the strengths that built its global position. Its enterprise relationships, engineering capabilities, domain knowledge, and enormous human resource remain valuable. The strategic question is how those strengths can be made more durable in an environment in which both technology and enterprise demand are changing faster than before.
The answer proposed here is not technological autarky. Indian IT does not need to manufacture its own chips, build its own frontier models, operate every data centre, or develop every piece of software it uses.
Nor should it place its future in the hands of any single technology provider.
Its opportunity lies in building an upstream technology partner portfolio broad enough to provide technological optionality, while retaining the enterprise relationships that provide knowledge of downstream demand.
That creates a different kind of IT company.
It can understand what an enterprise needs, determine which combination of technologies can address that need, access those technologies through strategic partnerships, test them in controlled environments, develop the necessary workforce capabilities, deploy them through engineering and FDE teams, learn from their use, and turn recurring patterns into platforms and products.
Its relationship with technology therefore becomes continuous.
So does its relationship with its employees. Workforce learning becomes part of productive capacity rather than an occasional response to technological disruption. Employees become structural capabilities of the organisation, while the organisation itself becomes a mechanism for continuously converting individual learning into organisational knowledge.
Its relationship with its clients also changes. The company is no longer simply supplying people to execute a client's technology strategy. It can increasingly help determine the technological architecture through which that strategy is implemented, operated, assured, and continuously renewed.
Its relationship with technology partners changes too. It can become a commercialisation bridge through which chips, compute, models, software, data infrastructure, and other technologies reach enterprises and generate sustained economic value.
And its relationship with the physical economy changes through industrial AI. The IT company can move closer to factories, infrastructure, logistics systems, energy networks, and other physical environments, creating new forms of engineering capability and new geographical footprints.
Taken together, this suggests that the next transformation of Indian IT need not be described simply as a transition from traditional services to AI services.
It is better understood as a transition:
enterprise relationships → upstream technology partnerships → technological optionality → orchestration → continuous learning → deployment → organisational learning → platforms and products → recurring enterprise capability
The underlying objective is not to predict which technology will dominate the next decade.
It is to build an organisation capable of learning, choosing, combining, deploying, and replacing technologies throughout the decade.
That brings us back to the boat and the tide.
A boatman cannot know the exact size of every future tide. Nor can an IT company know which model, chip architecture, software platform, infrastructure configuration, or enterprise technology will prove dominant several years from now.
But a boat can be designed to remain navigable as the water changes.
An IT company can do something similar.
It can spread technological risk across partners and architectures. It can retain the ability to substitute technologies. It can continuously develop its people. It can experiment before committing at scale. It can learn from every deployment. And it can turn that learning into increasingly reusable capabilities.
The durable advantage, then, is not possessing the technology of the moment.
It is possessing an organisation that knows how to absorb technological change.
That may be the more sustainable future for Indian IT: not simply becoming another technology company, but becoming an institution capable of connecting a rapidly changing global technology supply with the much slower-moving organisational and physical economy—and continually turning that connection into enterprise value.
Comments
Post a Comment