ARA02 Blue Prism ROM Architect: Legacy Exam and the ROM2 Path

ARA02 belongs to an earlier generation of Blue Prism certification. The Blue Prism Certified ROM Architect exam tested the original Robotic Operating Model and the governance, delivery, and organizational disciplines required to scale robotic process automation beyond a handful of isolated automations. That historical purpose remains useful, but candidates should not treat ARA02 as the current management certification. Blue Prism now presents ROM 2 Professional as the live certification for intelligent-automation operating-model leadership.

The distinction matters because the old exam and the current credential are not merely two labels for the same syllabus. ARA02 emphasized the original ROM structure, Centre of Excellence roles, governance, pipeline, delivery methodology, and enterprise RPA maturity. The current ROM 2 program reorganizes the operating model around five foundations—Strategy, Workforce, Design, Development, and Operations—and measures how those foundations support a modern automation capability. The broader Blue Prism certifications therefore provide the right context for interpreting this legacy page.

ARA02 was an operating-model exam, not a developer skills test

The historical ARA02 exam was aimed at people shaping how an automation program operates across an organization. Blue Prism's credential record described a 60-minute, 60-question multiple-choice exam covering the mandatory ROM concepts and delivery principles. The important knowledge was organizational: how sponsorship, governance, demand, delivery, controls, and operational ownership fit together. A candidate could understand process stages very well and still be weak on the questions ARA02 was designed to ask.

This is why ARA02 should not be studied like the Blue Prism Developer certification. Developers need to build reliable automations, but a ROM architect has to create conditions in which many developers, business owners, controllers, and support teams can work consistently. The operating model defines who makes decisions, how work enters the pipeline, what evidence is required, where responsibilities move between teams, and how automation remains controlled after deployment.

Strategy connects automation demand to measurable business outcomes

An automation program becomes fragile when it is driven only by a list of tasks that look easy to automate. A ROM architect needs a strategic frame: why the organization is investing in automation, which outcomes matter, what risk appetite is acceptable, and how investment decisions will be made. Strategy is therefore more than executive sponsorship. It translates business priorities into selection criteria that can be used repeatedly when departments compete for limited delivery capacity.

Candidates should understand the difference between an attractive demonstration and a scalable use case. A process with high transaction volume may be valuable, but volatility, poor data quality, unstable applications, unclear ownership, or weak controls can make it expensive to operate. A strong governance model asks about value, feasibility, complexity, controls, change frequency, and support burden before a process is committed to delivery. That discipline is one of the ideas that carries naturally from original ROM thinking into ROM 2.

Workforce design defines roles, authority, and accountability

Automation introduces a mixed workforce of business specialists, developers, process analysts, architects, controllers, infrastructure teams, security professionals, and operational support. The operating model needs to define how these roles collaborate without creating gaps in accountability. If every automation is 'owned by the automation team,' business accountability can disappear. If every decision is pushed back to the business, technical standards can fragment. The ROM architect creates explicit boundaries between sponsorship, process ownership, design authority, delivery, and operations.

This role design becomes especially important as a Centre of Excellence grows. A centralized team can preserve standards but become a bottleneck; a federated model can scale but produce inconsistent practices. Mature operating models often define which controls must remain common while allowing delivery activity to occur closer to business units. Study should therefore focus on why a role exists, what decisions it owns, and what evidence should be produced at handoffs—not simply on memorizing a chart of job titles.

Design governance turns principles into repeatable delivery decisions

The design layer protects the automation estate from one-off solutions that are difficult to support. It includes standards for solution architecture, reusable objects, credentials, exception behavior, queues, interfaces, logging, security, and nonfunctional requirements. A ROM architect does not replace the solution designer or technical architect; instead, the operating model establishes when those specialists must be involved and what approval or assurance is required.

That relationship is visible in the historical ASD01 Solution Designer exam and ATA02 technical architecture exam. Those credentials tested different technical disciplines, while ARA02 sat above them as an operating-model perspective. In a well-governed program, design review is not a ceremonial checkpoint at the end of development. It is a mechanism for catching risky assumptions before they become embedded in production.

Development governance should improve flow rather than add paperwork

A delivery method is useful only when it improves decisions and makes work visible. Original ROM material emphasized a controlled lifecycle from process discovery through definition, build, test, acceptance, deployment, and handover. The documents produced at each stage should answer real questions: What is in scope? Which applications are involved? What happens on exceptions? Who accepts the process? How will it be monitored? What is the rollback plan? A template with no decision behind it is administrative overhead, not governance.

Candidates should be able to recognize appropriate controls for different levels of risk and complexity. A small internal automation does not always need the same ceremony as a high-volume regulated process, but both need sufficient evidence for support and accountability. The operating model should make the lifecycle proportionate while preserving required security, testing, and release controls. This is one reason scenario practice is more useful than memorizing ROM terminology in isolation.

Operations determine whether automation value survives after go-live

Deployment is not the end of an automation program. Operational teams need monitoring, schedules, credentials, queue controls, incident procedures, capacity information, and clear escalation routes. When applications change, certificates expire, service accounts lock, or transaction patterns shift, automations can fail even though the original logic is correct. The ROM perspective treats these events as part of normal service management rather than as exceptional developer problems.

A mature model also separates business exceptions from platform or system incidents so that the right team responds. Business owners need visibility into rejected transactions and policy decisions; technical support needs diagnostic information about runtime resources, networks, application availability, and platform services. Metrics should reveal both business outcomes and operational health. High robot utilization alone is not proof of value if work is being retried, delayed, or corrected manually.

Maturity is a progression in capability, not a badge earned once

The enterprise maturity idea in the original ROM helps explain why organizations should not copy the governance of a large automation program on day one. Early programs are still establishing sponsorship, standards, skills, and confidence. As volume grows, the organization needs stronger portfolio management, reusable assets, architecture discipline, support structures, and measurement. Maturity is therefore visible in repeatable behavior and decision quality, not in the existence of a Centre of Excellence slide deck.

For exam preparation, compare how an organization would behave at different levels of maturity. Who selects opportunities? How consistent are design standards? Is operational support defined? Are benefits measured after deployment? Are controls dependent on individuals or embedded in repeatable processes? Thinking in those terms makes the operating model concrete and helps separate symptoms from root causes when a scenario describes an automation program that is growing faster than its governance.

ROM 2 Professional is the current certification reference

Blue Prism's current ROM 2 Professional exam has 60 questions, a 70-minute duration, and a scaled passing score of 600 or higher. Its content is organized across Strategy, Workforce, Design, Development, and Operations, with Workforce carrying the largest published weighting. Blue Prism recommends completing the corresponding ROM 2 learning plans in sequence. There is no formal prerequisite, which makes role experience and careful study of the current methodology especially important.

ROM 2 Professional is also different from Blue Prism's Developer, Professional Developer, and Technical Architect credentials in lifecycle policy. As of the 2026 certification renewal program, ROM 2 Professional does not expire, while the automation-development certifications moved to three-year validity from July 1, 2026. Candidates researching ARA02 should therefore use the historical page to understand the lineage, but use the live ROM 2 material for current exam scheduling, content, and credential rules.

A sensible study approach starts by mapping the old ARA02 concepts to the current operating-model language. Keep the enduring questions—governance, sponsorship, roles, demand, design assurance, controlled delivery, operations, and maturity—but do not assume old diagrams or exam logistics still govern the current credential. Build short scenario notes that explain which role owns a decision, what evidence is needed, and how a control prevents a specific risk. That method tests understanding rather than recognition.

The most useful legacy pages are the ones that explain what changed without erasing why the old certification existed. ARA02 represents the period when Blue Prism formalized enterprise RPA governance around the original ROM. ROM 2 Professional carries that concern forward in a reorganized framework for modern intelligent automation. Treating the two as a lineage, rather than pretending ARA02 is still the active exam, gives both historical candidates and new learners a clearer path.

Operating-model metrics should connect activity to outcomes

A mature automation program measures more than the number of processes delivered or digital-worker hours consumed. Those activity measures can help with capacity planning, but they do not show whether automation improved the business. A ROM architect should define benefit measures that relate to the original case: cycle time, error reduction, service availability, cost avoidance, compliance evidence, customer experience, or released human capacity. Benefits also need an owner who can verify them after deployment rather than assuming the business case becomes true automatically.

Metrics should expose risk as well as value. Repeated exceptions, manual interventions, aging queue items, failed schedules, and emergency changes can indicate that an apparently successful automation is expensive to operate. Reviewing those signals with business and technical owners creates a feedback loop for the pipeline and design standards. This measurement discipline is another way the operating model becomes a management system instead of a collection of delivery templates.