Everyday ‘Solution Architectural’ Thinking

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;

Everyday Solution Architectural Focus Points during a project

Digital Data

Consideration Description
Collection How will or does the project elements collect ‘raw data’  – physically / logically and the associated transmission protocols etc ?
Extraction Transformation & Loading How will your system collect its raw data and if the data is without structure – do you  need to ‘mould’ it for use prior to storing ?, thus, what is the moulding / transformation that is required?
Storage Once collected, how will the system physically store the data , ‘as is’ or do we restructure , index, create meta data etc.?
Cleansing Do we need to cleanse the data or does it need to be quarantined i.e. placed in temporary staging area before releasing for use?
Protection How do we safeguard and protect the data during collection, maintaining integrity throughout the collection, transformation and storage phases ? i.e. prevent malicious activity.
Source Knowing the source of the data, be it a SCADA device, a repository or 3rd party is crucial to ensuring that all upstream feeds remain.
Ingestion   Data although raw can be linked to multiple objects e.g. Spatial data containing geometric coordinates and thus must be validated during the ingestion stage.

Information

Consideration Description
Management The ‘information life cycle’ requires extensive management both during the life of a project and post go live.
Classification Information as an asset requires classification to enable the protective marking of its use and management.
Transformation One of the greatest value adding activities during an ICT project is that of transforming the data to add value in its representation.
Governance The control and use of data must be governed to ensure that any Enterprise standards and policies are adhered to.
Visualisation Visualisation is often a by-product of the collection of large amounts of data, which needs to be represented or simplified visually for consumption.
Cost The real and notional cost of production, retention and distribution of information
Intelligence The process of grouping large volumes of data to provide information which in turn provides intelligence that can be ‘acted on’

 

Process Execution / Orchestration

Consideration Description
Definition Process Definition – the functional and non-functional definition of processes.
Orchestration The orchestration of the defined processes and the associated triggers.
Interactions (internal/External) Processes can be executed within the organisation outside but then.
BPM – Modelling The actual Modelling of the business process.
RACI The Roles & responsibilities of the process (RACI – Responsible, Accountable, Consulted and Informed).
Execution How are processes executed ? – what are the triggers or events that initiate a process?
Notations / graphical tools Most organisations have complex processes with multiple dependencies – these cannot often be represented simply in a text document and many tools are available to capture process flows / swim lanes graphically etc.

 

Reporting

Consideration Description
Dynamic / Static Reporting There are two types of reporting – Static and Dynamic reporting is often ‘predefined’ data sources and structures to represent specific information. Dynamic reporting is the ability to generate reports on the fly with no fixed structures or hard coded variables.
Localisation When working on global deployment projects it is important to constantly consider the localisation requirements for reporting and if operating in countries such as Brazil this is important for regulatory compliance.
Data Sources / Query Executers The following are all self-explanatory and considered ‘bread and butter’ for the Solutions Architect.What are the sources for which reports will be based on and the queries?

Reusable Report Structures

Structure
Charts
Templates
Elements / Styles

Leave a Reply

Your email address will not be published. Required fields are marked *