2026-0125 Solutions Architect (NS) - FRI 2 Oct EXTENDED AMENDMENT 1
EMW, Inc. · The Hague, South Holland, Netherlands ·
- Employment
- Contract
- Category
- Architecture
- Experience
- 4+ years
EMW, Inc. · The Hague, South Holland, Netherlands ·
Global Experience Specialists · Las Vegas, Nevada, United States
GES · Las Vegas, Nevada, United States
SimplifyNext · Singapore
Avomind · Guangzhou, Guangdong Province, China
BIDDING INSTRUCTIONS
1.1 Technical Proposal
Bidders shall include in the Technical Proposal a CV of the proposed candidate, clearly indicating relevant experience for the requirements (Section 3) and qualifications (Section 9) in the Statement of Work.
Bidders shall also include a compliance matrix referring how each candidate meets each of the stated requirements (Section 3) and qualifications (Section 9) of the Statement of Work, justified by relevant (project) experience.
Deadline Date: Friday 02 October 2026
Requirement: Solutions Architect – Amendment 1
Location: Off-site (80%), on-site in The Hague or Brussels (20%)
Period of Performance: Base: 11 November 2026 (Tentative) – 31 March 2027. Option: 01 April 2027 – 31 December 2027.
Required Security Clearance: NATO SECRET
1. INTRODUCTION
The NCIA Chief Technology Office requires Solutions Architect services to capture and document the as-is and to-be NATO Intelligence System Architecture as well as a roadmap for how to transition the as-is to the to-be architecture.
The services include the capturing of the current architecture through the delivery of an as-is architecture with generated documentation, the capturing of the to-be architecture as well as the implementation roadmap including transition architecture in order to assure future programmatic technical coherence. With a focus on documenting the architecture and engagement with all NATO Intelligence Enterprise key stakeholders, the services will ensure the delivery of high-quality technical products that align and will inform current and future NATO Intelligence Enterprise programmes.
2. SCOPE OF WORK
The purpose of this project is to provide the NATO Intelligence Enterprise (NIE) “as-is” and “to-be” architecture and implementation roadmap. To achieve this scope, the Contractor shall:
3. DELIVERABLES
3.1 “As-Is” Architecture
The Contractor shall deliver the “as-is” NIE architecture models, which comprise Application Architecture, Business Architecture, Technical Architecture, and Data/Information Architecture. The metamodel guiding the architecture models will be provided upon onboarding.
The “as-is” architecture report will, to the maximum extent, be generated from the architecture models. The report shall cover the following areas:
Executive Summary
Description: Brief overview of the goals and objectives, stakeholders, architecture views and scope.
KPIs: 100% coverage of goals, objectives, scope, stakeholders and required architecture views.
Acceptance Evidence: Approved scope checklist, traceability links, review record and editable source.
Accept When: Decision-focused summary is complete, consistent with the package and approved by the Purchaser PM and Lead Architect.
Current Architecture Overview
Description: High-level description of the current NIE architecture / NISA.
KPIs: KPI 1 — 100% of in-scope domains, boundaries, external actors, key dependencies and integration points represented against the baseline inventory. KPI 2 — 100% of overview views reviewed by designated domain SMEs; 0 unresolved Critical or Major modelling inaccuracies.
Acceptance Evidence: Context/dependency views, inventory reconciliation and SME validation log.
Accept When: Views describe the current state, agree with domain models and contain no unapproved future-state content.
Stakeholders and Roles
Description: List of stakeholders and their roles and responsibilities.
KPIs: KPI 1 — 100% of identified stakeholder groups have role, responsibility, interest and required architecture input/output recorded. KPI 2 — 100% of key architecture activities have exactly one Accountable party and at least one Responsible party; 0 RACI gaps or duplicate accountability.
Acceptance Evidence: Stakeholder register, RACI and stakeholder review record.
Accept When: Named functions are current, responsibilities are unambiguous and the designated governance authority approves the RACI.
Application Architecture
Description: Appropriate views with narratives about existing applications, their software components, interfaces, related standards, and dependencies between the applications.
KPIs: KPI 1 — 100% of in-scope applications, components, interfaces, standards and dependencies modelled; at least 95% of mandatory attributes complete. KPI 2 — 100% of critical interfaces record source, target, protocol, exchanged information and security/trust dependency; 0 orphan critical applications.
Acceptance Evidence: Application catalogue, interface matrix, diagrams, model export and reconciliation report.
Accept When: Catalogue and models are mutually consistent, traceable to inventory and approved by application/integration SMEs.
Technical Architecture
Description: Description of the infrastructure services, networks and connectivity, platform services, middleware as they are relevant for the deployment and hosting of the applications.
KPIs: KPI 1 — 100% of relevant infrastructure, network/connectivity, hosting, platform and middleware services documented and linked to deployed applications. KPI 2 — 100% of critical hosting/network paths validated; at least 95% of mandatory technical attributes complete; 0 unresolved Critical or Major inaccuracies.
Acceptance Evidence: Deployment, network and service views; configuration/source references; SME validation log.
Accept When: Models reflect the current technical state and reconcile application deployment with platforms, zones and connectivity.
Pain Points and Limitations
Description: Identified issues, bottlenecks, risks, and gaps in the current architecture.
KPIs: 100% of identified pain points are recorded with description, affected capability/system/process, severity, impact, owner, source, and proposed disposition.
Acceptance Evidence: Pain point register, gap analysis, risk/issues log, stakeholder interview records, incident/problem reports, operational feedback, architecture assessment findings, technical debt register, and traceability matrix.
Accept When: Pain points are complete, evidence-based, prioritised, traceable to the current architecture, and agreed by relevant SMEs and stakeholders; all Critical and Major items have an approved mitigation, target-state response, or formal risk acceptance.
Compliance and Standards
Description: International and/or existing NATO standards; adherence status.
KPIs: KPI 1 — 100% of applicable compliance obligations and architecture standards identified, assigned to architecture areas, and traced to controls, requirements, or design decisions. KPI 2 — 100% of deviations, waivers, or non-compliances documented with justification, risk impact, owner, and approval status.
Acceptance Evidence: Compliance matrix, standards applicability assessment, waiver/deviation register, requirements traceability matrix, and review/approval records.
Accept When: Compliance position is clear, traceable, approved by the relevant authority, and all mandatory standards are either satisfied or formally waived.
Appendix
Description: Diagrams, glossary, references, and supporting documents.
KPIs: KPI 1 — 100% of referenced diagrams, models, terms, acronyms, standards, and source documents included or linked. KPI 2 — 100% of architecture diagrams have title, version, owner, date, classification/handling marking where applicable, and source reference.
Acceptance Evidence: Diagram pack, glossary, acronym list, reference list, assumptions/constraints log, model exports, document control record, and repository links.
Accept When: Supporting material is complete, controlled, versioned, accessible to authorised stakeholders, and consistent with the main architecture document.
3.2 “To-Be” Architecture
The “to-be” architecture shall be based upon existing and future NIE systems/applications, data sharing architecture and infrastructure. The “to-be” architecture shall:
The Contractor shall deliver the “to-be” NIE architecture models, which comprise Application Architecture, Business Architecture, Technical Architecture, and Data/Information Architecture. The metamodel guiding the architecture models will be provided upon onboarding.
The “to-be” architecture report will, to the maximum extent, be generated from the architecture models. The report shall cover the following areas:
Executive Summary
Description: Overview of the future architecture vision and objectives.
KPIs: 100% coverage of goals, objectives, scope, stakeholders and required architecture views.
Acceptance Evidence: Approved scope checklist, traceability links, review record and editable source.
Accept When: Decision-focused summary is complete, consistent with the package and approved by the Purchaser PM and Lead Architect.
Future Architecture Overview
Description: High-level description of the future system architecture; identify new components, and components from the as-is architecture that can be reused or need to be modified.
KPIs: KPI 1 — 100% of in-scope domains, boundaries, external actors, key dependencies and integration points represented against the baseline inventory. KPI 2 — 100% of overview views reviewed by designated domain SMEs; 0 unresolved Critical or Major modelling inaccuracies.
Acceptance Evidence: Context/dependency views, inventory reconciliation and SME validation log.
Accept When: Views describe the current state, agree with domain models and contain no unapproved future-state content.
Target Stakeholders and Roles
Description: List of target stakeholders including future users, associated locations, and their expected roles.
KPIs: KPI 1 — 100% of identified stakeholder groups have role, responsibility, interest and required architecture input/output recorded. KPI 2 — 100% of key architecture activities have exactly one Accountable party and at least one Responsible party; 0 RACI gaps or duplicate accountability.
Acceptance Evidence: Stakeholder register, RACI and stakeholder review record.
Accept When: Named functions are current, responsibilities are unambiguous and the designated governance authority approves the RACI.
Application Architecture
Description: High-level description of planned applications, their functions, interfaces, and dependencies.
KPIs: KPI 1 — 100% of in-scope applications, components, interfaces, standards and dependencies modelled; at least 95% of mandatory attributes complete. KPI 2 — 100% of critical interfaces record source, target, protocol, exchanged information and security/trust dependency; 0 orphan critical applications.
Acceptance Evidence: Application catalogue, interface matrix, diagrams, model export and reconciliation report.
Accept When: Catalogue and models are mutually consistent, traceable to inventory and approved by application/integration SMEs.
Technology Architecture
Description: Target application technology.
KPIs: KPI 1 — 100% of relevant infrastructure, network/connectivity, hosting, platform and middleware services documented and linked to deployed applications. KPI 2 — 100% of critical hosting/network paths validated; at least 95% of mandatory technical attributes complete; 0 unresolved Critical or Major inaccuracies.
Acceptance Evidence: Deployment, network and service views; configuration/source references; SME validation log.
Accept When: Models reflect the current technical state and reconcile application deployment with platforms, zones and connectivity.
Security Architecture
Description: Planned security controls, risk mitigations, and compliance.
KPIs: KPI 1 — 100% of in-scope systems, applications, interfaces, data flows, and hosting zones mapped to applicable security controls and trust boundaries. KPI 2 — 100% of identified Critical and High risks have an approved mitigation, acceptance, transfer, or treatment plan; 0 unresolved Critical security gaps.
Acceptance Evidence: Security architecture views, risk register, control traceability matrix, threat model, data classification mapping, security requirements, and security SME review record.
Accept When: Security controls and risk treatments are complete, traceable to requirements and standards, and approved by the Security Authority or designated security governance body.
Integration Architecture
Description: Future integration methods, APIs, middleware, and interoperability.
KPIs: KPI 1 — 100% of internal and external integration points documented with source, target, protocol, data exchanged, frequency, ownership, security classification, and error-handling approach. KPI 2 — 100% of critical integrations mapped to approved integration patterns, standards, and interoperability requirements.
Acceptance Evidence: Interface control documents, API catalogue, integration matrix, sequence/data-flow diagrams, interoperability assessment, and SME validation log.
Accept When: Integration architecture is complete, technically feasible, aligned with approved standards, and approved by integration, application, and security SMEs.
Compliance and Standards
Description: Future compliance requirements and alignment strategy.
KPIs: KPI 1 — 100% of applicable compliance obligations and architecture standards identified, assigned to architecture areas, and traced to controls, requirements, or design decisions. KPI 2 — 100% of deviations, waivers, or non-compliances documented with justification, risk impact, owner, and approval status.
Acceptance Evidence: Compliance matrix, standards applicability assessment, waiver/deviation register, requirements traceability matrix, and review/approval records.
Accept When: Compliance position is clear, traceable, approved by the relevant authority, and all mandatory standards are either satisfied or formally waived.
Appendix
Description: Diagrams, glossary, references, and supporting documents.
KPIs: KPI 1 — 100% of referenced diagrams, models, terms, acronyms, standards, and source documents included or linked. KPI 2 — 100% of architecture diagrams have title, version, owner, date, classification/handling marking where applicable, and source reference.
Acceptance Evidence: Diagram pack, glossary, acronym list, reference list, assumptions/constraints log, model exports, document control record, and repository links.
Accept When: Supporting material is complete, controlled, versioned, accessible to authorised stakeholders, and consistent with the main architecture document.
3.3 Implementation Roadmap
The main deliverable is the implementation roadmap that aims at identifying the transition from the “as-is” architecture to the “to-be” architecture. The implementation roadmap shall enable the ability to deliver faster, identifying quick wins as well as long-term strategies. The implementation roadmap shall address the following areas:
Gap Analysis
Description: Compare as-is and to-be to highlight what needs to change.
KPIs: KPI 1 — 100% of in-scope as-is and to-be architecture elements are compared and assigned a gap status: unchanged, reused, modified, replaced, retired, or new. KPI 2 — 100% of identified gaps have documented impact, priority, owner, target resolution approach, and traceability to requirements, pain points, risks, or target architecture objectives.
Acceptance Evidence: Gap register, as-is/to-be comparison matrix, capability heat-map, application/technology disposition matrix, traceability matrix, and SME review record.
Accept When: Gaps are complete, prioritised, evidence-based, traceable to both baseline and target architecture, and agreed by relevant SMEs and governance authority.
Initiatives / Projects
Description: Group related changes into programmes/projects.
KPIs: KPI 1 — 100% of approved gaps and target-state changes are mapped to at least one initiative, project, work package, or explicit no-action decision. KPI 2 — 100% of initiatives include objective, scope, expected outcome, owner, impacted domains, estimated effort, indicative cost, benefits, dependencies, risks, and target phase.
Acceptance Evidence: Initiative register, programme/project mapping, work package descriptions, benefits map, gap-to-initiative traceability matrix, and governance review record.
Accept When: Initiatives are complete, non-overlapping, traceable to architecture gaps and objectives, and approved by the portfolio/programme governance authority.
Dependencies
Description: Identify dependencies on external projects.
KPIs: KPI 1 — 100% of initiatives and roadmap phases have dependencies identified, classified, and assigned an owner. KPI 2 — 100% of Critical and Major dependencies include impact, required date, delivery owner, mitigation or contingency, and monitoring status.
Acceptance Evidence: Dependency register, integrated master schedule, project interface agreements, external project mapping, RAID log, supplier/third-party inputs, and governance records.
Accept When: Dependencies are complete, validated with dependency owners, reflected in the roadmap schedule, and actively managed through an agreed governance mechanism.
Roadmap Phases
Description: Prioritize based on value, feasibility, and dependencies. Define clear phases or waves for implementation, identifying quick wins (low effort, high impact), foundational work (e.g., data governance, cloud infrastructure) and major transformations (new core system, process re-engineering). Provide milestones and timeline.
KPIs: KPI 1 — 100% of initiatives are assigned to a roadmap phase/wave with sequencing rationale, priority, dependency alignment, and expected outcome. KPI 2 — Each phase identifies quick wins, foundational activities, major transformation activities where applicable, entry/exit criteria, and measurable benefits.
Acceptance Evidence: Phased roadmap, prioritisation matrix, value/feasibility assessment, dependency mapping, benefit realisation plan, sequencing rationale, and governance review record.
Accept When: Roadmap phases are realistic, prioritised, dependency-aware, benefit-led, and approved by architecture and delivery governance stakeholders.
Milestones and Timeline
Description: Gantt chart or timeline view of key activities; milestones for each work stream or phase.
KPIs: KPI 1 — 100% of roadmap phases and initiatives have start/end windows, key milestones, decision gates, dependencies, and accountable owners recorded. KPI 2 — 100% of milestones have measurable completion criteria, planned date, owner, dependency linkage, and status.
Acceptance Evidence: Gantt chart, integrated roadmap timeline, milestone register, workstream plan, dependency schedule, baseline schedule, and approval record.
Accept When: Timeline is complete, internally consistent, dependency-aware, agreed by delivery owners, and baselined under the relevant programme or portfolio governance process.
Risks
Description: Identify top risks and mitigation plans.
KPIs: KPI 1 — 100% of roadmap initiatives and phases are assessed for key implementation, technical, security, operational, schedule, cost, and organisational risks. KPI 2 — 100% of High and Critical risks have owner, likelihood, impact, mitigation, contingency, due date, residual risk rating, and escalation path.
Acceptance Evidence: Risk register, RAID log, mitigation plans, security/accreditation risk inputs, dependency risk assessment, issue logs, and risk review records.
Accept When: Risks are complete, prioritised, actively owned, linked to roadmap items, and all High/Critical risks have approved mitigations, contingency plans, or formal acceptance.
Appendix
Description: Diagrams, glossary, references, and supporting documents.
KPIs: KPI 1 — 100% of referenced diagrams, registers, matrices, models, schedules, terms, acronyms, standards, and source documents are included or linked. KPI 2 — 100% of supporting artefacts have title, version, owner, date, classification/handling marking where applicable, and source reference.
Acceptance Evidence: Diagram pack, glossary, acronym list, reference list, assumptions and constraints log, model exports, roadmap source files, document control record, and repository links.
Accept When: Supporting material is complete, controlled, versioned, accessible to authorised stakeholders, and consistent with the roadmap document.
Option 2027
Period of performance: 01.04.2027 – 31.12.2027
3.4 “As-Is” Minimum Viable Architecture (MVA) of Intelligence & ISR Capabilities
This deliverable pulls through stakeholder evidence, source documentation, current system knowledge, and architecture model content into a coherent baseline of the current Intelligence & ISR capability landscape.
Key activities include confirming scope and boundaries, conducting stakeholder interviews and SME reviews, capturing current applications and capability dependencies, documenting technical and data/information context, identifying interfaces and standards, recording pain points and limitations, and producing the draft and final as-is architecture report and models with traceability to evidence and review comments. These activities are iterating on the deliverables provided during the Base period.
As-Is MVA – Scope, Stakeholders, and Evidence Baseline
Description: Define the Intelligence & ISR as-is MVA scope, stakeholders, source material, assumptions, constraints, and evidence baseline for current NIE / NISA capabilities.
KPIs: Scope statement agreed with NCIA; stakeholder register covers all NCIA-identified stakeholder groups; 100% of source artefacts logged; assumptions and constraints recorded with owner or disposition.
Acceptance Evidence: NCIA accepts the scope baseline; source register, stakeholder register, assumptions log, and evidence pack are delivered in editable form.
Accept When: As above (see Acceptance Evidence).
As-Is MVA – Current Capability and Application Architecture
Description: Capture current Intelligence & ISR capabilities, applications, functions, interfaces, dependencies, standards, and high-level service relationships.
KPIs: At least 90% of NCIA-identified in-scope systems and capabilities captured; 100% of agreed mandatory current-state application views produced; all critical interfaces and dependencies recorded.
Acceptance Evidence: Draft as-is application views, catalogue, and interface/dependency register are delivered; SME review comments are logged and traceable to updates or dispositions.
Accept When: As above (see Acceptance Evidence).
As-Is MVA – Technical, Data, and Operating Context
Description: Document current hosting, platform, network, middleware, data/information flows, deployment context, operating constraints, and relevant technical standards.
KPIs: 100% of agreed technical and data/information views produced; critical hosting, network, data-flow, and interoperability constraints identified; standards applicability recorded.
Acceptance Evidence: NCIA confirms technical and data context coverage; model exports, diagrams, standards matrix, and supporting notes are delivered in the agreed toolset/template.
Accept When: As above (see Acceptance Evidence).
As-Is MVA – Pain Points, Gaps, and Limitations
Description: Identify current pain points, architecture limitations, risks, technical debt, capability gaps, and improvement opportunities.
KPIs: Pain points include description, affected capability/system/process, severity, impact, owner or source, and disposition; all agreed high-priority gaps linked to affected architecture elements.
Acceptance Evidence: Pain point register, gap register, and risk/issues log are delivered; NCIA confirms that material issues raised by stakeholders are captured or dispositioned.
Accept When: As above (see Acceptance Evidence).
3.5 “To-Be” MVA of Intelligence & ISR Capabilities (NATO Intelligence Systems Architecture), in Line with NATO’s Digital Transformation Implementation Strategy
This deliverable consists of the as-is findings, NATO strategic direction, Digital Transformation Implementation Strategy alignment, architecture principles, standards, and stakeholder priorities into a target-state NISA architecture.
Key activities include defining the target architecture vision and principles, identifying reusable, modified, new, replaced, and retired components, designing target application, technical, data, integration, security, and interoperability views, assessing alignment with data-centricity, cloud-readiness, Zero Trust, open standards, and federation needs, and producing the draft and final to-be architecture report and models with documented assumptions, decisions, and review dispositions.
To-Be MVA – Target Architecture Vision and Principles
Description: Define the to-be Intelligence & ISR MVA / NISA target architecture vision, scope, architecture principles, and alignment with NATO’s Digital Transformation Implementation Strategy.
KPIs: Target vision and principles agreed with NCIA; 100% of strategic alignment claims traced to agreed principles or source references; target scope maps to as-is scope and agreed exclusions.
Acceptance Evidence: NCIA accepts the target architecture scope and principles; alignment rationale, assumptions, and decision log are delivered.
Accept When: As above (see Acceptance Evidence).
To-Be MVA – Target Application, Technical, and Data Architecture
Description: Describe future applications, reusable components, modified or new capabilities, target technologies, data-centric architecture, integration patterns, and hosting/platform approach.
KPIs: 100% of agreed target application, technical, and data/information views produced; all critical target interfaces and dependencies documented; target elements classified as reused, modified, replaced, retired, or new.
Acceptance Evidence: Draft to-be models and report sections are delivered; NCIA confirms that target-state views are understandable, internally consistent, and traceable to as-is findings.
Accept When: As above (see Acceptance Evidence).
To-Be MVA – Security, Interoperability, and Standards Alignment
Description: Document target security controls, trust boundaries, interoperability approach, standards alignment, cloud-readiness, data exchange patterns, and Zero Trust considerations.
KPIs: Security and interoperability considerations covered for all in-scope critical systems, interfaces, and data flows; standards obligations and deviations recorded; Zero Trust and data-centric principles addressed.
Acceptance Evidence: Security, interoperability, and standards views/registers are delivered; SME comments are logged; deviations, risks, and assumptions are traceable.
Accept When: As above (see Acceptance Evidence).
To-Be MVA – Gap Disposition and Transition Implications
Description: Map as-is findings to to-be architecture decisions and identify transition implications for the roadmap.
KPIs: 100% of agreed as-is gaps mapped to a target disposition or no-action decision; all major target changes linked to affected capabilities, systems, dependencies, and risks.
Acceptance Evidence: Gap disposition matrix and traceability matrix are delivered; NCIA confirms the target architecture can be used as input to roadmap planning.
Accept When: As above (see Acceptance Evidence).
Working-Practice Support – Stakeholder Interviews and Workshops
Description: Plan, conduct, and document stakeholder interviews, workshops, and SME reviews needed to produce the as-is MVA, to-be MVA, and roadmap.
KPIs: Approximately 20 stakeholder interviews or equivalent sessions completed; 100% of completed sessions have notes, date, attendees or roles, topics, and follow-up actions recorded.
Acceptance Evidence: NCIA accepts the engagement log and evidence pack; stakeholder inputs are traceable to architecture content, roadmap items, or explicit dispositions.
Accept When: As above (see Acceptance Evidence).
Working-Practice Support – Review, Issue, and Decision Management
Description: Maintain the working cadence, review records, action log, issue log, decision log, and deliverable status reporting during active delivery.
KPIs: Deliverable status updated at least weekly; 100% of review comments assigned status and disposition; open actions and decisions include owner, due date, and current status.
Acceptance Evidence: NCIA accepts the review and governance records; no unresolved Critical review comments remain at final acceptance without agreed waiver or deferral.
Accept When: As above (see Acceptance Evidence).
3.6 Roadmap Iteration
This deliverable pulls through the agreed as-is baseline and to-be target architecture into an actionable transition path for implementation planning and governance. Key activities include comparing current and target states, documenting gaps and dispositions, grouping changes into initiatives or work packages, identifying dependencies and accountable roles, sequencing quick wins, foundational work, and longer-term transformations, defining milestones and decision gates, assessing implementation risks and mitigations, and producing a final roadmap that is traceable to architecture findings and usable for programme planning.
Roadmap – Gap Analysis and Initiative Definition
Description: Compare as-is and to-be architectures and group required changes into initiatives, projects, work packages, or explicit no-action decisions.
KPIs: 100% of agreed gaps mapped to a roadmap item or no-action decision; initiatives include objective, affected capability/system, expected benefit, dependencies, and owner or accountable role where known.
Acceptance Evidence: Gap register, initiative register, and as-is/to-be comparison matrix are delivered; NCIA confirms that roadmap scope is traceable to architecture findings.
Accept When: As above (see Acceptance Evidence).
Roadmap – Sequencing, Milestones, and Dependencies
Description: Define transition phases, sequencing rationale, milestones, decision gates, dependencies, quick wins, foundational work, and longer-term transformation steps.
KPIs: Roadmap includes phases, milestones, dependencies, decision gates, accountable roles, and measurable completion criteria; initiatives prioritised by value, feasibility, risk, and dependency constraints.
Acceptance Evidence: Final roadmap timeline or Gantt view is delivered; NCIA confirms the sequencing is understandable, actionable, and aligned with known programme constraints.
Accept When: As above (see Acceptance Evidence).
Roadmap – Implementation Risks and Controls
Description: Identify implementation, technical, security, operational, schedule, cost, organisational, and dependency risks with proposed mitigations.
KPIs: High and Critical risks include owner, likelihood, impact, mitigation, contingency, due date, residual rating, and escalation path; risks linked to affected roadmap items.
Acceptance Evidence: Risk register and RAID inputs are delivered; NCIA confirms that material roadmap risks and dependencies are captured and usable for governance.
Accept When: As above (see Acceptance Evidence).
Final As-Is Baseline – Report, Model, and Review Closure
Description: Finalise the as-is MVA report and architecture models, incorporating NCIA review feedback and establishing the approved current-state baseline.
KPIs: 100% of accepted review comments incorporated or formally dispositioned; no open Critical or High severity content defects; final report and model export are internally consistent.
Acceptance Evidence: NCIA accepts the final as-is report and models; final package includes review disposition log, appendices, references, glossary/acronyms, assumptions, constraints, and traceability evidence.
Accept When: As above (see Acceptance Evidence).
Final To-Be Baseline – Report, Model, and Review Closure
Description: Finalise the to-be MVA / NISA report and architecture models, incorporating NCIA review feedback and establishing the approved target-state baseline.
KPIs: 100% of accepted review comments incorporated or formally dispositioned; no open Critical or High severity content defects; target architecture is traceable to agreed principles, standards, gaps, and roadmap initiatives.
Acceptance Evidence: NCIA accepts the final to-be report and models; final package includes strategic alignment evidence, architecture decisions, standards traceability, appendices, references, glossary/acronyms, assumptions, and constraints.
Accept When: As above (see Acceptance Evidence).
3.7 Requirements
All the documentation provided under this Statement of Work will be based on NCIA templates and/or agreed with the NCIA project manager.
Architecture views/artefacts need to be captured using agreed architecture language and tools.
All support, maintenance, and documentation will be stored under configuration management and/or in the provided NCIA tools.
The reports shall remain a high-level overview of the system/service capabilities.
4. SCHEDULE OF PAYMENT
This task order will be active immediately after signing of the contract by both parties.
The Base period of performance is as soon as possible but not later than 11.11.2026 (Tentative) and will end no later than 31 March 2027. The Option 2027 period of performance is 01.04.2027 – 31.12.2027.
Payments shall be dependent upon the successful acceptance of each deliverable. All invoices shall be accompanied with a Delivery Acceptance Sheet (DAS) signed by the Contractor and the project authority.
In 2026, the following deliverables are expected from the service, with T0 being the start of the Contractor’s work (estimated no later than 11.11.2026):
Base
Deliverable D01: Initial “as-is” architecture report and architecture models – Draft
Timeline: Q4 2026 Base
Acceptance Criteria: An “as-is” draft report and architecture models that fit the description and requirements described in Section 3.1.
Deliverable D02: Initial “to-be” architecture report and model – Draft
Timeline: Q1 2027 Base
Acceptance Criteria: A “to-be” draft report and architecture models that fit the description and requirements described in Section 3.2.
Deliverable D03: Initial roadmap from “as-is” to “to-be” architecture
Timeline: Q1 2027 Base
Acceptance Criteria: Implementation roadmap structured as defined in Section 3.3.
Deliverable D04: Refined “as-is” and “to-be” architecture artefacts
Timeline: Q1 2027 Base
Acceptance Criteria: An “as-is” final report and architecture models that fit the description and requirements described in Section 3.1.
Deliverable D05: Architecture transition roadmap, outlining the steps required to move from the “as-is” to the “to-be” architecture
Timeline: Q1 2027 Base
Acceptance Criteria: A “to-be” final report and architecture models that fit the description and requirements described in Section 3.2.
Option 2027
Deliverable D01: “As-is” Minimum Viable Architecture (MVA) of Intelligence & ISR capabilities
Timeline: Q2 2027 Base
Acceptance Criteria: An “as-is” Minimum Viable Architecture (MVA) that fits the description and requirements described in Section 3.4.
Deliverable D02: “To-be” MVA of Intelligence & ISR capabilities (NATO Intelligence Systems Architecture), in line with NATO’s Digital Transformation Implementation Strategy
Timeline: Q3 2027 Base
Acceptance Criteria: A “to-be” Minimum Viable Architecture (MVA) that fits the description and requirements described in Section 3.5.
Deliverable D03: Roadmap iteration
Timeline: Q4 2027 Base
Acceptance Criteria: Roadmap iteration in line with Sections 3.4 and 3.5, structured as defined in Section 3.6.
5. PRACTICAL ARRANGEMENTS
The services should be delivered 80% off-site.
Alternatively, they may be delivered using flexible working, with a requirement to be on-site at NCIA, The Hague, Netherlands, or Brussels, Belgium as agreed with NCIA (anticipated as 1-2 days per month), with the remainder of the services provided remotely.
Access to the relevant NCIA networks and software will be established as needed.
The services will be delivered during normal office hours following the NCIA The Hague calendar, as well as outside office hours and on weekends, if necessary.
The Contractor personnel will be part of a team under the supervision of the NCIA (project manager and lead architect).
The NCIA project team and the Contractor personnel will have regular meetings to review progress, address issues, and make necessary adjustments to the processes or production methodology.
The meetings will be physically in the office, or in person via electronic means using conference call capabilities, according to the NCIA project manager’s instructions.
The NCIA project team will provide guidance and direction on the architecture methodology, language, tools and framework to be used.
The Contractor personnel shall establish a continuous feedback loop to gather input from all stakeholders for ongoing improvements and their subsequent implementation depending on NCIA approval.
The Contractor personnel shall use a shared dashboard or tool to track the status of the deliverables and any issues.
6. SECURITY
All Contractor / Sub-contractor’s personnel shall be aware of all security rules pertaining to the handling of NATO classified information.
NATO Secret (NS): Individuals who require access or may have access to information classified NATO Classified or above during service delivery shall have a NS, which is valid for the duration of the authorized access. Such individuals are required to:
Have a ‘‘need-to-know’’ when accessing classified information.
Have been briefed on their security obligations in respect to the protection of NATO Classified Information.
Have acknowledged their responsibilities either in writing or an equivalent method which ensures non-repudiation.
Have access to Class II areas at NATO facilities, therefore PSC at NS level is required.
For this reason, a Request for Visit (RFV) will be submitted on time and before the join in day, by the company, through the respective National Security Authority, to the NCIA site of work.
7. INTELLECTUAL PROPERTY RIGHTS
All developed reports, solutions, tools and code under this project will be property of the NCIA.
8. TRAVEL
In case of flexible working (see Section 5), travel to and from The Hague or Brussels will be at the Contractor’s expense.
Extraordinary Travel (Purchaser Directed Travel) may be required to other NATO or non-NATO locations as necessary. In the event of such unforeseen meetings being called, the cost of all travel and subsistence will be addressed through a contract amendment.
9. REQUIRED QUALIFICATIONS
[See Requirements]
10. GENERAL PROVISIONS
A sole contractor must deliver these services. In the event that the contractor leaves during the contract period, a new contractor, who has the proven required qualifications and is evaluated qualified and suitable, shall replace him/her. The leaving contractor shall provide to the new contractor a training and handover of the performed history of the project. All normal NCIA Terms and Conditions apply.
NCIA Recognised Business Hours/Holidays: The NCIA - The Hague official holiday schedule applies and will be provided to the contractor.
NCIA Hours of Operations: Monday to Thursday 0830 – 1700 and Friday 0830 – 1500 (CET)
Contractor Furnished Services: The Contractor shall furnish everything required to perform the contract except for the items specified and covered under NCIA Furnished Property and Services below.
NCIA Furnished Property and Services: Access to relevant networks can be provided by NCIA as agreed.
Requirements
6. SECURITY
9. REQUIRED QUALIFICATIONS
Smith+Nephew · IND - NonGBS-Pune-Kharadi