An Infrastructure Architecture system: High Level Design

In the first article in this series we discussed the Conceptual Design for an Infrastructure Architecture System. In this article we will extend upon the ideas discussed previously to create a High-Level design for such a system.

The purpose of this High-Level Design is to define and describe the functions and features of the Infrastructure Architecture system, and to explore the relationship between the functions and features. 

Approach

In accordance with Systems Engineering principles, we will not be 'solutioning' the system at this stage; however, High-Level realisation options will be discussed, and in later articles in this series we will describe an implementation of the system at a Low-Level.

High Level Design Diagram

The Infrastructure Architecture system will consist of the following related functions:

The remainder of this article will discuss the functions in turn. 

Data Sources

Data Sources are (unsurprisingly) the sources of data available for your Infrastructure Architecture System to consume. Those available to you will reflect the sources of data available within your environment, but might typically include:

• users, 
• groups, 
• group memberships, 
• applications,
• mailboxes,
• servers.
• end user compute devices,
• records from your HRM and / or ERP systems, and,
• records from specific Line of Business applications.  

These are just the basics, and many more sources of data may be available then you actually require; accordingly the requirements of your own organisation will determine the value in consuming any particular source of data.

Back-End Database

The Back-End Database will be the structured storage capability used for holding and processing data extracted from the Data Sources. 

The most appropriate method and technology used will reflect your requirements and capabilities. For example, the "database" could be a simple as a folder containing a list of CSV files containing extracted data. 

Alternatively, the database could be hosted on a SQL Server with extracted data stored in related tables. Either would be fine, provided they meet the needs of your organisation. 

Front-End 

The Front-End is how value is consumed from your Infrastructure Architecture System. It will access, analyse, process and report upon the extracted data stored within the database. 

Within the Front-End are business rules, queries and application logic to drive use of the system such that value is delivered. This might include creating code automatically to automate processes, or to report on security risks.

Realisation of the Front-End will again reflect your requirements and capabilities; accordingly, it might be a set of written procedures, a spreadsheet, a set of Microsoft Access forms, and / or some SQL Server Reports. Most likely, it could be a mix of all of the above and more, and this fine provided it is capable of delivering your intended value.

Automated Orchestration

The Automated Orchestration feature is the glue that connects sources of data to the database, and the database to the Front-End.  

Extraction

It might consist of a series of interface scripts designed to extract data from the data sources and output them to a regular format suitable for importing into the database, or processing in some other structured manner.  

The actual scripts that you will require will depend upon the sources you wish to query. Furthermore, the structure of the scripts and the technology required for them to function will need to address the specific features of the data source itself. 

For example, many Microsoft products have native PowerShell capability, whereas other systems may rely upon data export features within the systems themselves, or may require you to extract data via APIs or from underpinning databases using SQL. 

Load

Automated Orchestration can also be used to load extracted data into your Back-End Database. Technologies that could achieve this include manual cut and paste imports, PowerShell interface scripts, and ETL (Extract, Transform and Load) services such as SSIS (SQL Server Integration Services).

Reporting

There is also the potential to use Automated Orchestration to generate and deliver reports using services such as SSRS (SQL Server Reporting Services). This might automate some of the manual reporting and distribution you might otherwise have to perform.

Administrator Usage

Administrator Usage of the system is likely to reflect the ongoing maintenance and development of system capability.

User Usage

User Usage, is where a 'User' in this context is an IT Professional performing their IT Operational duties, rather than a typical End User found in non-IT roles across your organisation.

User Usage of the Front-End is likely to focus on using forms and other built structure to analyse the Database to:

• fix technical problems,
• identify opportunities to improve, 
• fix mis-configurations, 
• report upon compliance and security problems, and, 
• perform automated IT operations tasks. 

Outputs

Anticipated Outputs of the system will therefore be:

• identification of non-compliance and automated generation of scripting that can be run to fix such non-compliance, and,
• demonstration of compliance and risk position through reporting, and,
• identification of business intelligence and other business-related value through reporting upon posture, features and performance in both a qualitative and qualitative (i.e. KPI driven) format.

Benefits

Consequently, the Outputs realise the Benefits described within the conceptual discussion by:

• creating a virtuous circle of continual improvement by identifying and fixing error, configuration drift and non-compliance, and,
• providing reporting as evidence as to why this is the case.

Furthermore, this is achieved in a mostly automated, low time and effort manner that liberates technical staff to focus upon higher value activities.

Next Steps

The following articles in this series will describe implementation of these features and functions in a practical manner.