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 |