How Should PIF Portfolio Company Technology Be Standardised?

The difficult portfolio decision is not whether to standardise technology. It is deciding where standardisation reduces cost, risk and duplication without forcing businesses with different operating models into the same architecture. Get that boundary wrong and pif portfolio company technology can become either fragmented beyond control or centralised beyond usefulness.

This matters because PIF's portfolio spans companies and ecosystems with materially different operating requirements. PIF itself describes separate investment portfolios and an ecosystem model covering multiple sectors, while portfolio-company performance remains subject to governance and shareholder oversight. A technology model therefore has to support portfolio-level discipline without assuming every company should operate identically. :contentReference[oaicite:0]{index=0}

For organisations evaluating how much capability should be shared across entities, the starting point is the operating model rather than the software catalogue. The wider context for that decision is covered through the PIF portfolio technology partner framework.

The PIF Portfolio Company Technology Problem

Technology standardisation becomes difficult when the portfolio contains companies at different stages of maturity. One entity may be building its core systems from the ground up, while another has years of ERP customisation, local integrations and established vendor contracts.

A third may operate critical infrastructure, while another runs consumer services or financial operations. Treating those organisations as one IT estate can create as many problems as allowing every company to design its technology independently.

The portfolio-level problem is therefore to identify which decisions benefit from common rules and which decisions require local discretion.

• Common standards: Policies or technical principles that every relevant entity should follow.

• Preferred platforms: Products selected for reuse where the business requirement is sufficiently similar.

• Shared services: Capabilities operated centrally for several entities rather than duplicated inside each company.

• Reference architectures: Approved patterns that companies can reuse without being forced onto one implementation.

• Controlled exceptions: Documented cases where an entity has a legitimate reason to diverge from the portfolio standard.

The aim is not maximum similarity. It is deliberate similarity where similarity creates value.

Before choosing platforms, the portfolio also needs a sequence for resolving current-state gaps, future architecture and investment priorities. That sequence can be structured through an it strategy roadmap rather than allowing individual procurement cycles to determine the architecture.

Standardise, Harmonise or Let It Diverge?

Not every technology decision deserves the same treatment. A useful portfolio model separates decisions into three categories: standardise, harmonise and allow divergence.

Standardise means using one required approach where fragmentation creates unacceptable cost, risk or operational complexity.

Harmonise means allowing several products or implementations while enforcing common data definitions, interfaces, security controls or operating principles.

Diverge means allowing the entity to select its own approach because local requirements outweigh the value of portfolio consistency.

This table prevents a common mistake: treating standardisation as a binary decision. The better question is what level of consistency each technology domain needs.

For example, two companies may operate different ERP products while still using the same chart-of-account mapping, supplier taxonomy, cybersecurity expectations and integration standards. That can produce more portfolio value than forcing an expensive ERP replacement solely to create visual uniformity.

If the organisation needs an independent way to classify these decisions, a portfolio assessment can compare cost, business differentiation, regulatory constraints, integration complexity and switching risk before any vendor mandate is issued. That type of decision framework fits within IT strategy consulting, but the matrix itself remains useful even when the portfolio performs the assessment internally.

Shared Services vs Federated Autonomy

Once the standardisation boundary is clear, the next question is who owns the capability.

A fully centralised model places technology decisions and operations under one portfolio-level authority. A fully decentralised model leaves almost everything to individual companies. Large portfolios normally need something between those extremes.

What Belongs in Shared Services?

Shared services work best when the service is repeatable, does not create competitive differentiation between portfolio companies and benefits materially from scale.

Possible candidates include identity services, cybersecurity monitoring, selected cloud governance, licence management, common integration components, service management tooling and specialist architecture capabilities.

The business case should still be tested. A central service that is slower or less accountable than the local capability it replaces can create hidden operating cost even if its procurement price looks lower.

Where Federated Autonomy Matters

Local teams should retain decision rights where technology is tightly coupled to the entity's operating model, sector requirements, customer proposition or regulatory environment.

Federation does not mean absence of governance. It means the central model specifies the boundaries while the portfolio company controls decisions inside those boundaries.

The relationship between central authority and entity-level accountability should be explicit: who sets architecture standards, who approves exceptions, who owns budgets and who is responsible when a shared service underperforms. Those questions are central to IT operating model design.

Common Platform Decisions Worth Centralising

Some platform decisions offer genuine portfolio benefits because duplication creates recurring cost without adding meaningful local differentiation.

Identity and Security

A common identity architecture can simplify employee movement, privileged-access governance and shared application access. Cybersecurity standards can also establish a portfolio baseline while allowing stricter controls where an entity's risk profile requires them.

Saudi regulatory applicability should still be assessed company by company. The National Cybersecurity Authority maintains several control frameworks, including Essential Cybersecurity Controls and Cloud Cybersecurity Controls, with the latter addressing responsibilities for both cloud providers and cloud tenants. A portfolio standard should therefore set a baseline without assuming every company has exactly the same regulatory scope. 

Cloud Architecture

Portfolio-wide cloud agreements may create commercial and governance advantages, but that does not mean every workload belongs on the same cloud service or deployment model.

A useful standard might define approved providers, identity patterns, logging, encryption, network connectivity, landing-zone requirements and cost tagging. Individual entities can then select services within that controlled environment.

Core Business Systems

ERP, CRM, HR and procurement systems require more caution. Centralisation becomes attractive because these platforms are expensive and often repeat similar processes, but implementation depth differs considerably between sectors.

A financial-services portfolio company, for example, may face technology and regulatory requirements that do not apply to a development, tourism or industrial entity. Where those differences materially change architecture, the sector-specific considerations covered in banking technology consulting saudi arabia should take priority over portfolio uniformity.

The portfolio should therefore centralise platforms only when the process itself is sufficiently common. Standardising the product while allowing every company to customise it heavily simply moves fragmentation inside the same vendor contract.

Procurement Leverage Across a Portfolio

Portfolio scale can create stronger procurement positions, but purchasing power should not become the only reason to standardise technology.

A group agreement can improve commercial terms, consolidate licence management and reduce repeated vendor evaluation. It can also create dependency if entities become locked into a product selected primarily for portfolio pricing.

Separate Commercial Consolidation From Technical Mandates

A portfolio can negotiate a preferred commercial arrangement without requiring every company to consume the same product.

This is particularly useful for cloud services, security products, professional services and enterprise software where demand is significant but operating requirements vary.

A strong framework agreement can establish:

• Pricing structure: Portfolio-level volume tiers and transparent discount mechanics.

• Service levels: Minimum support, escalation and availability commitments.

• Exit rights: Clear treatment of data extraction, transition and contract termination.

• Entity onboarding: A defined process for new companies joining the agreement.

• Security obligations: Common contractual requirements without weakening entity-specific controls.

• Consumption visibility: Reporting that shows spend and utilisation by portfolio company.

The correct level of centralisation can vary significantly between sectors. Comparing different operating environments through the industries we serve helps explain why a procurement standard should sometimes stop short of a technical mandate.

Portfolio advisory also does not always fit a one-off project. Architecture decisions, procurement exceptions and new-company onboarding may continue over time, so the choice between project work and standing support should be deliberate. The different it consulting engagement models help clarify that distinction.

Reporting Consolidation Across Entities

Technology standardisation often becomes most valuable at the reporting layer. Portfolio leaders need comparable information without forcing every operating company to run identical transaction systems.

The key is to standardise meaning before reporting tools.

If one entity defines active customers differently from another, putting both figures into the same BI platform does not make them comparable. The same problem appears in project status, procurement savings, IT cost, cybersecurity incidents, headcount and capital expenditure.

Build a Portfolio Data Contract

A portfolio data contract should define the measures that must be reported consistently and the minimum attributes supporting them.

• Metric definition: What exactly is being measured?

• Source ownership: Which system or function is accountable for the figure?

• Reporting frequency: When must the value be available?

• Data quality: What validation must occur before consolidation?

• Entity mapping: How are local structures translated into the portfolio model?

• Change governance: Who approves modifications to definitions?

This allows portfolio companies to retain legitimate local systems while still producing comparable management information.

The reporting architecture should also distinguish management consolidation from operational centralisation. A central dashboard does not require the central team to own the transaction system that produced the data.

A Staged Standardisation Approach

Trying to standardise the entire portfolio in one programme usually makes the scope too broad. A staged model allows the organisation to capture low-regret benefits before attempting expensive platform consolidation.

1. Map the current estate: Identify major platforms, contracts, integration dependencies, data ownership and support models across participating companies.

2. Classify technology domains: Decide which areas should be standardised, harmonised or left under controlled local autonomy.

3. Set portfolio principles: Define the minimum architecture, cybersecurity, data and procurement rules that apply across relevant entities.

4. Create exception governance: Allow justified divergence through a documented process with ownership and review dates.

5. Target repeatable wins: Start where duplicated spend or inconsistent controls create clear portfolio cost or risk.

6. Harmonise reporting: Establish common definitions before attempting to consolidate every underlying system.

7. Sequence platform migrations: Replace major systems only where the business case survives implementation cost, operational disruption and switching risk.

8. Review continuously: Reassess standards as new companies, technologies and regulatory requirements enter the portfolio.

The work does not necessarily end after the first roadmap. Portfolio-level technology decisions continue as entities mature, acquisitions change the estate and vendors introduce new options.

Where that creates a recurring advisory requirement rather than a single implementation project, engagement models and retainers can be assessed against the cadence of portfolio decisions rather than defaulting automatically to project-by-project procurement.

The sequence also matters. Moving directly from discovery into vendor selection can turn an architecture issue into a procurement exercise. A structured progression through requirements, evaluation, implementation and optimisation is set out in our five-stage methodology.

The practical objective is not to make every portfolio company look the same. It is to create a controlled technology environment in which common capabilities are genuinely reusable, local exceptions are intentional, reporting is comparable and procurement scale does not destroy operational fit.

That is the decision standard that should guide pif portfolio company technology: centralise where scale, control or shared information creates measurable value; harmonise where interoperability matters more than identical platforms; and allow divergence where the company's operating model genuinely requires it.

A useful final step is to build a one-page portfolio standardisation matrix covering the major technology domains, current platforms, target treatment, business owner, exception criteria and next decision date. It can be used internally as a governance tool or as the starting point for a scoping discussion before any major consolidation programme begins.

PIF Portfolio Company Technology FAQs for Standardisation Decisions

Should all PIF portfolio companies use the same technology platforms?

No. Common platforms make sense where requirements are genuinely similar and portfolio scale reduces cost or risk. Other areas may be better harmonised through common interfaces, data definitions or security standards. Sector-specific operational platforms should be allowed to differ when forcing one product would weaken functionality, regulatory alignment or the company's operating model.

What technology should be standardised across a portfolio first?

Start with areas where variation creates cost or control problems without providing meaningful business differentiation. Identity, cybersecurity baselines, selected collaboration services, architecture principles, integration standards and reporting definitions are often stronger early candidates than replacing every ERP or sector platform. The priority should follow measurable portfolio benefit rather than the visibility of the technology.

What is the difference between technology standardisation and harmonisation?

Standardisation requires entities to follow one defined platform, control or technical approach. Harmonisation allows different implementations while making critical elements compatible, such as data definitions, interfaces, identity standards or reporting rules. Harmonisation is useful when operating differences justify multiple systems but the portfolio still needs interoperability and comparable management information.

How should portfolio companies manage exceptions to technology standards?

Exceptions should be explicit rather than informal. The requesting company should document the business requirement, technical reason, risk, cost impact and expected duration of the exception. A portfolio architecture or governance function can approve it, set conditions and review it later. This prevents local autonomy from gradually becoming uncontrolled fragmentation.

Can technology procurement be centralised without forcing one platform?

Yes. A portfolio can negotiate framework agreements, support conditions, security terms and volume pricing while allowing companies to choose among approved options. This separates commercial leverage from architecture mandates. It is particularly useful when several companies have similar purchasing needs but different technical maturity, regulatory obligations or operating requirements.