> Markdown version of [/jobs/ext/2950684-2026-0125-solutions-architect-ns-tue-29-sep](https://www.wearedevelopers.com/jobs/ext/2950684-2026-0125-solutions-architect-ns-tue-29-sep). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md). --- # 2026-0125 Solutions Architect (NS) - TUE 29 Sep - **Company:** EMW, Inc. - **Location:** Den Haag, Netherlands - **Experience:** Experienced - **Contract:** Permanent contract - **Skills:** Applications Architecture, Systems Engineering, Cloud Computing, Configuration Management, Data Transmissions, Data Governance, Data Integrity, Document Management Systems, RAID, Gantt Charts, Interoperability, Cloud Services, Zero Trust Network Access, Requirements Traceability, Data Streaming, Systems Architecture, Archimate, Technical Debt, AI Platforms, Bug Reporting, Information Technology - **Published:** September 17, 2026 - **Apply:** https://www.adzuna.nl/details/5886288005 ## About the Role * 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., 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., * Individuals who require access or may have access to information classified NATO Classified or above during service delivery shall have a NATO Secret (NS) clearance, which is valid for the duration of the authorized access. Access to Class II areas at NATO facilities requires a PSC at NS level., * The candidate must hold an MSc degree in either Computer Science, Software & Systems Engineering, or a similar area, or, exceptionally, the lack of a university degree may be compensated by the demonstration of particular abilities or experience that is/are of interest to NCIA, that is, at least 6 years' extensive and progressive expertise in duties related to the services outlined in the Statement of Work. * The candidate must have a minimum of 5 years' proved experience in enterprise/solution architecture delivery. * The candidate must have 4+ years of experience with the development of architectures for NATO and/or defence customers. * The candidate must have experience using Archimate and Sparx Enterprise Architect. * The candidate must have proven experience and writing of large, structured documents. * The candidate must have proven ability to integrate and work in a multinational team. * The candidate must be fluent in Business English. ## Description The NCIA Chief Technology Office requires Solution 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 a Solution Architect with generated documentation, the capturing of the to-be architecture as well as the implementation roadmap 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: * 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. 3. DELIVERABLES The Contractor shall deliver: * "As-is" Minimum Viable Architecture (MVA) for the NATO Intelligence Systems Architecture focusing on Applications and Technology. * "To-be" MVA for the NATO Intelligence Systems Architecture focusing on Applications and Technology. * Gap analysis with high level roadmap. 3.1 "As-Is" Architecture The "as-is" architecture will include a selected set of current NIE applications, and technologies. The main deliverable is the "as-is" architecture report that shall cover the following areas, 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., 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. In addition, the Contractor is expected to deliver the architecture models that shall include all information about Application Architecture, Business Architecture, Technical Architecture, and Data/Information Architecture, based on the details defined in the metamodel to be further provided upon onboarding. 3.2 Working Practices In order to deliver the architecture detailed above, the Contractor is expected to: * Conduct around 20 interviews with relevant stakeholders regarding NIE projects and programmes detailed by the CTO project team. * Support the architecture and roadmap development as prescribed in this Statement of Work. * Provide architecture expertise to support the report generation. 3.3 "To-Be" Architecture The "to-be" architecture shall be based upon existing and future NIE systems/applications. 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, aligned with NATO's Data Centric Reference Architecture. * Be a resilient architecture with open design for the future. * Optimize data flow, considering data transfer spanning different security domains, networks, and the internet/cloud. * 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. * Ensure applications are cloud-native to the extent possible, i.e. embrace a cloud-optimized design using cloud services and 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 main deliverable is the "to-be" architecture and the generated report shall address the following areas, 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., 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.4 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, 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. 3.5 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 04.11.2026 (Tentative) and will end no later than 31 March 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 and Q1 2027, the following deliverables are expected from the service, with T0 being the start of the Contractor's work (estimated no later than 04.11.2026): Deliverable D1: Initial "as-is" architecture report and architecture models - Draft, 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 CTO (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., 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. ## Related Videos - [This App Reached 10,000 Users in One Week. Here's How.](https://www.wearedevelopers.com/videos/100329-this-app-reached-10-000-users-in-one-week-here-s-how) - [Security Pitfalls for Software Engineers](https://www.wearedevelopers.com/videos/726-security-pitfalls-for-software-engineers) - [From AI Assistance to Agentic Systems: Scaling Sovereign AI in Banking](https://www.wearedevelopers.com/videos/100070-from-ai-assistance-to-agentic-systems-scaling-sovereign-ai-in-banking) - [We (don't) need a software architect!?!](https://www.wearedevelopers.com/videos/663-we-don-t-need-a-software-architect) - [What makes Cybersecurity different for critical infrastructure?](https://www.wearedevelopers.com/videos/571-what-makes-cybersecurity-different-for-critical-infrastructure) - [Supercharge your cloud-native applications with Generative AI](https://www.wearedevelopers.com/videos/950-supercharge-your-cloud-native-applications-with-generative-ai) ## Related Articles - [The 12 Best Jobs for Software Engineers](https://www.wearedevelopers.com/magazine/401-the-12-best-jobs-for-software-engineers) - [The Netherlands – Europe’s powerhouse for software development?](https://www.wearedevelopers.com/magazine/31-the-netherlands-europe-s-powerhouse-for-software-development) - [How to land a developer job in Amsterdam](https://www.wearedevelopers.com/magazine/36-how-to-land-a-developer-job-in-amsterdam) - [Dev Digest 134 - Where pixels sing?](https://www.wearedevelopers.com/magazine/477-dev-digest-134-where-pixels-sing) - [Top 6 Hackathons for Developers in 2023](https://www.wearedevelopers.com/magazine/263-top-6-hackathons-for-developers-in-2023) - [Is Software Engineering Over-Saturated?](https://www.wearedevelopers.com/magazine/418-is-software-engineering-over-saturated)