Article
Operators are not builders: why the region resells software instead of making it
A decision gets made in the region several times a month, usually in under an hour, and usually without anyone in the room recognising it as a decision at all.
The organisation has resolved to put a product in front of its customers. A portal, an app, 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 present: give it to IT. That is where the technical people are.
It is not a resourcing decision. It is a category error, and it is the single most consequential one being made in technology across the GCC today — because the department being handed the work is, in the overwhelming 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 is a substitute for the other. And the confusion between them is not confined to one badly run company: repeated across a region for fifteen years, it produces an economy that buys technology from the United States and Europe, wraps it, resells it, and adds almost nothing to what the region actually knows how to do.
Two professions that share a vocabulary
An IT engineering function is excellent at a specific and difficult set of things. It evaluates vendors and negotiates with them. It integrates systems that were never designed to meet. It runs identity, networks, endpoints, backups and the licence estate. It keeps an environment available, compliant, patched and within budget, and it absorbs the consequences when a supplier changes its terms. The people who do this well are genuinely skilled, and the good ones are worth a great deal — the skill is in judgement about other people’s products and in operating them under pressure.
A product engineering function is excellent at something else entirely. It makes a thing that did not previously exist, puts it in front of people who have the option of ignoring it, and then owns that thing for a decade — its data model, its failure modes, its migrations, its dependencies and its accumulating debt. The skill is in creation and in long custody.
The two share a vocabulary. Both talk about systems, architecture, releases, uptime, security and users. That shared vocabulary is precisely why executives who are not engineers cannot see the boundary, and why the person who could point it out — the enterprise architect — is so often either absent from the conversation or not listened to when present.
What actually goes wrong
The failure is not that IT people are less capable. It is that every reflex that makes an operations function excellent becomes a defect when it is pointed at a product.
The procurement reflex. In an IT function, the correct first question about any requirement is who sells this? Building something a vendor already supplies is waste, and an IT department that builds its own identity platform has failed at its job. In a product function, that same question is fatal, because the part of your product that matters is by definition the part nobody sells. Ask a procurement-shaped organisation to build a differentiator and it will assemble one from purchasable components and hand you something your competitor can buy on Tuesday.
Demand-taker versus bet-maker. IT exists to serve internal demand. Requirements arrive from the business, are triaged and are delivered; saying no to a business unit is politically expensive and culturally alien. A product requires the opposite: someone who forms a view about a customer, commits to it, and refuses ninety per cent of what is asked for 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 appear.
Captive users versus customers who can leave. Internal users have no alternative. They will tolerate an ugly interface, a slow workflow and an eleven-field form, because the alternative is not doing their job. This means an IT function can be genuinely excellent for twenty years without ever developing the muscle for adoption — without ever having to make something people choose. Point it at a paying customer and the gap appears immediately, in the numbers, and usually too late.
Cost centre versus investment. IT is funded to be minimised. Its budget is defended by reducing it, its projects are approved as capital with an end date, and its success looks like the same service for less money. A product is funded to compound — sustained investment, no end date, returns that arrive after the second or third year. Run a product through a cost centre’s funding model and it is cut in year two, precisely when it was about to become useful.
Change control versus continuous release. A mature IT function protects the estate with change windows, advisory boards and freeze periods — appropriate when a change carries risk and delivers no revenue. A product delivers value only by changing, and a change process designed to slow things down applied to a product that must learn weekly does not make the product safe. It makes it irrelevant.
A support contract versus a codebase. When bought software breaks, you raise a case with a vendor whose obligations are contractual. When your own product breaks in year four, there is no one to call. There is only whether the people who wrote it are still employed, whether anyone understood it, and whether it was built to be understood at all. 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, the refusal of shortcuts that a vendor’s engineers took for you invisibly.
Ladders, bands and the people you can hire. IT career ladders reward breadth across vendors and certification against products. Product engineering ladders reward depth in a domain and codebase, and sustained ownership. The pay bands differ, the interviews differ, the seniority signals differ. Put product engineering inside an IT function and you will hire on IT bands, interview for IT signals, and receive integrators — and 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.
And then the integrator. Since the function has no builders, the work goes to a systems integrator, which is a rational response to the position the organisation has put itself in. The product ships. But the knowledge of how it works leaves 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 exactly as much as it did at the start.
None of this is hypothetical, and none of it is unusual. It is the default outcome, and it follows inevitably from a single unexamined sentence: give it to IT.
The mechanism is a manager
All of this reaches the work through one person: an IT manager put in charge of building a product.
That is worth stating plainly, because it is where the abstraction becomes concrete. Departments do not make decisions; the person appointed to lead the programme does. And the person appointed is, almost always, whoever in IT is currently trusted with large budgets and difficult suppliers — which is exactly the wrong qualification, arrived at by exactly the reasoning that feels most responsible in the room.
An IT manager is good at genuinely hard things. Holding a supplier to a contract. Running a service desk to an SLA. Defending a budget through a cost round. Escalating to an account team at two in the morning and getting a result. These are real skills, and few executives can do them.
But hand that person a product and watch what they reach for, because they 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 ever been rewarded for completing. They will appoint an integrator, because engaging a supplier is how work gets done. And 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 thing underneath is being built in a way that will not survive its third year. Nobody is being deceived. There is simply no one present who can tell.
Then it compounds, in two directions.
They cannot hire builders, because they interview for the signals they know — tool familiarity, certification, estimate discipline, willingness to work to a plan. Strong product engineers interview poorly against that rubric. They ask about the customer, they push back on the plan, they want to know who owns the decision, and they are read as difficult. So they are screened out, in favour of someone who will be pleasant and deliver to a schedule. And because managers hire in their own image and are promoted by managers who were promoted the same way, the organisation’s stock of operators rises every year while its ability to recognise a builder decays. By the time someone senior finally asks why nothing good gets built here, the people who could have answered were rejected at second interview eight years ago.
And the vendor becomes the source of technical truth. When your own team cannot answer an architectural question, someone will — and it will be the account manager, whose answer is always sincere, frequently competent, and never against their own interest. This is the moment the roadmap quietly leaves the building. Everything downstream of it, including the strategy deck that gets presented to the board next year, is downstream of a supplier’s product plan.
None of this is a criticism of the individuals, most of whom are conscientious people doing their best in a position they did not design. It is a criticism of whoever appointed them, and of the architecture function that watched a customer-facing product be 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 what that person’s profession has trained them to do when the work becomes uncertain.
This is an enterprise architecture failure
Someone should have stopped that sentence, and the discipline whose job it is to stop it is enterprise architecture. This is what the function is for: to know which capabilities differentiate the business and which are context, to decide 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 happens here is not usually a failure of intent. In my experience it is some combination of three things.
The first is knowledge. A great many people carrying the title in this region have never built or run a software product, and cannot feel the difference between a system you operate and a system you own — because the distinction is not in any framework they were taught.
The second is influence. The architecture function sits three levels below the decision, produces recommendations rather than decisions, and is consulted after the sourcing route has been chosen. An advisory function that arrives after procurement has begun is decoration.
The third is will. Sometimes the architect knows exactly what is about to happen and does not say it, because the sponsor has already announced the programme, the integrator has already been briefed, and the cost of being right in the wrong meeting is higher than the cost of being quiet.
Underneath all three is what the discipline has been allowed to become. In too many organisations, enterprise architecture means administering TOGAF as a process and populating a Zachman grid as an ontology — a repository, a set of artefacts, a governance forum with attendance and no teeth. Both frameworks are useful; neither was ever meant to be the job. The job 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 last year is not underperforming — it is doing something other than architecture.
This is the same fault I wrote about in the previous article, one layer up. There, the damage came from splitting building from running inside a single product. Here, it comes from confusing the two functions at the level of the enterprise. In both cases the boundary was drawn by default, and in both cases the organisation lives inside it for a decade.
What the region ends up with
Multiply that decision across a market and you get the pattern the GCC has now: the region’s most visible technology companies are, at the layer that matters, distributors.
Take the flagship platform offerings out of Abu Dhabi. Core42’s sovereign public cloud is Microsoft Azure with a sovereignty and controls layer over it. Its sovereign private cloud, announced with Red Hat in May, is Red Hat OpenShift and Red Hat AI — which is to say IBM. Operating a hyperscaler’s platform under local control at national scale is genuinely difficult work, and the compliance and controls layer is real engineering by capable people. But look at what is owned. The cloud platform is Microsoft’s. The container platform is IBM’s. What is Emirati is the operations, the wrapper and the customer relationship. If either vendor changes its licensing — and Red Hat’s owner has changed licensing before, at some cost to people who had built on the assumption that it would not — the dependency runs in exactly one direction, and it is not a direction that can be argued with.
I am not arguing that these organisations cannot build. G42 plainly can, and has: Jais, the Arabic large language model developed with MBZUAI and Cerebras and released openly, is a real contribution — a thing that did not exist, made here, given to the world. That is exactly what building looks like.
And it is the exception that makes the point. Jais happened because somebody decided to build something that did not exist, funded it as a build, and staffed it with people whose profession is building. The commercial platform business was a separate decision, taken in the ordinary way, and was constituted to integrate. Same group, two decisions, two completely different outcomes for what the region ends up knowing. The difference between them was not capability or capital. It was an architectural choice about what would be owned.
The wider version of this is easy to spot once you know the tell: ask whose roadmap the product follows. If the answer to what will this do next year depends on what a vendor in Redmond or Raleigh announces, the organisation is a channel, whatever the logo on the building says. 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 jobs on offer. 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 thing.
Buying is not the problem
To be clear, because this argument is routinely misread: 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.
Buy the context. You should not be writing your own database engine, identity provider, payroll system or operating system, and an organisation that does is indulging itself. The discipline is in the separation: identify the narrow set of capabilities that constitute the reason your organisation exists — the thing a customer chooses you for and cannot get from the vendor directly — and own those completely. Buy everything else deliberately, with exit paths costed, with your data in formats you control, and with an honest view of what you are handing over.
That separation is an architectural judgement. It cannot be delegated to procurement, because procurement’s job is to buy well, not to decide what should never be bought. It cannot be delegated to an IT function, because the answer will come back shaped like a shortlist. And it cannot be delegated to a vendor, for reasons that need no elaboration. It belongs to enterprise architecture, exercised by someone with the standing to say not this one and be heard.
What this requires of the architecture function
If the region is going to move from packaging to building — and there is no version of a technology economy here that does not require exactly that — then the architecture function has to become something other than a framework administrator.
It needs architects who have built and run software products, because the distinctions in this article are not learnable from a syllabus. It needs a mandate that includes sourcing decisions and the appointment of the accountable leader, not just solution designs, and it needs to be present when the sponsor first says give it to IT, not after. It needs to produce decisions with owners, consequences and recorded reasoning, rather than artefacts. It needs the capability map to be honest about which capabilities are differentiating, and the organisational courage to fund and staff those differently from everything else. And it needs to accept that its output is measured in outcomes it changed, not documents it produced.
That is the work we do at Mamluk. Our enterprise architecture practice is built for exactly this class of decision: target-state and transition architectures that account for the operating model as well as the technology, build-versus-buy calls made on differentiation rather than convenience, vendor and platform selection with real exit paths costed, and second opinions on programmes already committed. We also work alongside in-house architecture teams to raise the practice itself — because a capable internal function that can make these calls without us is a better outcome for the client, and a better one for the region.
We are engineers who build and run our own products — our own cloud, our own Kubernetes distribution — inside this region and under its constraints. We know what it costs to own something rather than resell it, and we think it is the only thing worth advising anyone else to do.
The next time someone in your organisation says give it to IT, it is worth about ten minutes of everybody’s time to ask two questions. Which of the two professions does this work actually require? And has the person we are about to put in charge of it ever built and owned the kind of thing we are asking for? Asked early enough and answered honestly, those two questions are most of the difference between an organisation that builds something and one that becomes a reseller of somebody else’s future.
— Meezaan-ud-Din Abdu Dhil-Jalali Wal-Ikram, founder of Mamluk