Tag: Solution Architect

As an Architect you can expect, at some point in your career, to be involved in a critical frontline, turbulent project or programme. During such times, you need to rely on technical, political and social skills gained over several years of working in the field of ICT.

Today’s blog (prepared on the London-Coventry train)  is a reminder of some of the “basics” that the average Solution Architect must consider when working on complex projects. These ‘system orientated’ considerations remain at the forefront during project engagement elements , requiring consideration during analysis, design and build stages of system construction / delivery at the same time of maintaining the line of sight for the outcome.

As with most things in life, the list presented is obviously subject to the area you operate in, for example, if you are working on a Manufacturing Execution System (MES) solution then your primary focus for the project would be on the real-time supervisory control and data acquisition systems and processes. However, if you are working on a Retail Banking Application then your focus would be biased towards compliance and reporting.

The list presented is not exhaustive and kept general to provide insight. However If we examine most ICT projects, we often find  a common pattern i.e. one of collecting raw data, transforming this into  information then allowing digital processes to consume and generate reports allowing businesses to execute an event or action that adds value to the Organisation.

This movement is presented in the diagram below, with thought  bubbles representing areas of thought which are further listed in the tables below;

Continue reading “Everyday ‘Solution Architectural’ Thinking”

Solution Architects as previously mentioned are responsible for working with programmes and projects to ensure a solution to problems is designed, costed, procured, built and delivered into the organisations which often results in delivering a new process outcome and IT capability.

Solution Architects address a wide spectrum of problems and issues ranging from the simple to the complex and thus require a wide range of skills (technical / business).

The work of the Solution Architect can be broken down into distinct stages and categorised into the following areas:

Each layer of the Solution Architect Lifecycle is briefly discussed below. However, it must be noted that the focus at each layer will be aligned to the top layer i.e. the problem/issue.

Identification

Often a problem requires a working group to establish if something is worth considering e.g. bid on a project or to discuss a ‘pattern’ that is emerging in the technology landscape which requires investigation from the reporting systems e.g. Capacity & Performance / Security incidents.

Solution Architects are often engaged at this stage to provide advice on possible options for resolving a problem and to assist in triggering the next phase of the activity.

Defining the context of the problem/issue

No project or programme of work in real terms commences without a Business Case i.e. a document that captures the reasoning for initiating a project or task with basic costings and outcomes documented. If the problem issue is a Technical one then the Solution Architect is required to elaborate (in simplistic terms) the context of the problem from the systems viewpoint.

Capturing the Requirements

During the requirements capture phase the Solution Architect will spend much of his/her time focusing on the system elements of the requirements and trying to understand the system components characteristics.

During this stage, there will be a bias towards the non-functional elements of the system.

During this stage, a Minimum Viable Product can be elicited from stakeholders, i.e. the minimum components and effort that will be required to deliver the functional and non-functional requirements can be sketched to define further costs analysis.

It must be noted that the requirements must also encapsulate any legal compliance issues e.g. GDPR requirement and any Enterprise Architectural directives.

Defining Product Backlog and or Level 0 Systems Architecture

Once the problem is known, documented and decomposed into a set of clearly defined functional and non-functional requirements a level 0 systems architecture can be produced to outline a solution.

Where possible reusable components should be highlighted to shorten time to market and increase savings to the project.

At this stage, the outcome should be a level 0 design and in many cases, result in a product backlog for the solution

The level 0 design will facilitate the project to determine the cost and effort involved to deliver the outcome required.

Designing the Solution and breaking down the deliverables into sprints

At this stage, a detailed analysis of the Level 0 is undertaken and elaborated further to deliver a detailed design document and the subsequent technical sprints to deliver the project.

Depending on the Solution it may be prudent to produce a low-level design to support the Solution Design.

Options for realising the solution and enacting

I have discussed previously the options that are available for analysis from “do nothing” to “Build” but from a cost / do ability view the option should be selected that leverages existing relationships /services and best value for money.

Delivering Solution into production

Developing, procuring  or modifying a system requires deployment into a production environment and thus the Solution Architect must be capable of defining the environments (test, prod, pre-prod) for the route to live. Often this will involve working with the Service Architects to design the Service and the operational elements (often extrapolated from the NFRs) of the system.

If we were to take all the elements above and assign time that the Solution Architect would be involved in the project then we could produce a graph like the one below;

In summary, the Solution Architect is an important role and requires skills that evolve with each engagement and has a role to play from problem realisation to delivery into service of a solution.

The article from https://dalbanger.wordpress.com/2017/05/07/the-solution-architecture-life-cycle/