IT Engineering, Product Engineering, and the Architecture of Regional Technology Dependence
Abstract. Organisations across the Gulf routinely assign the construction of customer-facing software products to information technology functions constituted to select, integrate and operate software purchased from others, and appoint to lead that work managers whose profession is supplier and service management. The two disciplines share a vocabulary and very little else. This paper sets out the mechanisms by which the conflation fails, identifies the appointed manager as the mechanism through which the failure reaches the work, and argues that the decision is an enterprise architecture responsibility discharged badly — through absent knowledge, insufficient influence, or unexercised will. It then examines the aggregate consequence: a regional technology sector whose flagship platform offerings are, at the layer that determines dependence, the operation and resale of platforms built elsewhere. The paper proposes the separation of differentiating from contextual capability as the governing architectural judgement, and states what an architecture function capable of enforcing it would require.
A decision is taken across the region several times a month, usually in under an hour, and usually without anyone present recognising it as a decision.
An organisation has resolved to place a product in front of its customers: a portal, an application, a platform, a service that people outside the company will use and in most cases pay for. The chief executive asks who will build it. The answer is obvious to everyone in the room — give it to IT, because that is where the technical people are.
This is not a resourcing decision. It is a category error, and the department receiving the work is, in the majority of organisations, not constituted to build software at all. It is constituted to buy it, integrate it, and keep it running. Both are demanding disciplines; neither substitutes for the other. Repeated across a region for fifteen years, the confusion produces an economy that purchases technology from the United States and Europe, wraps it, resells it, and adds very little to what the region knows how to do.
An information technology engineering function is excellent at a specific and difficult set of activities. It evaluates suppliers and negotiates with them. It integrates systems that were never designed to meet. It runs identity, networks, endpoints, backup and the licence estate. It keeps an environment available, compliant, patched and within budget, and it absorbs the consequences when a supplier alters its terms. The competence is judgement about other people's products, and operation of those products under pressure.
A product engineering function is excellent at something else. It makes a thing that did not previously exist, places it in front of people who are at liberty to ignore it, and then owns that thing for a decade — its data model, its failure modes, its migrations, its dependencies and its accumulating debt. The competence is creation, followed by long custody.
The two share a vocabulary. Both speak of systems, architecture, releases, uptime, security and users. That shared vocabulary is precisely why executives who are not engineers cannot perceive the boundary, and why the person who could identify it — the enterprise architect — is either absent from the conversation or not heeded within it.
The failure is not that information technology practitioners are less capable. It is that every reflex which makes an operations function excellent becomes a defect when directed at a product.
In an IT function the correct first question about any requirement is who sells this? Building what a supplier already provides is waste, and an IT department writing its own identity platform has failed at its remit. In a product function the same question is fatal, because the part of a product that matters is by definition the part nobody sells. A procurement-shaped organisation asked to build a differentiator will assemble one from purchasable components and produce something a competitor can acquire the following week.
IT exists to serve internal demand. Requirements arrive from the business, are triaged, and are delivered; refusing a business unit is politically expensive and culturally alien. A product requires the opposite: a person who forms a view about a customer, commits to it, and declines ninety per cent of what is requested in order to protect the ten per cent that matters. A function whose entire operating model is demand-taking cannot produce that person and will not protect them if they emerge.
Internal users have no alternative. They will tolerate an unpleasant interface, a slow workflow and an eleven-field form, because the alternative is not performing their work. An IT function can therefore be genuinely excellent for twenty years without developing any capability for adoption — without ever having to produce something people choose. Directed at a paying customer, the deficit appears immediately, in the numbers, and usually too late.
IT is funded to be minimised: its budget is defended by reduction, its projects are approved as capital with an end date, and success resembles the same service for less money. A product is funded to compound, with sustained investment, no end date, and returns arriving in the second or third year. Administered through a cost centre's funding model, a product is cut in year two, precisely when it was becoming useful.
A mature IT function protects the estate with change windows, advisory boards and freeze periods — appropriate where a change carries risk and delivers no revenue. A product delivers value only by changing. A process designed to slow change, applied to a product that must learn weekly, does not make the product safe; it makes it irrelevant.
When purchased software fails, a case is raised with a supplier whose obligations are contractual. When an organisation's own product fails in year four, there is no one to call. There is only whether the people who wrote it remain employed, whether anyone understood it, and whether it was built to be understood. Organisations that have only ever operated other people's software have never had to develop the practices that make a decade of ownership survivable — the tests, the documentation, the architectural discipline, and the refusal of shortcuts that a supplier's engineers previously took invisibly on their behalf.
IT career ladders reward breadth across suppliers and certification against products. Product engineering ladders reward depth in a domain and codebase and sustained ownership. The pay bands differ, the interviews differ, and the seniority signals differ. Product engineering placed inside an IT function will hire on IT bands, interview for IT signals, and receive integrators; the two or three genuine builders who arrive by accident will leave within the year, because their work is being assessed by people who measure completion rather than consequence.
Since the function has no builders, the work is awarded to a systems integrator — a rational response to the position the organisation has placed itself in. The product ships. But knowledge of how it works departs with the contract, the source is a deliverable rather than an asset, the roadmap belongs to whoever holds the maintenance agreement, and every subsequent change is priced by a party with no incentive to make the next one cheaper. Nothing compounds. Five years and three programmes later, the organisation knows precisely what it knew at the start.
All of the above reaches the work through one person: an information technology manager placed in charge of building a product.
Departments do not make decisions; the individual appointed to lead the programme does. The individual appointed is almost always whoever within IT is currently trusted with large budgets and difficult suppliers — which is exactly the wrong qualification, reached by exactly the reasoning that feels most responsible at the time.
An IT manager is competent at genuinely difficult things: holding a supplier to a contract, running a service desk to an agreed level, defending a budget through a cost round, escalating to an account team at two in the morning and obtaining a result. Few executives can do any of these.
Given a product, however, that person will reach for what has always worked. They will run it as a programme, with a plan, a milestone schedule and an end date, because that is the only shape of work they have been rewarded for completing. They will appoint an integrator, because engaging a supplier is how work is done. From that point the outcome is largely determined, because a manager who cannot read the system cannot supervise the people building it. Quality is assessed by demonstration and by milestone, both of which an integrator can satisfy indefinitely while the artefact beneath is constructed in a manner that will not survive its third year. No one is being deceived; there is simply no one present who can tell.
The effect then compounds in two directions.
First, such managers cannot hire builders, because they interview for the signals they know — tool familiarity, certification, estimating discipline, willingness to work to a plan. Strong product engineers interview poorly against that rubric. They ask about the customer, they contest the plan, they want to know who holds the decision, and they are read as difficult. They are screened out in favour of candidates who will be agreeable and deliver to a schedule. Because managers hire in their own image and are promoted by managers promoted the same way, the organisation's stock of operators rises annually while its capacity to recognise a builder decays.
Second, the supplier becomes the source of technical truth. Where an internal team cannot answer an architectural question, someone will, and it will be the account manager — whose answer is sincere, frequently competent, and never contrary to their own interest. This is the point at which the roadmap leaves the building. Everything downstream of it, including the strategy presented to the board the following year, is downstream of a supplier's product plan.
None of this is a criticism of the individuals, most of whom are conscientious people performing well in a position they did not design. It is a criticism of whoever appointed them, and of the architecture function that observed a customer-facing product being placed under a service-management leader and recorded it as a resourcing decision. Placing a capability is not only a question of which department holds it; it is a question of who leads it, and of what that person's profession has trained them to do when the work becomes uncertain.
The discipline whose responsibility it is to intervene at this point is enterprise architecture: to know which capabilities differentiate the business and which are context, to determine what is bought and what is built, and to place each capability in a part of the organisation actually shaped to hold it.
That it so rarely occurs is not generally a failure of intent. It is some combination of three conditions.
Beneath all three lies what the discipline has been permitted to become. In many organisations, enterprise architecture means administering TOGAF as a process and populating a Zachman grid as an ontology — a repository, a body of artefacts, and a governance forum with attendance and no authority. Both frameworks are useful; neither was intended to constitute the work. The work is to make consequential decisions about the shape of the enterprise and to be accountable for them. An architecture practice that has produced a hundred well-formed artefacts and cannot name three decisions it changed in the past year is not underperforming — it is doing something other than architecture.
The same fault appears one layer down, in the division of building from running within a single product.[5] In both cases the boundary is drawn by default, and in both cases the organisation inhabits it for a decade.
Multiplied across a market, the decision produces the pattern now observable in the Gulf: the region's most prominent technology companies are, at the layer that determines dependence, distributors.
Consider the flagship platform offerings from Abu Dhabi. Core42's sovereign public cloud is Microsoft Azure with a sovereignty and controls layer above it.[1] Its sovereign private cloud, announced with Red Hat in May 2026, is Red Hat OpenShift and Red Hat AI — which is to say IBM.[2] Operating a hyperscaler's platform under local control at national scale is genuinely difficult work, and the compliance and controls layer is real engineering performed by capable people. The question is what is owned. The cloud platform is Microsoft's. The container platform is IBM's. What is Emirati is the operation, the wrapper and the customer relationship. Should either supplier alter its licensing — and Red Hat's owner has altered licensing before, at cost to parties who had built on the assumption of continuity — the dependency runs in one direction only.
This is not an argument that such organisations are incapable of building. G42 plainly is capable, and has demonstrated it: Jais, the Arabic large language model developed with MBZUAI and Cerebras and released openly, is a genuine contribution — a thing that did not exist, made in the region and given to the field.[3] It was trained on Condor Galaxy, compute procured and stood up at scale.[4]
It is the exception that establishes the argument. Jais occurred because a decision was taken to build something that did not exist, funded as a build and staffed with people whose profession is building. The commercial platform business was a separate decision, taken in the ordinary way, and was constituted to integrate. One group, two decisions, two entirely different outcomes for what the region ends up knowing. The difference was not capability or capital. It was an architectural determination of what would be owned.
The general form of the test is straightforward: ask whose roadmap the product follows. If the answer to what will this do next year depends on what a supplier in Redmond or Raleigh announces, the organisation is a channel, whatever appears on the building. The consequences accumulate quietly. Licence fees leave the region annually and permanently. The engineering labour market fills with people who configure rather than build, because those are the positions available. Graduates are trained accordingly. And the capability to make the next thing never forms, because capability is a by-product of having made the last one.
The argument is routinely misread, so it is worth stating plainly: the answer is not to build everything. That is a different and equally expensive failure, and a small country with a thin engineering labour market can afford it even less than a large one.
Context should be bought. An organisation writing its own database engine, identity provider, payroll system or operating system is indulging itself. The discipline lies in the separation: identify the narrow set of capabilities constituting the reason the organisation exists — what a customer chooses it for and cannot obtain from the supplier directly — and own those completely. Buy everything else deliberately, with exit paths costed, with data in formats under the organisation's control, and with an honest assessment of what is being surrendered.
That separation is an architectural judgement. It cannot be delegated to procurement, whose function is to buy well rather than to determine what should never be bought. It cannot be delegated to an IT function, because the response will return in the shape of a shortlist. It cannot be delegated to a supplier, for reasons requiring no elaboration. It belongs to enterprise architecture, exercised by someone with the standing to say not this one and be heard.
For a region to move from packaging to building — and no version of a technology economy here does not require exactly that — the architecture function must become something other than a framework administrator. Specifically, it requires:
The assignment of customer-facing product construction to functions and managers constituted for supplier management is a category error made at speed, in the belief that it is a resourcing decision. Its mechanisms of failure are predictable and enumerable, its transmission is a single appointment, and its aggregate effect over a region and a decade is an economy that operates other people's platforms competently while producing very little of its own.
The corrective is not a larger budget or a better supplier. It is the exercise of a judgement that already belongs to enterprise architecture: what differentiates must be owned, ownership must be placed where it can be held, and the person appointed to lead a build should have built something before. The next occasion on which someone says give it to IT is worth ten minutes of anyone's time, to ask which of the two professions the work requires, and whether the person about to be placed in charge has ever built and owned the kind of thing being asked for.