Two years ago, a transformation programme in this region typically started the same way: a bank would decide what it wanted to build, write a business case, get budget approval, and only then go looking for the people to build it. The enterprise architect, if one was hired at all, came in after the vendor was already chosen — brought on to make sense of a decision that had effectively already been made.
That order has flipped. On the mandates we're currently running, the enterprise architect is now one of the first hires on the programme, often arriving before the vendor shortlist even exists. That's not a small shift in sequencing. It's a shift in what banks think the hard part of transformation actually is.
The hard part isn't building anymore. It's choosing.
Most Gulf banks aren't short of vendors willing to build something. They're short of someone internal who can sit across a table from four different platform providers, each with a compelling demo and an aggressive timeline, and tell the board honestly which one will actually survive contact with the bank's existing core systems, regulatory obligations, and integration debt.
That's not a developer's job. It was never really meant to be. But for a long time, banks tried to get that judgment from whichever senior engineer was in the room, or worse, from the vendor doing the pitching. Neither produces a decision anyone can defend eighteen months later when the programme is behind schedule and someone in governance is asking who approved the architecture.
The banks getting this right aren't hiring architects to build things. They're hiring them to be the one person in the building who can say no to a vendor and make it stick.
What's actually changed in the requirement
The architects we're placing now look different from the ones banks hired five years ago. The brief has moved away from deep specialism in one platform or stack, and toward three things:
Vendor-neutral judgment. The ability to evaluate a core banking platform, a cloud migration path, or a data architecture proposal without a prior allegiance to any of them — and to say so plainly in a steering committee, even when it's not the answer the room wants.
Regulatory fluency. Not compliance box-ticking, but a working understanding of how central bank data residency rules, open banking mandates, and operational resilience requirements actually constrain what's buildable — before the RFP goes out, not after.
Stakeholder range. The same person needs to be technically credible enough to challenge a vendor's engineering lead, and commercially fluent enough to explain to a CFO why the cheaper option carries three times the integration risk.
What this means if you're considering a move
If you're an enterprise architect currently sitting inside a delivery team, reporting into a programme rather than shaping it, this shift is worth paying attention to. The mandates coming through now are earlier-stage, higher-influence, and — because of that — significantly better compensated than the architecture roles that used to sit two or three layers down a transformation programme's org chart.
The trade-off is that these roles ask more of you before you're hired, not after. Banks running this kind of search aren't looking for a CV that lists platforms. They're looking for someone who can walk into a feasibility conversation and change the outcome of it.