Before a new system becomes the centerpiece of a procurement brief, the team needs to explain what will change in everyday work. Where does the service fail today? Why can existing capabilities not meet the need? Who will own data, integration and operations after delivery? A sound purchase decision answers these questions before treating a new product as the solution.

An enterprise architecture review turns a product request into an explainable decision. It is most useful before requirements are fixed and a preferred product becomes synonymous with the solution. The decision card below is a proposed working practice to adapt to the organization’s scale and authorities. It is neither an official procurement requirement nor a substitute for purchasing approvals.

Describe the need before specifying the system

Ask the service owner to describe a concrete failure in today’s work. “Employees cannot see the latest approval without contacting three departments” is more useful than “We need a workflow system.” The first statement invites questions about responsibility, the source of status information and update frequency. The second jumps straight to a product category.

Record the user, the blocked step, the observable consequence and the person accountable for the outcome. Define what the initiative excludes. If the need is request tracking, do not add contract and inventory management simply because a vendor includes them. A feature’s availability is not evidence that it is needed. A short walkthrough of current work can establish the problem before anyone designs the future process.

The UK Technology Code of Practice [1] includes user needs, integration and purchasing strategy among its technology considerations. It is used here as an international practice reference, not as a procurement rule applicable to Saudi organizations.

Compare capabilities and realistic alternatives

An organization may already own part of the required capability without having suitable licensing, capacity or operating arrangements to extend it. A similar application in another department may not be reusable across the organization. Reuse therefore needs investigation rather than assumption.

Compare four paths: improve the process without a new system, activate or extend an existing system, reuse a shared service, or buy a new solution. For each, record the requirements it meets, the changes it needs and the limitations it leaves. Compare like-for-like scope: a software licence alone cannot fairly be compared with a proposal including integration, migration and support.

Official guidance on sharing and reuse [2] recommends considering existing technology before committing to a new project. Identifying a suitable asset and proving its fit remain local analytical tasks, not automatic consequences of that principle.

Four alternatives to compare against the same need; no route is universally best.

Map integration before discussing the interface

A convenient interface can hide dependencies missing from the project estimate. For every significant data exchange, show who creates the information, who owns updates, where it is approved and which system consumes it. Distinguish reading from writing, immediate exchanges from scheduled transfers, and reference data from operational transactions.

“The system supports APIs” does not settle integration readiness. Ask for a relevant exchange to be demonstrated, including connection failure, retry and conflicting updates. Identify who notices a failed exchange, where a pending transaction appears and how it is resumed. When another system must change, record the owner, estimated cost and availability of that change.

The official integration guidance [3] connects integration with the operating model, service management and required skills. Operations and data owners therefore need an early place in the review, while design choices remain open.

Review data, operations and cost together

Identify the data to migrate, its quality, correction authorities and the reconciliation needed before and after migration. Copying records will not resolve competing definitions of a customer, request or supplier. Agree the relevant meaning first. Security, privacy and hosting specialists should determine the requirements applicable to the organization and its data; one sector’s obligations should not be presumed universal.

Then examine operational readiness. Who administers accounts, approves changes, monitors service health and handles incidents? What training is needed? Describe transition from the current solution and the fallback if transition fails. Completion of implementation does not end responsibility for the system.

Separate initial investment from ongoing cost. Include applicable licensing, integration, migration, infrastructure, support, training, modifications and exit work. Do not silently enter zero for an unknown cost. Label it as an assumption requiring a quotation or a test, and explain how a different outcome could change the preferred option.

A conceptual illustration of data, integration and operational evidence. Actual evidence must be checked before a recommendation.

Connect the purchase to the Saudi organization’s requirements

Start with the organization, data and service involved. If the supplier will process personal data on the organization’s behalf, Article 8 of the Personal Data Protection Law requires the controller to select a processor offering the necessary guarantees and verify its compliance. In practice, request reviewable evidence about processing scope, access and further subcontracting. A supplier’s statement of compliance does not close the review. [4]

Cybersecurity controls have a defined scope. ECC 2-2024 covers government organizations and their affiliated entities, and private organizations that own, operate or host critical national infrastructure. The security team determines which controls apply within the organization; every requirement should not be presumed universal. [5] Record relevant sector and Digital Government Authority requirements in an organization-specific applicability register, with an accountable verifier. This decision card does not confer regulatory approval.

Turn the demonstration into an acceptance test

Before requesting proposals, describe essential requirements in a testable form. For example: “When the approval system is unavailable, the transaction remains traceable, a named operator receives an alert, and processing resumes without duplication when connectivity returns.” Set acceptable response times and test cases according to the service’s needs, rather than adopting a vendor’s generic success percentage.

Separate exclusion conditions from weighted preferences. A requirement essential to safe operation cannot be offset by a better-looking interface or a cheaper licence. Compare desirable features after the basic conditions are demonstrated. Retain the test result, environment, requirements version and acceptance owner, and repeat the relevant checks when a material assumption changes.

A needs, alternatives and integration decision card

Use the proposed card to expose open questions and assign responsibility. Supporting evidence can sit behind it; filling every cell with broad assurances adds little value.

Review area	Record before the decision	Expected evidence
Need	User, problem, outcome and boundaries	Current journey and observed failure
Alternatives	Process, existing, shared and new options	Comparison against the same requirements
Data	Source, owner, definition and migration	Short glossary and reconciliation plan
Integrations	Parties, direction, timing and failure handling	Flow diagram and test findings
Operations	Owner, support, access and skills	Responsibilities and operating plan
Cost and risk	Lifecycle costs and assumptions	Declared estimates and linked risks
Decision	Preferred route, conditions and exceptions	Dated decision and condition owners

 

A hypothetical example: a separate request platform

Consider a Saudi organization with an internal portal and an existing service management system. A department requests a separate platform because employees submit requests by email and call for progress updates. The review finds that the portal can already receive requests, but approval status is not displayed and responsibility for keeping it current is unclear.

The team compares extending the portal with purchasing a separate platform. The first option needs an approval integration and clarified responsibilities. The second needs that integration too, plus additional accounts, migration and support. These are hypothetical circumstances, not an RMG project, commercial quotation or claimed result.

Finding a similar function does not settle the decision. A limited test covers normal, rejected and delayed requests, as well as an interrupted connection. If the existing solution meets the need, the team can recommend extension subject to explicit conditions. If it fails a documented essential requirement, the purchase request becomes sharper: suppliers must demonstrate the missing capability instead of repeating general product features.

Finish with a decision that can be followed through

A review can recommend proceeding, proceeding with conditions, or further analysis. Give every condition an owner, a due point and closure evidence. “Consider integration” is not an actionable condition. Identify whether an unresolved assumption must be settled before tendering, contracting or deployment, within the organization’s delegated authorities.

Retain the rationale, rejected alternatives and exceptions alongside the requirements version used. Revisit affected findings when the scope, supplier, hosting model or data flow changes. To assess the review’s value, follow whether its assumptions held and which implementation changes emerged; the number of completed forms alone does not demonstrate decision quality.

RMG’s existing guide to operating an architecture office connects governance with solution design reviews and technology selection. This card applies that role specifically to the pre-purchase decision; its rationale and evidence can be retained in the office’s repository. [6]

As these questions recur across projects, solution reviews become a practical service of the architecture office. RMG’s enterprise architecture office service [8] covers establishing operating roles and procedures and documenting current and target states. This decision card can start a discussion about the capabilities your office needs to support clear, evidence-based purchasing decisions.

Sources and references

Accessed 27 September 2026. These references support the article; they are not certifications of a particular solution.