Digital Strategy & Application Portfolio
What an organisation intends to run digitally and why: target architecture, roadmap, investment, ownership of each capability, deliberate reuse, and the technical debt already carried. Every system added carries a validation and support obligation for its whole life, and strategy is where that obligation is taken on deliberately rather than discovered later.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 23 LINKSAn application portfolio accumulates rather than being designed: each system was justified alone, and the ones that matter most are often those nobody remembers commissioning.
06 · QUALITY MATURITY — DIGITAL STRATEGY & APPLICATION PORTFOLIO, REACTIVE TO ADAPTIVE
Applications exist because someone needed them. There is no list, and spreadsheets performing GxP functions are invisible.
An application inventory exists, maintained by IT, covering what IT installed and missing what departments procured.
Every application touching a regulated record is inventoried with an owner, a GxP classification and a lifecycle position, including departmental and end-user computing.
Portfolio decisions are made deliberately — rationalise, retain, replace, retire — against overlap, risk and support position rather than against renewal dates.
New capability is assessed against the portfolio before procurement, so the estate is shaped rather than accumulated.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 4
Derived from the 4 standards SPEQ maps to this subject, across 4 regulatory bodies: FDA, EMA, ICH, ISPE.
RECORDS & OBJECTIVE EVIDENCE
- The application inventory with owner, GxP classification and lifecycle position
- Coverage of departmental and end-user computing performing regulated functions
- Portfolio decisions with their basis, including systems retired
- Overlap analysis where multiple systems perform the same regulated function
- Assessment records where new capability was placed against the existing estate
COMMON INSPECTION FINDINGS
- Spreadsheets performing GxP calculations or holding regulated records, outside any inventory
- Applications with no named business owner, leaving every control on them unassigned
- Two systems performing the same regulated function with different controls
- Systems past vendor support carrying regulated records with no plan
- New systems procured departmentally with no assessment against the estate
Every system is a permanent liability as well as a capability
A GxP system arrives with a validation package and then requires periodic review, change control, access management, backup verification, supplier assessment, patching and eventual retirement — for as long as it exists. That is a standing annual cost expressed in quality-organisation effort rather than licence fees, and it is almost never in the business case that justified the system.
The pattern that follows is predictable. Systems are added because each addition is individually justified, and are not retired because retirement is a project with no sponsor. A portfolio grows until the validation and periodic-review load exceeds what the quality organisation can perform properly, at which point the reviews become formalities and the estate is nominally compliant.
Retirement is the missing half of the lifecycle
Decommissioning a regulated system is genuinely harder than decommissioning an ordinary one, because the records have to remain retrievable for their full retention period in a form that preserves their integrity and audit trail. That is why systems stay running long after their function moved elsewhere — kept alive to serve read access to old records.
Planning the record disposition at implementation rather than at retirement is what avoids this: what will be migrated, what will be archived in a readable neutral format, what will be attested, and what the retrieval route will be once the application is gone. Decided upfront it is a design constraint; decided at retirement it is the reason the retirement does not happen.
Ownership per capability, or shadow systems
Where a needed capability has no owned system, it appears anyway — as a spreadsheet, a departmental database, or a cloud tool someone expensed. These shadow systems frequently hold GxP data, and they carry no validation, no access control, no backup and no audit trail, because nobody registered them as systems.
They are a symptom rather than a discipline problem. A shadow system exists because a real need was unmet by the sanctioned estate, and the durable remedy is to find the unmet need rather than only to remove the tool. Periodic discovery — asking what people actually use, without consequence for answering honestly — finds them; enforcement alone drives them further underground.
SPEQ interpretation — technical debt has a compliance form
Technical debt in a regulated estate is usually discussed in engineering terms: outdated frameworks, brittle integrations, unsupported versions. Its compliance form is more concrete and less discussed — systems whose validation documentation no longer describes them, whose supplier assessment predates two acquisitions, whose periodic review has been deferred twice, or whose vendor no longer provides the evidence the original assessment relied on.
That register is worth maintaining explicitly, because it is what turns a slow accumulation into a set of dated decisions. An estate where twelve systems have deferred reviews and three have withdrawn supplier evidence has a specific, addressable problem; the same estate described as carrying technical debt has an unfundable one.
FREQUENTLY ASKED
What does adding a GxP system actually commit an organisation to?
Periodic review, change control, access management, backup verification, supplier assessment, patching and eventual retirement, for as long as it exists — a standing annual cost in quality-organisation effort rather than licence fees, and one that is almost never in the business case.
Why are regulated systems so hard to retire?
Because the records must remain retrievable for their full retention period with integrity and audit trail intact, so systems stay alive purely to serve read access to old data. Planning record disposition at implementation — what migrates, what is archived in a neutral readable format, what the retrieval route will be — is what makes retirement possible later.
What causes shadow systems?
An unmet need. A spreadsheet or departmental database holding GxP data exists because the sanctioned estate did not cover something real. Enforcement alone drives them underground; periodic discovery that asks what people actually use, without consequence for answering honestly, finds them and points at the gap to fill.
What does technical debt look like in compliance terms?
Systems whose validation documentation no longer describes them, whose supplier assessment predates two acquisitions, whose periodic review has been deferred twice, or whose vendor has withdrawn the evidence the assessment relied on. Named that way it is an addressable list; called technical debt it is unfundable.