7.1 THE STEPS IN SOLUTION TECHNOLOGY DEFINITION

The aim of solution technology definition is to show:

• What type and level of technical infrastructure is required to deploy a solution.
• What areas of the current infrastructure will need to change.
• How much cost, time and other resources will be required to make the necessary changes.

Solution technology definition is based on a model that allows solution components (SBBs) and interfaces between them (SBBIs) to be mapped to infrastructure components using a step-by-step approach (see Figure 7.1).

Each component has a set of functional requirements and NFRs and some, but not all, of these requirements will map to infrastructure service requirements. An infrastructure service requirement must include the level of service required.

Infrastructure service requirements map to suitable infrastructure services that can meet the requirement. If an infrastructure service exists, or is planned for, it will appear in the infrastructure catalogue and will be mapped to one or more infrastructure components. If a service requirement does not map to a suitable infrastructure service, this indicates a gap.

Solution technology definition is a critical activity in making the transition from logical design to physical implementation and ultimately deployment. The key stakeholders involved in this transition are:

• The solution architecture team who have produced and validated the logical design.
• The infrastructure architecture function who will fit the physical technology platforms and enabling infrastructure that support the solution into the infrastructure architecture and model any necessary changes.

The steps outlined here are arranged in a formal process that can be used to produce a solution technology definition using the outputs from gap analysis. A less formal process is often used during solution design to assess the physical dimension of a solution. For example, as soon as any infrastructure service requirements can be identified, the solution architecture team can discuss how they might be implemented in the current infrastructure architecture landscape and how they might fit into strategic planning.

The steps to define the technology for a solution are:

• Clarify precursors, requirements and context, ensuring all inputs to the process are prepared and disclosed to all parties, and that any initial queries are addressed before the process starts.
• Understand baseline opportunities and target constraints, mapping the scope of the solution to the baseline infrastructure architecture, and identifying any potential opportunities and constraints within the scope.
• Map SBBs to infrastructure services, itemising infrastructure services and components that meet the solution requirements.
• Define networking infrastructure, modelling the connectivity required to fulfil the needs of the interfaces between solution and infrastructure components.
• Iteratively refine to meet functional requirements and NFRs, testing the target infrastructure architecture against the solution requirements and making modifications where necessary.
• Assure end-to-end security, assessing the solution and infrastructure architectures against security standards and removing or mitigating vulnerabilities.
• Identify gaps in infrastructure services, itemising any gaps in provision or capacity and reporting on the costs and other implications for change.
• Validate the solution technology definition, reviewing with senior stakeholders and obtaining sign-off from the business.

7.2 PRECURSORS, REQUIREMENTS AND CONTEXT

The starting point for solution technology definition is the solution design. This contains the components and interfaces that make up the solution and define its scope.

Any technology needed for the solution must be within this scope. For both solution and infrastructure architecture, however, impacts may extend beyond the scope of the solution. For example, a change to an existing system could impact other users even though they are out of scope for the solution.

Other models, artefacts and documents can provide additional detail to support the process of solution technology definition. The solution architecture team is responsible for making all necessary information available for use by the infrastructure architecture function and any other roles involved. This can include:

• logical solution design;
• baseline and target solution architecture descriptions;
• gap report and associated gap models;
• business functional requirements and NFRs;
• viewpoints and views that address infrastructure-related areas of the solution.

The infrastructure architecture function is responsible for reviewing the solution design and associated information and raising any queries. Queries typically concern clarification of design decisions, perceived gaps in the information provided, or projected timescales that could affect the availability of infrastructure components.

The solution architecture team is responsible for ensuring effective communication with stakeholders at all times during the solution architecture life cycle. The solution architecture team is accountable for the fact that all stakeholders are informed about all activities and decisions that affect the solution. In addition they are accountable for the fact that stakeholders who are directly affected by a decision or who have registered a related concern are consulted before the decision is finalised. This includes escalating any significant decisions, such as those that may impact on the business requirements, budget or timescales, to the business sponsor for approval.

7.3 BASELINE OPPORTUNITIES AND TARGET CONSTRAINTS

Baseline opportunities are beneficial changes that can be made to the baseline infrastructure architecture as part of the implementation of a solution. These are opportunities to incorporate changes to the infrastructure architecture with those required for the solution. This approach can save effort, reduce costs and bring forward desired changes that would normally require a separate change project or programme.

A major source of opportunities is the IT strategy. This represents decisions that have been made by business leaders about the future direction of IT infrastructure within the organisation or enterprise.

The other area that can be revealed by a close inspection of the overlap between infrastructure architecture and solution design is that of constraints. Constraints are limits within which infrastructure and solution architecture must work to define the technology that will be part of the implementation of the solution. These constraints also apply to those who will implement the solution in the completion phase.

There are many different types of technological constraint. The main ones are shown here:

• Approval or preference: a list or model of technological choices that have been approved for use within the organisation or enterprise, placing a constraint on infrastructure components that can be used as part of a solution.
• Standards: infrastructure architecture contains standards that must be adhered to and therefore can constrain a solution; an example is the ISO 50001 standard for energy management, which aims to reduce energy footprint and greenhouse emissions (ISO 50001:2018, 2018).
• Budget: financial limits are placed on the overall spend on IT and priorities established for how the money should be spent, putting a constraint on the changes that can be made to the infrastructure to accommodate a new solution.
• Time: some required technology may not be available in time for the solution to take advantage of its benefits, or there may be pressure to stop using certain technologies by a certain date.
• Contracts: existing contracts must be adhered to and this can impose constraints on what can be changed.
• Geography: infrastructure services may not be universally available for various reasons and could result in different components being used in different geographical locations, especially if governments place restrictions on their use.
• Skills: the skills of staff to implement, deploy or manage its components may be a constraint on certain aspects of a solution, where some development tools or environments may not be available to be part of a solution.

The idea of approval or preference of certain infrastructure technologies, or products that implement them, has been adopted by many organisations. This has a number of benefits for infrastructure architecture. It acts to limit the number of different technologies in use by controlling the choices available. It can also help by ensuring that technologies and products have been through a process of assessment and trial.

A simple way for an organisation or enterprise to express technology preferences is to use the infrastructure catalogue. Each item in the catalogue requires a status to indicate the type of preference expressed. This can be complicated or simple. A simple system involves a RAG or traffic-light rating, so that each item is either red, amber or green. Here, red indicates it is not to be used for new projects and any opportunity to remove it from the infrastructure should be acted upon. Green indicates that this is a preferred technology or product and should be the first choice. Amber items may still be used, but approval to do so by the infrastructure architecture function or another authority is required.

An alternative, more dynamic approach is a technology radar that gives technologies and products more of a life cycle.

The process for identifying and understanding opportunities and constraints takes place between the solution architecture team and the infrastructure architecture function. Other stakeholders may be consulted to support decisions about the effect on the solution design. There are also levels of decision that require escalation to senior business stakeholders, including the business sponsor.

A RACI matrix (see Table 7.1) may be used to show which stakeholders have the responsibility (R) and accountability (A) for carrying out activities, together with those who may be consulted (C) and also those who must be informed (I) about decisions and other outcomes.

The enterprise architecture function must be consulted if any major change to the infrastructure architecture is proposed to support the implementation of a solution. This is to ensure that any change is consistent with enterprise principles and policies.

Any significant impact on capital or recurring costs must be escalated to business owners and senior managers and their approval sought.

7.4 MAPPING SBBS TO INFRASTRUCTURE SERVICES

SBBs that map to infrastructure services may be of different types:

• Technology: equipment or software.
• Process: business process or procedure.
• Information: data structure, message, document or other unit of information.
• Organisation unit: team, department, organisation or other business unit.
• Person or role: business actor or end user of a service.

This activity depends on having a list of SBBs with requirements that can be met by infrastructure services. Where there is a baseline solution architecture that is being replaced with a modified solution design, it would be reasonable to remove any components that do not change from this list. However, this approach risks missing some potential benefits that could be achieved by mapping an existing SBB to an infrastructure service.

Table 7.2 shows a typical infrastructure service catalogue with services categorised by function. They can additionally be mapped to infrastructure components in an infrastructure technology catalogue.

The process for mapping SBBs to infrastructure services is driven by the infrastructure function in consultation with the solution architecture team. Decisions may be escalated if they go beyond the remit of infrastructure and solution architecture. Specialist knowledge may also be required, and other stakeholders can be consulted if necessary.

A RACI matrix (see Table 7.3) may be used to show stakeholder involvement in this activity.

For solution requirements where there is an existing infrastructure service provision, reconfiguration may be required, or the capacity expanded. These details need to be recorded for each SBB.

7.5 NETWORKING INFRASTRUCTURE

Up to this point, the focus has been on selecting the best infrastructure services and components to meet the needs of the solution. Now the focus shifts to how the components connect and communicate with each other to carry out the activities of the solution.

Throughout the process of solution technology definition there is a degree of iteration required. The level and frequency of iteration may vary from step to step, but the aim of achieving the functional requirements and NFRs is paramount. Iteration occurs each time an infrastructure service, provided by an infrastructure component, is proposed as part of a solution. This triggers a review of the solution requirements to ensure that they are all still being met. This is a form of static regression testing.

This approach continues throughout solution technology definition, but the activity of defining the networking infrastructure is a boundary or watershed in the process. At this point any trade-offs between infrastructure services and components should have been resolved so that the focus can move on to connectivity and interfaces.

Each interface needs to be examined individually to determine the correct infrastructure service requirement. Interfaces are about communication, so the requirements will concern the type and volume of the communication traffic that passes across the interface from one SBB to another. Note that not all interfaces require networking – for example, an interface between two processes may be entirely manual. However, in the interest of completeness, each interface should be considered even if it can be swiftly ruled out.

Note that interfaces between SBBs are known as SBBIs.

The process here is similar to mapping SBBs to infrastructure services. First, a list of SBBIs that require the use of infrastructure services is prepared. The services are mainly in the networking and communications category. The individual requirements for each interface are then identified and clarified. These will largely be NFRs but there may be some functional requirements about the message contents, for example. This information allows suitable infrastructure services to be selected to support each interface.

A RACI matrix (see Table 7.4), may be used to show stakeholder involvement in this activity.

7.6 FUNCTIONAL REQUIREMENTS AND NFRS

At every stage in the process of solution technology definition, the business requirements have been checked and validated by the solution architecture team to ensure they have not been adversely impacted by any of the decisions about the use of infrastructure services. Business requirements represent the quality of the solution and are the test against which it will be judged by its stakeholders.

This results in a set of infrastructure components connected by networks that can deliver the requirements of the solution.

However, the nature of architecture is that everything is connected, meaning that a design decision in one area of the solution affects everything else. For example, the decision to select a type of data store, such as a NoSQL graph database, has benefits for analytics that may support a functional requirement but is not so good for one of the NFRs such as data integrity. In other words, design decisions involve compromises that can involve trading off between requirements.

The aim of this activity is to test the design to identify any weaknesses in support for specific functional requirements or NFRs, and then modify the design to try to strengthen support, in a balanced way, for all the requirements.

It is important to recognise that testing at this stage does not mean putting software or hardware through its paces or setting up test environments, nor does it involve recruiting end users and business actors to try out the solution. The type of testing used here is called static testing and is based purely around the solution design and its supporting documentation.

Some static techniques that can be used here are:

• Traceability: to ensure that all requirements are present within the design.
• Business scenarios: realistic end-to-end use cases of the solution by business actors that illustrate the problem being addressed by the solution.
• Data and information flow analysis: close examination of the movement of data and information to ensure it meets or supports the requirements.
• Control flow analysis: inspection of decision points in the solution to ensure sufficient accurate information is available to make the correct decision, and that decision points cannot be bypassed in a way that would compromise the requirements.

The majority of testing is conducted by the solution architecture team with support from the infrastructure architecture function. However, there may be benefits in involving other stakeholders. For example, a representative of the business, such as a business analyst, can give another perspective on what can otherwise become quite a technical activity. Another useful perspective may be introduced by the use of professional testers who are familiar with the techniques of static testing and can help with creating scenarios, tracing requirements and ensuring a high degree of test coverage.

The requirements catalogue is the reference point for all types of requirements and should be used as the source of information during this activity.

A requirements traceability matrix acts as an intermediate artefact to link requirements to solution components – that is, the SBBs and SBBIs.

Existing viewpoints can be used to produce views based on the proposed infrastructure services and components in the solution technology definition.

A RACI matrix, such as the example in Table 7.5, may be used to show stakeholder involvement in this activity.

7.7 END-TO-END SECURITY

Information security is an important aspect of solution design and applies in almost every line of business, but particularly so where confidential information relating to customers or commercial activity is concerned. Cybersecurity is also a big concern and this must be reflected in solution design by including robust protection against attack by malevolent parties.

In a solution, there are a number of ways that security can be specified:

• Functional requirements: security controls that are part of the functionality may be specified as requirements and may be implemented using techniques such as role-based access control (RBAC), business rules that may be configured to prevent unwanted activity or security auditing.
• NFRs: measures that prevent malicious attacks and attempts to undermine the aims of the solution.
• Enterprise directives: principles and policies that define how security measures should be applied in specific areas of the business.
• Technical standards: specifications that have been adopted by the business to guarantee types and levels of behaviour that underpin security and are widely recognised as being of value externally by, for example, customers and partner organisations.

Functional requirements related to security should by now have been refined as part of previous activities to a point where they are acceptable to all stakeholders. However, there are some cases where there is some overlap with security NFRs and it is as well to include all aspects of security in the end-to-end assurance step.

In previous steps of solution technology definition, other stakeholders have been consulted and provided input, either by virtue of their accountability for the outcome or because of their specialist knowledge about the operational domain. Security aspects of a solution require highly specialised and current knowledge because of the changing nature of the threats faced. Recognising that security assurance is a complex and specialised field, organisations are increasingly convening a security design authority to make decisions about the security aspects of all solutions within the organisation or enterprise. Much of the accountability for assuring end-to-end security is delegated to this group.

A RACI matrix (see Table 7.6) may be used to show stakeholder involvement in this activity, including the security design authority, if there is one.

The security design authority performs two tests on a solution and provides an assessment that is acted upon by the solution architecture team and the infrastructure architecture function:

• Compliance with directives: auditing the solution design against security principles, policies and standards that have been adopted by the organisation or enterprise, such as ISO 27001 (ISO/IEC 27001:2013, 2013).
• Vulnerability testing: modelling threats and malicious activity to test the security resilience of the solution using libraries of identified threats such as Common Weakness Enumeration (CWE) and Open Web Application Security Project (OWASP) and frameworks such as Control Objectives for Information and Related Technologies (COBIT) and National Institute of Standards and Technology (NIST).

7.8 GAPS IN INFRASTRUCTURE SERVICE PROVISION

A key output of the solution technology definition process is a report on any gaps in the provision of infrastructure services that would hinder or prevent the implementation and deployment of the solution.

Key decisions about the implementation of a solution cannot be taken without this information. For example, service gaps are likely to add to the costs of implementing and deploying the solution, and costs are a major factor in the decision to proceed with any project or programme.

Costs may be accrued by a solution in multiple ways, including those costs associated with solution architecture and design, implementation, deployment and ongoing management and maintenance. The marginal costs linked to infrastructure may be isolated by itemising the gaps in infrastructure service provision and analysing the associated costs.

Exposing a higher-than-expected level of costs may lead to a rethink of:

• the infrastructure technology used to support the solution;
• the architecture and design of the solution;
• the scope and scale of the solution;
• the inclusion of baseline opportunities.

Whether changes are made in any of these areas or not, stakeholders will be given the opportunity to validate the solution technology definition and may insist on a revision.

The other benefit of identifying and itemising gaps in infrastructure service provision is that the resulting requirements for change must be part of the solution delivery roadmap.

The process for achieving the list of changes and costs is similar to the gap analysis that was performed between the baseline and target solution architectures during the validation phase of the solution architecture life cycle. Here the list is constructed by comparing the solution technology definition and the infrastructure technology catalogue.

Each item may be categorised as follows:

• New: service is not currently provided.
• Replacement: existing service replaced by an alternative.
• Modification required: service exists but needs reconfiguration, rescaling or expansion into a new geographical region, for example.
• Removal: service is no longer required.

Each of these changes needs to be assessed to establish the size and scale of the change and what will be required in terms of cost, resource and time. Note that although all changes require effort and this is likely to involve some cost, some changes may reduce ongoing costs. For example, in the case of the replacement of one service by another, there will be some cost in making the switch, but the running costs of the new service may be less due to improved efficiency. The entire basis and rationale of some solutions is to reduce ongoing costs, but this can rarely be achieved without investing in change first.

7.9 VALIDATING THE SOLUTION TECHNOLOGY DEFINITION

Once all the steps of the solution technology definition have been completed, all the necessary information is ready to be presented to the stakeholders for validation.

Many stakeholders will have been directly involved in the process and others will have been consulted during decision making or informed of the outcome of those decisions. If stakeholder communication is effective, there should not be too many surprises during the validation step. However, it is an opportunity for all stakeholders to focus on the infrastructure and technological aspects of the solution and see all the relevant information in its completed form.

This step is jointly led by the solution architecture team and the infrastructure function. The information may be delivered to stakeholders electronically for review and followed up with a workshop at which there is an opportunity for discussion and questions.

A solution technology definition validation workshop typically covers:

• A walkthrough of the solution technology definition with all stakeholders present or represented.
• A description of all changes and revisions of the solution architecture.
• A breakdown and explanation of the infrastructure costs and any savings associated with the solution.
• A discussion of the tradeoffs behind the infrastructure choices.
• Raising and addressing any concerns, either during the workshop or following further investigation.

REVIEW QUESTIONS

1. Which step is performed first in solution technology definition?

a. Understand baseline opportunities.

b. Clarify precursors and requirements.

c. Assure end-to-end solution security.

d. Map building blocks to infrastructure services.

2. How is an infrastructure catalogue used in solution technology definition?

a. As a source of infrastructure services for a solution.

b. As a source of requirements for a solution.

c. To define the interfaces between solution components.

d. To define the end-to-end security for a solution.

3. A solution architecture team has completed the logical design and validation phases of the solution architecture life cycle. The solution is now being put through the solution technology definition process. What two possible events during this process will require the solution design to be revised?

i. A security vulnerability is identified.

ii. A solution component is mapped to an infrastructure service.

iii. A target architecture constraint is breached.

iv. An infrastructure service capacity gap is identified.

a. i and ii only.

b. iii and iv only.

c. i and iii only.

d. ii and iv only.

4. Which type of solution component is most likely to map to a networking infrastructure service?

a. Non-functional requirement (NFR).

b. Solution building block (SBB).

c. Architecture building block (ABB).

d. Solution building block interface (SBBI).