Senior Solution Architect – ICT Traffic Management Solutions

Infrabel's I-ICT.212 office manages all of the applications related to infrastructure management rail as well as rail traffic planning and infrastructure work. Users The end users of these applications are the collaborators of Train Service and Works planning offices, signaling and traffic control posts. Our These applications are critical for railway operations. and benefit from a 24/7 childcare service and 7 days a week. Purpose of the Role: We are looking for a solution. Architect for the UPM project, capable of designing, document and govern the architecture of a solution meeting explicit business objectives, while ensuring its consistency with the enterprise architecture, the principles, standards, and architectures of reference and applicable target trajectories. The Solution Architect translates functional requirements and non-functional in a feasible design secure, resilient, operable, scalable and economically sustainable. It informs decisions at By comparing scenarios, it formalizes the trade-offs. and supports the implementation through to verification of the conformity of the delivered solution. The role is technical as well as architectural. The holder designs, but it must also be able to read the existing codebase. appreciate its quality and discuss the consequences concrete aspects of a decision with the engineers who will implement. An architecture that the team in A place that cannot be built is not architecture: That's an intention. He also maintains the reference point. perimeter architecture in the form of models ArchiMate, not isolated diagrams—this is what makes the architecture verifiable over time rather than being recounted at every meeting. Defined Scope: The UPM solution, its satellites, and its interfaces: train and work planning on Infrabel's Belgian rail network. • Technical inventory of the solution. • Establishment of a technical architecture roadmap aligned with: – its current state and potential rework; – its planned evolutions, through ongoing maintenance of the legacy component and through the separate platform modernization program; – its compatibility with cybersecurity standards. UPM Solution Infrastructure and Technology: • Infrastructure: OpenShift, AIX, Oracle, Redis. • Back-end: Java 8, Java 17-21 (primarily microservices). • Front-end: Angular 15 and 18, Swing. • Secrets: HashiCorp Vault. • Queuing: IBM MQ. • Event: Kafka. • Logging: Elastic. Experience with a specific technology is less crucial than the ability to quickly evaluate a new one, but the coexistence of legacy systems and microservices, along with the diversity of exchange mechanisms (MQ, Kafka), lies at the heart of the scope's challenges. Positioning: • Work within a clearly defined solution scope, aligned with business capabilities, data, applications, and relevant technologies. • Apply a requirements-driven approach, considering stakeholders, risks, value, and decision traceability. • Ensure continuity between target architecture, change portfolio, detailed design, implementation, transition, and operation. • Submit key decisions, deviations, and exceptions to the appropriate governance bodies. • Document and develop knowledge. • NTH: Contribute to relevant iterations of the architecture development methodology, without replacing the roles responsible for corporate strategy or overall governance. Note: The incumbent does not belong to any development team: an architect placed in a team becomes its developer within two sprints. He or she will align with similar and/or impacted entities as needed. Key Areas of Responsibility: Defining and Understanding the Need • Identify stakeholders, their concerns, objectives, and success criteria. • Analyze and challenge functional, non functional, regulatory, operational, and security requirements. • Define the scope of the solution, its boundaries, assumptions, dependencies, and constraints. • Maintain traceability between objectives, requirements, architectural decisions, and solution elements. Developing the Solution Architecture • Describe the relevant initial state and develop the target architecture of the solution. • Build and compare several scenarios, clearly outlining benefits, costs, risks, trade-offs, impacts, and reversibility. • Consistently cover business, data, application, integration, technology, security, and operational dimensions. • Define interfaces, flows, component responsibilities, quality of service requirements, and deployment principles. • Identify reusable building blocks and prioritize Existing standards, models, and services where relevant. • Formalize significant decisions and their rationales in Architecture Decision Records or an equivalent mechanism. Transition Planning • Identify gaps between the existing and target systems, as well as the capabilities to create, modify, migrate, or remove. • Propose realistic intermediate states, transition packages, and implementation sequences. • Contribute to the assessment of feasibility, dependencies, risks, costs, and technical debt. • Support the development of the implementation and migration roadmap. • Estimate the order of magnitude of the implementation costs for the proposed scenarios, ensuring that the decision-making process focuses on comparable options. Governance and Compliance • Verify the alignment of the solution with principles, standards, reference architectures, and governance requirements. • Prepare architecture reviews, present choices, and integrate decisions made. • Identify, document, and obtain arbitration for deviations or exceptions, along with their associated risks and mitigation measures. • Conduct compliance reviews during implementation and before commissioning. • Update the architecture when the approved implementation differs from the initial design. Support for Implementation and Operations • Guide the detailed design, development, integration, testing, cybersecurity, and operations teams. • Clarify the architectural intent without replacing engineering and execution responsibilities. • Ensure that operability, observability, continuity, backup, recovery, support, and lifecycle are addressed from the design stage. • Contribute to proofs of concept when technical uncertainty or risk warrants it. • Organize the transfer of architectural knowledge and verify that required documentation is available and up-to-date. • Participate in team work preparation sessions (refinement) with the product owner and analysts, and validate the technical aspects of sprint entry criteria. • Conduct targeted code reviews on key structural points—service boundaries, interface contracts, transaction and error management—without replacing peer review. Knowledge Management and Continuous Improvement • Capitalize on reusable models, decisions, lessons learned, and components. • Contribute to the evolution of standards, patterns, reference architectures, and architectural practices. • Report inconsistencies, documentation gaps, systemic risks, and opportunities for streamlining. • Stay informed about practices, technologies, and trends relevant to the scope of responsibility. Architecture Repository Maintenance (ArchiMate) • Build and maintain the scope's architectural models in ArchiMate, within the reference modeling tool (e.g., Sparx EA), and not as independent diagrams. • Define and enforce modeling conventions: naming conventions, granularity, layer usage, allowed relationships, and element lifecycle. • Produce views by viewpoint and stakeholder from a single model, ensuring that a change propagates to all views concerned. • Ensure the repository is up-to-date: it reflects the approved state, observed deviations, and the target, and it is updated when the implementation diverges. • Ensure traceability between model elements, requirements, and Architecture Decision Records. Expected deliverables: • Solution architecture document — Context, stakeholders, requirements, views, scenarios, target, risks, and roadmap. (decision support and design reference) • Architecture views and models — Views adapted to stakeholder concerns. (make the solution understandable and verifiable) • Up-to-date ArchiMate repository — Single model, views per viewpoint, modeling conventions respected, elements traced to requirements. (ensure that every published view derives from a single, verifiable source) • Scenario analysis — Options, criteria, advantages, limitations, costs, risks, and recommendations. (objectify trade-offs) • Requirements registry — Requirements, sources, priorities, acceptance criteria, and traceability. (Manage compliance as needed) • Decision Records Architecture — Decision, context, options, rationale, and consequences. (Ensure decision traceability) • Gap Analysis and Roadmap — Gap, transition packages, dependencies, and sequencing. (Plan the transformation) • Architecture Risk Assessment — Risks, impacts, probability, treatment, and ownership. (Control residual exposure) • Compliance Report — Findings, gaps, decisions, actions, and status. (Verify implementation alignment) • Transfer Documentation — Up-to-date architecture, constraints, instructions, and operational elements. (Support commissioning and maintenance) Decision-Making Authority and Role Limits Expected Authority • Recommend the architecture option with the best balance of value, risk, cost, time, and sustainability. • Define the architecture constraints applicable to the solution within the scope of the mandates received. • Request the correction of a non-compliant implementation or the formal instruction of a deviation. • Escalate any conflicting requirement, unaccepted risk, or decision exceeding their mandate. Limitations • Does not make sole decisions regarding business priorities, funding, or acceptance of major risks. • Does not replace the business owner, product owner, project manager, domain experts, security managers, or engineering teams. • Does not have permanent operational responsibility for a platform, unless explicitly mandated separately. • Does not validate a solution whose essential requirements, flows, dependencies, or risks are not sufficiently documented. • Reports hierarchically to the Team Lead. Functional Relationships • Enterprise architecture and domain architects: strategic alignment, principles, standards, target models, and cross-functional trade-offs. • Business, product, and analytics owners: objectives, needs, value, processes, requirements, and acceptance criteria. • Security, data, integration, infrastructure, and platforms: specialized requirements and cross-domain consistency. • Program, project, and portfolio: planning, dependencies, risks, costs, and delivery governance. • Engineering, testing, and suppliers: feasibility,

Detailed design, implementation, and proof of conformity. • Operation and support: operability, observability, continuity, capacity, performance, and knowledge transfer. Criteria for successful project completion: • Decisions are traceable, understood, and linked to requirements and objectives. • The solution is consistent with target architectures, standards, and approved constraints. • Risks, deviations, and dependencies are visible early enough to allow for arbitration. • The implementation reflects the architectural intent or is subject to formally decided deviations. • Deliverables are complete, usable, maintained, and accessible to authorized stakeholders; knowledge is transferred. • The solution can be operated, maintained, secured, and subject to controlled evolution. • The ArchiMate repository is up-to-date and used by others besides its author: this is the only test that distinguishes a living repository from abandoned documentation. Behavioral Skills • Systems thinking, critical analysis, and synthesis skills. • Clear communication with technical and non technical stakeholders. • Facilitation, active listening, negotiation, and constructive disagreement management. • Influential leadership, pragmatism, and decision-making orientation. • Rigorous documentation, autonomy, responsibility, and a strong sense of ethics. • Ability to work in uncertainty and to make assumptions explicit. • Ability to gain acceptance for an architectural decision in an environment where change encounters resistance, by aligning with guidelines and explaining rather than imposing. Technical skills The holder must be able to communicate with technical experts and judge for himself the feasibility of what he designs. Distributed application architectures: service-oriented architecture, transaction delimitation, data ownership, interface contracts and version control, event-driven and messaging mechanisms. Data storage and access: data modeling, query strategies, transaction management, distributed caching, and cache consistency. Runtime platforms: containerization, orchestration, deployment strategies, and observability (logging, metrics, and traces). Application security: authentication, authorization, secrets management, common vulnerabilities, and securing the software supply chain

Skills
Proficiency in enterprise and solution architecture concepts, governance, and requirements management. (L4: at least 10 years of experience) Ability to produce coherent views covering business, data, application, and technology dimensions. (L4: at least 10 years of experience) Proficiency in architecture modeling. (L4: at least 10 years of experience) Ability to reason in terms of scenarios, trade-offs, risks, dependencies, costs, and value. (L4: at least 10 years of experience) Knowledge of integration patterns, APIs, data, infrastructure, cloud, and cybersecurity. (L4: at least 10 years of experience) Understanding of operational, resilience, continuity, performance, capacity, and lifecycle considerations. (L4: at least 10 years of experience) Multilingual communication: fluent command of French and/or Dutch, as well as English, both spoken and written. (C2: highly advanced proficiency) Professional experience in information systems, engineering, or a related field. (L4: at least 10 years of experience) Experience in information systems design. (L4: at least 10 years of experience) Experience as a solution architect for systems in production. (L4: at least 10 years of experience) Demonstrated experience in designing and integrating solutions that involve multiple technical domains and stakeholders. (L4: at least 10 years of experience) Experience participating in architecture reviews, risk analysis, and supporting implementation efforts. (L4: at least 10 years of experience) Personal experience in software development, recent enough to maintain credibility with an engineering team. (L4: at least 10 years of experience) Practical knowledge of TOGAF is recommended; TOGAF certification is a plus, depending on the expected level of seniority. (L3: at least 5 years of experience) Knowledge of security practices and a service management framework is a plus. (L4: at least 10 years of experience)