8.1 BUILDING THE DELIVERY ROADMAP

The roadmap development phase is a watershed in the solution architecture life cycle. It is where the carefully architected and validated solution design is handed over to be implemented and deployed by a variety of specialist teams. These delivery teams will be managed by P3M, and the delivery roadmap is their contract with the business and its stakeholders.

After the handover, the role of solution architecture changes significantly. Up to this point the solution has been in the hands of the solution architecture team and the main focus has been on logical design. From this point onwards, there is little or no requirement for this type of work, and solution architecture takes on a governance role, becoming the point of reference if anything relating to the architecture or design is unclear, or needs to be changed.

The roadmap is a critical document that serves to communicate at a high level and to a broad audience what needs to be delivered and in what sequence:

• Stakeholders: can focus on business benefits and ensuring the correct sequence and time frame for their achievement.
• P3M: can see the blocks of work that need to be broken down into programmes and projects to deliver the benefits.
• Delivery teams: can understand the context in which their implementation work is to be completed and integrated.
• Solution architecture team: is able to validate that the SBBs will be created and integrated in the correct sequence to deliver the business benefits.

8.1.1 Roadmap structure

Delivery roadmaps are needed to portray complex, multi-dependent change over a medium to long time period. The roadmap therefore shows only the most important deliverables that are easily recognised by all stakeholders, and places them within broad time periods – quarter years or months, for example – that are widely in use within the organisation for activities such as resource planning and budgeting. These are shown as vertical divisions. Delivery milestones and other significant events may also be shown (see Figure 8.1).

Deliverables may also be organised into workstreams that are normally shown at right angles as horizontal divisions and help to make the roadmap easier to understand. They may be based on a number of factors, such as the business area or geography of the change activity represented.

Deliverables are planned and organised by P3M using a combination of programmes and projects (see Figure 8.2). A programme is a collection of related projects and may be linked directly to a roadmap workstream. Some deliverables are of a sufficient size and degree of complexity to require a programme. More straightforward ones are usually delivered as part of a single project.

It is interesting to note that SBBs may relate to either deliverables or project work items. This depends on the granularity of the SBB. Some are small, fine-grained components whereas some are major parts of the whole solution, sometimes known as coarse-grained components.

Fine-grained SBBs appear as work items in project plans and are not visible on the roadmap. Coarse-grained SBBs that are made up of many fine-grained components working together are more likely to appear on the roadmap as deliverables.

To appear on the roadmap, an SBB must be separately deliverable, recognisable to stakeholders, and be associated with a business benefit or capability.

8.1.2 Inputs to the roadmap

The delivery roadmap represents a transition from the logical realm of architecture and design and is where the solution begins to be transformed into a physical reality. The shift from logical to physical is also evident in the solution technology definition activity where SBBs and SBBIs are matched up with technology components from the infrastructure architecture domain.

Significant technology components that need to be acquired or modified may appear on the roadmap as deliverables. Others that are components of a deliverable can be found by drilling down into project plans.

Behind the roadmap, P3M develops detailed plans with more specific deliverables, dates and dependencies, which align closely with the roadmap. Additional date tolerances are often included in the roadmap to allow for the compound dependency risks of multiple components needing to be delivered to support a single roadmap item.

The main inputs to the roadmap are:

• Target architecture: solution design documents that show how everything works together.
• Gap report: provides an itemised list of SBBs and SBBIs where change is required.
• Solution technology definition: provides an itemised list of infrastructure components where change is required.
• Existing dependencies: planned activity in other programmes and projects that overlaps with the solution and could impact its delivery.

8.1.3 Development process

The solution architecture team, working with P3M, are responsible for the process of building the delivery roadmap. Solution architecture provides three of the four inputs (target architecture, gap report and solution technology definition), with P3M providing the fourth (existing dependencies).

The development steps are:

• collect and validate inputs;
• identify and agree deliverables;
• perform outline planning to manage dependencies and resources;
• trade off between stakeholder expectations;
• produce draft roadmap;
• present to the business (possibly via the design authority);
• refine and circulate for approval.

Once a draft roadmap has been developed, this should be discussed with the business sponsor to ensure it is compatible with the priorities of the business.

When P3M, solution architecture and the business sponsor are happy with the roadmap, it can be presented to a broader group representing all the stakeholders for the solution. At this point, stakeholders may raise concerns about the dates or sequencing of deliverables, and this can lead to adjustments being made. Any modifications must be done with the agreement of the business sponsor.

8.1.4 Turning SBBs into roadmap deliverables

The major constituents of the roadmap are the deliverables, time periods and workstreams. The most important of these to identify are the deliverables and this should be done at the start of the process. Deliverables are derived directly from SBBs and are formed by grouping them together logically to deliver specific business benefits. Note that a single SBB may be part of multiple deliverables but only needs to be developed or procured once, although it may need configuration.

This approach of grouping together SBBs into deliverables may be performed using several techniques, such as affinity mapping, but a popular method is to produce a type of tree diagram called a work breakdown structure (WBS). This technique is widely used in project planning and begins with the highest-level product or the end result that the project is trying to achieve. For developing a solution delivery roadmap, the highest-level product is the solution itself.

The method is then to identify the next level of item that is required to deliver the solution. Further levels can be added until all solution components have been included.

Note that this technique may also be used much earlier in the solution architecture life cycle as a way to analyse a problem and start thinking about what might be required to solve it.

A WBS generally shows top-level deliverables and one or two levels below that. The diagram would become hard to follow and to maintain if much more detail were added. Its value is as a guide to identifying deliverables that need to be broken down further and organised into programmes and projects.

8.1.5 Project and programme planning

Having confirmed what needs to be delivered, the P3M function can start to think about how this could be achieved. The overarching responsibility of all those involved is to deliver the solution in line with the needs of the business, which is represented by the stakeholders. Therefore, the priorities and concerns of the stakeholders should be the main drivers to determine the sequence of delivery.

The stakeholders, led by the business sponsor, will have the opportunity to review, amend and approve the roadmap before the implementation begins. The solution architecture team, having worked closely with stakeholders up to this point, should have a very clear idea of their priorities.

There are many factors involved in the development of project and programme plans apart from the wishes of stakeholders, including:

• Estimation: how quickly tasks can be completed.
• Dependency: the natural or logical order in which tasks must or should be completed.
• Resource allocation: how resources can best be used to deliver the desired outcomes.
• Risks: how to minimise or mitigate all types of risk during the project.

The solution architecture team can advise on the business risks that were identified during the business case option selection process. Other information from the business case may also be relevant, such as the return on investment analysis. Stakeholders can also advise on general risks in other areas of the business.

Risk management is the responsibility of the P3M function throughout the implementation and deployment of the solution and a formal process will be used. During the roadmap development process, only those risks that are relevant to the sequencing of delivery are taken into account, although all identified risks should be captured for future reference.

The P3M function can then look in more detail at the programme and project plans to see if there are any serious concerns with the roadmap. Delivery team representatives may be consulted during this review. Any issues should be raised with the solution architecture team and can be escalated to the business sponsor.

Another point to agree upon is the schedule of communications and updates that are part of the governance of the delivery of the solution. This schedule should be published, along with the roadmap, to all solution stakeholders.

8.2 MONITORING AND SUPPORTING THE DELIVERY

There are a number of levels of involvement for the solution architecture team once the work of implementation has commenced.

At one extreme, solution architecture has little involvement beyond attending regular review meetings. Responsibility for ensuring that the solution adheres to the agreed architecture and design is largely delegated to P3M and any divergence is raised directly with the business to decide how to proceed.

A more formal approach to governance places solution architecture in the role of guardian of the design that represents the ideal for the business, having been fought out between the competing interests of multiple stakeholders. The benefit of a greater role for solution architecture in the governance of delivery is that the implemented solution is closer to the design and, where it varies, it is closer to the requirements.

In general, more complex designs and those with greater business impact should be dealt with more formally. Simpler, smaller-scale solutions can largely be delegated to P3M.

8.2.1 Role of the design authority

Throughout the work of architecting and designing the solution, the design authority has provided a focal point for decision making and stakeholder communication. The design authority:

• is fully representative of stakeholders;
• has access to specialist knowledge when required;
• provides updates to all or selected stakeholders;
• receives queries and concerns which can then be dealt with directly or escalated.

During the completion phase, the design authority is ideally placed to continue these activities. The differences between the completion phase and the previous phases of the solution architecture life cycle are chiefly ones of scale and complexity. Up to and including the roadmap phase, the focus has been on a single design being produced by a single team, albeit with the involvement of multiple stakeholders (see Figure 8.6).

The major organisational change during the completion phase is that the P3M function takes over coordination of the delivery of the roadmap elements, having been authorised by the business sponsor. As the delivery programmes and projects progress, P3M can keep all stakeholders fully informed by reporting progress to the design authority.

Any design decisions that exceed the specifications given to a delivery team by P3M can be referred to the design authority, which can escalate decisions if necessary:

• To solution architecture if changes to the architecture and design of the solution would be needed.
• To the business sponsor if business requirements or constraints would be affected.
• To business owners and senior managers if business operations are likely to be impacted.

Decisions that have been approved by the design authority need to be authorised by the business sponsor before P3M can amend programme and project plans and issue new specifications to the delivery teams affected by the change.

8.2.2 Complexity of design during implementation

Design activities in the completion phase are more complex, because they involve multiple components being implemented by different delivery teams with different skill sets. In addition to meeting their own specifications, they must work with other components using strictly defined interfaces. Any failure to comply puts the goals of the overall solution at risk.

There is also a difference of scale. The logical design activities of solution architecture can be completed in a relatively short period. However, there are many more constraints on physical activities, such as the development of software, acquisition of technology, or redesign of processes and organisational units. In general, this means delivery timescales are longer and resource use greater.

The number of dependencies increases exponentially with the number of components. This effect can be limited by packaging as many components together into a single deliverable so that the dependencies can be dealt with internally by the delivery team.

The solution architecture approach aims to reduce complexity so that the solution can be delivered with the maximum possible benefit to the business and the minimum disruption to operations. This is achieved through:

• analysis of requirements;
• design of independent components;
• clear specification of interfaces;
• reuse of existing components.

8.2.3 Scheduled meetings and regular reporting

Since there are multiple components being developed that may require decisions to be referred to the design authority, it is usually best to set dates when the members meet to consider these and any other relevant matters. This approach makes good use of the time and resources of the design authority members and any expert witnesses who are required to attend.

A schedule of regular meetings helps the development and delivery teams to coordinate their own activities because they know when critical decisions will be made. Therefore, planning sessions, supplier demonstrations, user testing and other activities that may throw up questions that need to be referred to the design authority can be scheduled before a meeting date and the work that would result from a decision scheduled afterwards.

An important way to monitor progress in the implementation and delivery of a solution is the use of regular reports from the teams responsible for developing or acquiring solution components.

This is a standard approach within P3M, where regular reviews of progress are held at programme and project meetings. These often have an internal and external aspect where minor technical aspects are dealt with internally by the P3M community before a presentation of progress is made to the business.

The solution architecture team should be represented at these progress updates, because there are often discussions about prioritising activities or allocating resources that can have an impact on the roadmap. Any such changes should be referred to the design authority or the business sponsor for a decision and approval.

Any question of changing the scope of a deliverable so that a specification or requirement will not be delivered should be referred to the design authority before any action is taken.

Some members of the design authority may be present at P3M-led progress update meetings. Other members can be kept abreast by receiving update summary reports. It is quite usual to have a report on progress as a standing agenda item at design authority meetings, at which point any queries can be raised and dealt with. Queries that cannot be dealt with from the summary information provided may be referred back to P3M.

8.2.4 Altering the roadmap

The summary report from P3M may highlight risks to the delivery of one or more roadmap items. If so, the report should be accompanied by details of the problem and the risk management activities that are being used to avoid or mitigate the risk.

In cases where the risk is unacceptably high, it may be necessary for the roadmap to be altered. This is a very serious matter as the delivery roadmap is a contract with the business stakeholders, who may have based operational activities and strategic plans around it. Before the roadmap can be altered, therefore, the business stakeholders must be fully involved. It is critical to begin the process of rebuilding the roadmap as soon as it has been established that the risk is significant. This is true even if it just involves a short delay with no knock-on effect on other deliverables.

8.2.5 Vetting designs

The delivery of the solution is managed by P3M in terms of allocating the work to a diverse number of delivery teams and monitoring their progress. P3M may have some expertise in the work being done, for example, being able to understand sprint plans and test reports produced by software development teams. However, when it comes to architecture and design, it is usual to refer any assessment or vetting to a body such as the design authority or another technical committee. Such a body can organise for the necessary expertise to be made available.

Design assessments may be made by architects and specialists from the appropriate domain, such as security, business, or software, and may work together to check that the design meets the needs of the solution:

• Effectiveness: meets all requirements and conforms to standards and constraints.
• Efficiency: makes best use of resources.
• Encapsulation: only uses defined interfaces and follows their specifications.

8.3 VALIDATING PRODUCT DELIVERY

The delivery of a product – meaning an SBB, component, or other deliverable – indicates that it is completely ready for deployment. Validating product delivery means establishing it is of sufficient quality and meets its specification and acceptance criteria. As more products are delivered, the interfaces between them can also be validated to ensure that they will work together when deployed.

Delivery teams report successful delivery to P3M, who then report back to the business via the design authority or a programme board. Apart from confirming that delivery dates accord with the roadmap, stakeholders need to have confidence in the quality of the products being delivered.

Governance of product quality has a number of strands that fall into different areas of responsibility:

• P3M: primarily concerned with time, cost, resources and to a certain extent the scope.
• QA: aims to ensure robust processes are in place that ensure a high-quality product is delivered.
• Testing: closely examines products on delivery and during development, making a formal assessment of quality.
• Business change management: concerned with how easily the product can be deployed within the business and the deployment of all business components of the solution.

There is some overlap between these strands, with testing as the common factor. For example, in projects involving software development, the project manager will often insist on a development life cycle being followed and its activities integrated into the project plan. A life cycle is also a control measure used by QA professionals as it contains processes that promote good practice with regard to quality. Testing is a major part of software development life cycles. Ease of deployment includes usability that is often expressed as an NFR and therefore subject to testing.

A concern for solution architecture is that the governance of product delivery has a disproportionate focus on software development. This is especially true of testing, which is either much more limited or non-existent for non-software components of a solution. Solution architecture provides adequate specifications that would allow the same standard of testing as for software:

• Externally sourced: components obtained from equipment suppliers, off-the-shelf software and even externally developed software is often subject to much lower standards of governance and testing. Solution architecture must ensure these are tested to ensure they meet the acceptance criteria by professional testers, as listed above. This needs to be emphasised to P3M so that it is included in project and programme plans.
• People and organisation units: where roles and responsibilities are changing, plans may include various forms of communication, including training, but its effectiveness is rarely tested. This comes under business change management, as described above, but testing may involve professional testers working with HR and other business managers.
• Processes: quite often lumped together into training courses and other forms of communication, the actual operation of processes often goes untested despite the many functional requirements and NFRs that apply to them. This can be done using scenario-based testing that is frequently used to test software systems.
• Information: sometimes tested in conjunction with any software that uses or manages it, but many of the requirements and constraints that are put in place to ensure immediate and long-term quality are omitted from testing programmes. Solution architecture needs to ensure that all information and data components within the solution have sufficient test coverage.

A factor that can impede the correct validation of product delivery is change management and version control of the specifications that deliverables are being built to meet. It is possible for a specification to change during implementation.

Any change should be subject to strict governance with decisions being made and authorised at the appropriate level. Failure to follow change control procedures could result in one version of a specification being used to design and build a product and a different specification being used for testing and validation.

8.4 AGREEING SERVICE LEVELS, TARGETS AND METRICS

An SLA is a commitment between two parties: the service provider and the client (sometimes called the service user). SLAs define the normal level of provision and what will be done if this is not maintained. The service provider is usually an external organisation such as a supplier, for example an internet service provider (ISP), or can be an internal business unit such as the IT department. Similarly, the client can be internal or external to the business.

A simple way of looking at SLAs is that they directly mirror the NFRs that were specified for the SBBs that make up the service.

One decision that needs to be taken is the scale of the service that an SLA will be applied to. This determines the metrics that will be used to monitor the service and feed any action or escalation.

Another decision is the frequency of measurement. With automation, measurements can be made at vanishingly small intervals, approaching continuous monitoring. Whether this is appropriate, however, depends on what is to be done with the information.

SLAs can be made up of exact figures such as speeds, percentages or volumes that are target values, but may also have additional figures that represent tolerances above or below the target figure, or both. This approach allows for multiple response options depending on the degree of variance from the target.

Details of business continuity and disaster recovery SLAs are specified in the ISO 22301 standard (ISO 22301:2019, 2019).

The needs of the business with regard to a service may change over time. Requests for change to the service level need to be dealt with using a change management process in a similar way to requests for new or modified functionality. Any change can have architectural implications at both the solution and infrastructure levels and needs to be fully assessed before it is implemented.

The infrastructure architecture function may also wish to make changes to SLAs over time. For example, if the metrics show that a certain service is never used to the level specified in its SLA, infrastructure architecture may recommend a reduction in the level provided. This could free up resources that could be used elsewhere or reduce the cost of running the service.

8.5 SUPPORTING FUTURE CHANGE AND MAINTENANCE

One of the strengths of solution architecture is that solutions can be designed and built with the future in mind. Components are designed to be replaceable because their clearly defined interfaces allow alternatives to be plugged into an existing solution. Components and interfaces with fully documented functionality are also much easier to reuse within the current solution or elsewhere in the enterprise.

All the necessary details to make changes to an existing solution can be found in the enterprise architecture repository where the final versions of all artefacts and other documentation must be lodged at deployment. Other parts of the enterprise architecture repository are also updated at deployment, if affected by the solution, so that those responsible for changes made anywhere in the enterprise will have access to the latest current-state information.

There are a number of reasons for updating an operational solution and these are often categorised as:

• Corrective: something not working according to specification that needs to be fixed.
• Adaptive: a change in the operating environment of the business requires a change to the solution or new requirements have been identified.
• Predictive: a risk has been identified that can be avoided or mitigated for by changing the solution.
• Perfective: the solution can be improved beyond its current specification.

Changes may be as small as a modification to an existing component or may involve adding, modifying and removing multiple components. Any change to an existing solution represents a risk to the business. The size of the risk is roughly proportional to the size of the change and the importance of the solution to the business.

A senior representative of the business needs to authorise most changes; this could be the business sponsor for the solution. This person may have been given the role of solution owner after deployment. Corrective and perfective maintenance that does not change the solution requirements may not need authorisation and may be delegated to operational teams such as DevOps.

The majority of changes can safely rely on the artefacts and other documentation produced during the solution architecture life cycle. For example, the stakeholder and concerns registers will still be accurate, although this could change over an extended time period.

The architecture and design of an existing solution supports all types of change in a number of ways:

• Diagnosing problems systematically using solution models.
• Isolating components and interfaces that need to change.
• Identifying the impacts of change.

Operational measurements such as SLAs and KPIs can add to the evidence both for the need to change and to help identify which parts of the solution can be modified to bring about the change.

8.6 COMMUNICATING WITH THE BUSINESS AFTER DEPLOYMENT

During the completion phase of the solution architecture life cycle, the design authority maintains communication with stakeholders through regular updates to report progress and keep all parts of the business fully informed.

At some point after the last component of the solution has been deployed, the solution becomes part of the operational responsibility of the business and any communication about the solution takes place within the business.

Solutions that are the result of solution architecture should deliver exactly what the business requires and thereby enhance the standing of the discipline within the organisation. This should mean that the next time the business has a problem or wishes to take advantage of an opportunity, the solution architecture approach will at least be considered.

An exercise that can help to reinforce the benefits of solution architecture is to capture any lessons that have been learned during the solution architecture life cycle and circulate the findings to all involved. This can form the basis of improving or refining the solution architecture process, but also helps to embed solution architecture into business processes that relate to business change.

Additionally, any business issues or needs that were excluded from the scope of the solution can be itemised and potentially addressed in a future solution.

Monitoring and control of various aspects of the solution will have been agreed with the business and this includes escalation points and actions in case there is variance from the agreed SLAs.

In the longer term, it may be beneficial to schedule some analysis of the solution to see its effect on the business after it has been in use for a continuous period. This type of review can be helpful in identifying requirements that were not apparent when the solution was being designed.

Typically such reviews are scheduled six months or a year after the key components of the solution are in place.

REVIEW QUESTIONS

1. A new solution has been developed to capture and filter citizen journalism from around the world. Submission can be by multiple channels including social media, file sharing, transfer and upload. Short videos will be prepared to help contributors submit material safely and in a usable format. What part does the roadmap play in monitoring the delivery of the solution?

a. The roadmap shows the order in which the submission channels will be developed and released so the videos can be produced in the right order.

b. The roadmap shows the order in which the submission channels will be developed, but there is a separate schedule for releasing the product and the associated videos.

c. The roadmap shows the dates by which the submission channels and videos will be developed and released so that progress can be monitored.

d. The roadmap shows the order in which the submission channels and videos will be developed, but the dates are shown on separate project plans which are used to monitor progress.

2. Citizen journalists submit reports, photos and videos 24/7/365. The channels are therefore guaranteed to have high availability for immediate use more than 90 per cent of the time and at least two channels are always available. How is this arrangement known?

a. Key performance indicator (KPI).

b. Service level agreement (SLA).

c. Non-functional requirement (NFR).

d. Decision support system (DSS).

3. To enable citizen journalists to submit reports, four high-level deliverables have been identified: submission, validation, communication and help videos. What type of model could be used to find lower-level building blocks?

a. Building block decomposition grid.

b. Delivery roadmap metamodel.

c. Work breakdown structure (WBS).

d. Cluster analysis diagram.

4. Which two items are inputs to the delivery roadmap?

i. Quality assurance and test plans from the development teams.

ii. Gap report with changes identified and itemised.

iii. Change management policies and procedures.

iv. Relevant dependencies from existing project plans.

a. i and ii only.

b. iii and iv only.

c. i and iii only.

d. ii and iv only.