08 · IT Consultancy
Systems & Architecture Assessment
Understand how systems, data and dependencies fit together before making major changes.
What this service is
Make system boundaries and dependencies visible before a major change creates avoidable risk.
A systems and architecture assessment makes the current technology landscape understandable before a major build, migration, acquisition or modernisation decision. It examines applications, interfaces, data ownership, hosting, operational responsibility and material failure points. The goal is not to create a decorative diagram, but to establish which boundaries are real, where concentration or duplication exists and which assumptions need evidence.
The assessment can cover an existing estate or a proposed solution. Findings are connected to practical consequences: changeability, continuity, data consistency, support, cost and delivery risk. The output records options and recommended priorities without representing a point-in-time review as ongoing assurance.
Typical situations
When this service is usually considered.
The examples below help frame suitability. The actual requirement, risks and intended outcome are confirmed during the initial review.
- 01
Different teams hold conflicting views of which systems own important records.
- 02
A modernisation or migration programme is being planned without a shared dependency map.
- 03
Changes in one application repeatedly cause unexpected issues in another.
- 04
Leadership needs an independent technical view before a major supplier or investment decision.
- 05
The current architecture grew organically and documentation no longer matches what is operating.
Scope of work
What the assessment may cover.
Every item is selected and bounded in the written proposal. Inclusion here describes capability, not an automatic promise that all activities fit the starting price.
Application and service inventory
A structured list of relevant systems, purpose, ownership, users, hosting and support arrangements.
Context and dependency mapping
Visual and written representation of boundaries, interfaces, data movement and critical external services.
Data ownership review
Identification of where important records are created, mastered, copied, transformed and consumed.
Risk and concentration assessment
Observations on single points of dependency, unsupported components, unclear ownership and recovery exposure.
Target options
Practical structural improvements or target directions with trade-offs, prerequisites and uncertainty made visible.
Prioritised recommendation brief
A written sequence of immediate evidence needs, risk-reduction actions and decisions for later design.
Expected outputs
Useful artefacts, decisions and working results.
The output is designed to support operation, delivery or a clearly defined next decision—not to create presentation volume without practical value.
System context and dependency map
A system context view showing relevant applications, users, suppliers and external boundaries.
Architecture observations and risk register
A dependency and data-flow model supported by written observations and unresolved questions.
Options with trade-offs
A prioritised architecture risk and decision register with practical consequences stated.
Prioritised recommendation brief
Target options and a recommendation brief explaining sequence, assumptions and next evidence required.
Application
Common use cases.
These examples show how the service can be applied. They are illustrative and do not represent claims of completed client engagements.
Pre-modernisation assessment
Understand dependencies and high-risk boundaries before choosing what to stabilise, separate or replace.
Application portfolio rationalisation
Identify overlap, duplication and ownership gaps across a group of systems.
Solution design assurance
Review a proposed architecture against requirements, operating capability and foreseeable change.
Technology due diligence
Create an independent point-in-time view of a product or estate before a major commercial decision.
Service-specific approach
How NORYVIA approaches Architecture Assessment.
The method is adapted to the service rather than repeating one generic project formula across every requirement.
Test documentation against reality
Existing diagrams are useful evidence but are checked against configuration, behaviour and stakeholder knowledge where access allows.
Follow the important records
Data ownership and movement often reveal dependencies that application lists alone do not show.
Connect technical findings to impact
Observations explain the operational, delivery or continuity consequence rather than relying on abstract architecture labels.
Separate evidence from inference
Confirmed facts, stakeholder statements and professional interpretation are distinguished in the output.
Engagement sequence
Six stages with visible decisions.
Activities can overlap where appropriate, but each stage has a clear purpose and produces evidence for the next one.
Scope and questions
Agree the systems, decisions, stakeholders, evidence sources and depth appropriate to the review.
Evidence collection
Gather inventories, diagrams, configurations, supplier information and structured stakeholder input.
Landscape mapping
Build the context, dependency, interface and data-ownership view.
Risk and option analysis
Assess material structural issues and develop proportionate improvement options.
Challenge and validation
Review findings with relevant people, resolve discrepancies and label remaining uncertainty.
Recommendation
Deliver the architecture pack, priority register and recommended next decisions.
Relevant capabilities
The disciplines brought into the work.
The precise technical or advisory depth depends on the accepted scope, available evidence and client environment.
Landscape
- Application and service inventory
- Context and boundary diagrams
- Integration and dependency mapping
- Hosting and supplier overview
- Ownership and support mapping
Data and resilience
- Source-of-truth analysis
- Information flow mapping
- Concentration and failure points
- Recovery-dependency review
- Logging and observability observations
Direction
- Target architecture options
- Transition dependencies
- Risk and decision register
- Modernisation priorities
- Leadership and technical walkthroughs
Client contribution
Information and access needed from the client.
Good delivery depends on timely, authorised access to relevant people and evidence. Missing inputs are surfaced as assumptions or constraints rather than quietly filled with guesses.
- 01
Available application lists, diagrams, contracts and operating documentation.
- 02
Access to people responsible for business processes, systems and supplier relationships.
- 03
Known incidents, change constraints and planned initiatives.
- 04
Representative interface, data and hosting information where authorised.
- 05
The decision or programme the assessment must support.
Scope, price and timing
A defined starting point—not a blank cheque.
The displayed price is an indicative starting guide for a bounded initial engagement. Before work begins, a written proposal confirms the selected activities, deliverables, assumptions, client responsibilities, exclusions, timetable, payment schedule and any third-party costs.
Indicative engagement shapes
Focused system assessmentTypically 1–2 weeks
Application landscape reviewTypically 2–4 weeks
Complex estate or target architectureDelivered through staged discovery and analysis
Factors that may change scope, price or duration
- 01
Number of applications, interfaces, suppliers and environments in scope.
- 02
Documentation quality and amount of discovery required to reconcile it.
- 03
Depth of data, resilience, security or target-option analysis.
- 04
Number of stakeholder sessions and conflicting ownership views.
- 05
Required diagrams, registers, workshops and decision outputs.
Scope boundaries
What is not automatically included.
Boundaries protect both parties from assumptions. A separate requirement can still be assessed and included where it is suitable and confirmed in writing.
Penetration testing
Security observations may identify areas for specialist testing, but formal penetration testing or certification is separate.
Continuous assurance
The assessment reflects evidence available during the review and is not a promise of future architecture or supplier behaviour.
Guaranteed complete discovery
Undocumented systems and unavailable access can limit findings; material uncertainty is recorded rather than concealed.
Service FAQ
Questions about Architecture Assessment.
Project-specific answers depend on the current environment, intended outcome and evidence available during review.
That is common. Existing material is treated as a starting point and compared with stakeholder input and available technical evidence. Differences are recorded explicitly.
Only where evidence supports it. Stabilisation, interface improvement, selective consolidation or no immediate structural change may be more proportionate.
Yes. The findings can help define current constraints, target requirements and evaluation questions, though formal procurement and legal work remain separate.
No. It may note material architecture or access concerns and recommend specialist work, but it does not substitute for formal security assessment.
Related capabilities
Other ways to move the requirement forward.
07IT Consultancy
IT Strategy & Roadmaps
Turn competing technology priorities into a practical sequence of decisions.
Explore service · from £1,400
09IT Consultancy
Cloud & Infrastructure Consulting
Plan infrastructure around workload needs, operational responsibility and cost visibility.
Explore service · from £1,800
10IT Consultancy
Technology & Vendor Selection
Choose technology against clear requirements rather than persuasive feature lists.
Explore service · from £1,200
Start with clarity
Start a conversation about Architecture Assessment.
Use the structured questionnaire to explain the current situation. NORYVIA will review suitability and respond with questions or a proposed next step.