Über die Rolle
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.
Solutions Architect – Amendment 1
Location: Off-site (80%), on-site in The Hague or Brussels (20%)
Cost Not to Exceed: 86,000 EUR (2026 Base), including travel costs to NCIA Hague or NCIA Brussels.
Option 2027 Base: 86,000 EUR, including travel costs to NCIA Hague or NCIA Brussels.
Period of Performance: Base: 11 November 2026 (Tentative) – 31 March 2027. Option: 01 April 2027 – 31 December 2027.
Required Security Clearance: NATO SECRET
- 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.
- 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:
- Engage with NCIA staff (Technical Subject Matter Experts, Project Managers and Enterprise/Segment Architects) to understand and document current and future system/service capabilities.
- Develop high level overview of as-is architecture.
- Develop the NIE as-is architecture, capturing selected current NIE, applications and system capabilities; their inter-dependencies and the technologies by which they are implemented and the standards they comply with to ensure interoperability.
- Develop the high level NIE to-be architecture.
- Develop the implementation roadmap that provides direction on how to transition towards the to-be architecture.
- Advise on technological synergies, gaps and opportunities identified.
- 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:
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.
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.
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.
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.
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.
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.
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.
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:
- Simplify, harmonize the “as-is” architecture: consolidate technology choices, identify common components and optimize their reuse.
- Reduce Operation & Maintenance support.
- Be data-centric, considering data as a first class concept and avoiding locking data into specific applications/systems (application-centric architecture), aligned with NATO’s Data Centric Reference Architecture.
- Be a resilient and scalable architecture designed for future extensions.
- Optimize data flow, considering data transfer spanning different security domains, networks, and internet connectivity.
- Enable interoperability, including interoperability with the nations and in a federated environment.
- Implement Zero Trust Policy: enforce identity checks, least privileged access, data integrity, provenance, and strict guard policies.
- Comply with NATO STANAGs when available, and open standards otherwise, avoiding vendor lock-in architecture design.
- Ensure applications are cloud-native to the extent possible, i.e. embrace a cloud-optimized design using cloud services and comply with principles such as portability, resiliency, and scalability, and ensure readiness for migration to the cloud.
- Maximize use of available platform, infrastructure and AI services.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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:
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 rev
Quelle: die eigene Karriereseite des Arbeitgebers.
