applying the gnst to the engie it ral-final

Applying the Generalised

Normalised Systems Theory to

the Engie IT Reference

Architecture Library

Author: ir. Haerens Geert

Promotor: Prof. dr. Jan Verelst

Datum: May 15th, 2016

Applying the GNST to the Engie IT RAL

ii | P a g e


iii | P a g e

Contents

1 Executive Summary ................................................................................................................. 1

2 Introduction ............................................................................................................................. 2

2.1 Problem Statement .......................................................................................................... 2

2.2 Research Question ........................................................................................................... 2

2.3 Conceptual Model ............................................................................................................ 3

2.4 Research Methodology .................................................................................................... 3

3 IT Infrastructure and the Engie IT Reference Architecture Library ......................................... 7

3.1 IT Infrastructure ............................................................................................................... 7

3.1.1 Architecture Frameworks ......................................................................................... 7

3.1.2 ArchiMate ................................................................................................................. 7

3.1.3 OIAM ......................................................................................................................... 8

3.1.4 GRAAL...................................................................................................................... 10

3.2 Engie IT RAL .................................................................................................................... 11

3.2.1 Concept ................................................................................................................... 11

3.2.2 RAL as a Modular Structure .................................................................................... 13

4 Artefact Requirements .......................................................................................................... 15

5 Artefact Design ...................................................................................................................... 16

5.1 General info on the Generalised Normalised Systems Theory ...................................... 16

5.2 Contextualisation for Infrastructure Systems ................................................................ 18

5.3 Artefact Description ....................................................................................................... 18

5.3.1 Artefact input .......................................................................................................... 18

5.3.2 Artefact Content ..................................................................................................... 18

6 Demonstrating the Artefact .................................................................................................. 20

6.1 Housing Infrastructure Basis Service .............................................................................. 20

6.1.1 Manifestations of Concern, State, Version and Instance ....................................... 21

6.1.2 Applying the Artefact to Housing 1.0...................................................................... 23



iv | P a g e


6.2 Hosting Infrastructure Basis Service .............................................................................. 29


6.2.2 Applying the Artefact to Hosting 1.0 ...................................................................... 31

6.2.3 Applying the Artefact to Hosting 2.0 ...................................................................... 33

6.3 Proxy Infrastructure Basis Service .................................................................................. 35


6.3.2 Applying the Artefact to Proxy ................................................................................ 37

7 Evaluation of the Artefact qualitative analyses .................................................................. 39

8 Evaluation of the Artefact feedback ................................................................................... 40

8.1 Value of the Artefact ...................................................................................................... 40

8.2 Observed CE ................................................................................................................... 40

9 Artefact Value ........................................................................................................................ 42

9.1 Value for RAL Engie IT .................................................................................................... 42

9.2 Value for the Architect ................................................................................................... 42

9.3 Value for the Generalized Normalised Systems Theory GNST ...................................... 43

10 Conclusions and Reflections .................................................................................................. 44

10.1 Conclusions..................................................................................................................... 44

10.2 Reflections ...................................................................................................................... 45

10.2.1 GNST knowledge as essential Architecture Skill ..................................................... 45

10.2.2 Artefact evolution ................................................................................................... 45

10.2.3 Roadmaps and Lehmans Law ................................................................................. 45

10.2.4 Configuration is the new Code ............................................................................... 46

Appendix 1: Applying the GNST on the RAL/ASC Engie IT ............................................................ 47

A1.1 Module: Housing-IBS......................................................................................................... 47

A1.1.1 Housing 1.0 ................................................................................................................. 49

A1.1.2 Module: Housing 2.0 .................................................................................................. 55

A1.1.3 Module: Housing 3.0 .................................................................................................. 59

A1.1.4 Conclusion and reflections on Housing-IBS................................................................ 64


v | P a g e

A1.2 Module: Hosting-IBS ......................................................................................................... 66

A1.2.1 Hosting 1.0.................................................................................................................. 68

A1.2.2. Hosting 2.0 ................................................................................................................ 70

A1.2.3 Conclusions and reflections on Hosting pattern ........................................................ 73

A1.3 Module: Proxy-Network-IBS ............................................................................................. 75

A1.3.1 Cohesion ..................................................................................................................... 76

A1.3.2 Coupling ...................................................................................................................... 76

A1.3.3 Separation of Concern (SoC) ...................................................................................... 77

A1.3.4 Separation of State (SoS) ............................................................................................ 77

A1.3.5 Version Transparency (VT) ......................................................................................... 77

A1.3.6 Instance Traceability (IT) ............................................................................................ 77

A1.3.7 Adding a Source and Target ....................................................................................... 77

A1.3.8 Conclusions ................................................................................................................. 78

Appendix 2: CE in other IT Infrastructure Systems ....................................................................... 79

A2.1 Housing ............................................................................................................................. 79

A2.2 Upgrades OS - Hosting ...................................................................................................... 79

A2.3 New workstation ............................................................................................................... 80

A2.4 Unified Communication Tool ............................................................................................ 80

A2.5 Infrastructure Software Update - Exchange 2013 ............................................................ 81

A2.6 Instance Transparency ...................................................................................................... 81

A2.7 AD Upgrade ....................................................................................................................... 81

A2.8 Application functionality ................................................................................................... 81

A2.9 Separation of State ........................................................................................................... 82

Appendix 3: Infrastructure Solutions for Evolvability ................................................................... 83

A3.1 Updates ............................................................................................................................. 83

A3.2 Version Transparency ....................................................................................................... 84

A3.3 Separation of State ........................................................................................................... 85

References .................................................................................................................................... 87

Glossary ......................................................................................................................................... 89


vi | P a g e

List of Figures

Figure 1: Research conceptual model ............................................................................................. 3

Figure 2: Design Science Process .................................................................................................... 4

Figure 3: Archimate Technology Layer Meta Model ...................................................................... 8

Figure 4: TOGAF Enterprise Continuum .......................................................................................... 9

Figure 5: Classification of architecture disciplines according to NGI............................................ 10

Figure 6: ASC part of RAL .............................................................................................................. 12

Figure 7: Dependencies in the ASC part of the RAL ...................................................................... 14

Figure 8: Artefact Requirements .................................................................................................. 15

Figure 9: Generalization of the Normalised Systems Theory - Peter De Bruyn ........................... 17

Figure 10: Housing 1.0 Modular Structure ................................................................................... 23

Figure 11: Effect of change to Housing 1.0 ................................................................................... 24


Figure 13: Power Distribution Units, Patch panels and cable trays ............................................. 26


Figure 15: Microsoft seaborne data centre container .................................................................. 28

Figure 16: Hosting 1.0 modular Structure .................................................................................... 31

Figure 17: Hosting 2.0 modular Structure .................................................................................... 33

Figure 18: Proxy modular Structure .............................................................................................. 37

Figure 19: Housing 1.0 modular Structure .................................................................................... 49

Figure 20: going from BNC to CAT3/5/6 cables ............................................................................ 51

Figure 21: Different SCSI cables and connectors .......................................................................... 52

Figure 22: from SCSI to FC and from From SC to LC Fiber connectors ......................................... 52

Figure 23: Result unstructured cabling ......................................................................................... 54

Figure 24: Housing 2.0 modular Structure .................................................................................... 55

Figure 25: Patch panels and power distribution units .................................................................. 56

Figure 26: Housing 3.0 modular structure .................................................................................... 59

Figure 27: Zone concept ............................................................................................................... 59

Figure 28: Hot and cold air distribution in Zone ........................................................................... 60

Figure 29: Cooling of a zone .......................................................................................................... 60

Figure 30: Top of Rack concept, including redundancy ................................................................ 61

Figure 31: Data Center of the future according to Microsoft ....................................................... 65

Figure 32: Hosting 1.0 modular structure ..................................................................................... 68

Figure 33: Hosting 2.0 modular structure ..................................................................................... 71

Figure 34: Proxy modular structure .............................................................................................. 76


vii | P a g e

List of Tables

Table 1: OIAM Building blocks ........................................................................................................ 9

Table 2: ASC as part of RAL ........................................................................................................... 12

Table 3: Normalization Principles ................................................................................................. 17

Table 4: Manifestations of C, S, V and I ........................................................................................ 18

Table 5: GNST Compliancy check summary .................................................................................. 19

Table 6: Housing 1.0 GNST Compliance summary ........................................................................ 24



Table 9: Hosting 1.0 GNST Compliance summary......................................................................... 32

Table 10: Hosting 2.0 GNST Compliance summary ...................................................................... 34

Table 11: Proxy GNST Compliance summary ................................................................................ 38

Table 12: Expert Team Evaluation 11 of the 13 Expert Team members ................................... 39

Table 13: CE at different layers of the RAL ................................................................................... 41

Table 14: Ethernet speed evolution.............................................................................................. 63

Table 15: Max cable length for Ethernet ...................................................................................... 63


viii | P a g e


ix | P a g e

Acknowledgements

Glorie Deze reis omvatte veel emoties Midden in de grote ommezwaai van mijn leven Doorzetten met veel devotie Het heeft mij pure zuurstof gegeven Vele mensen moet ik mijn dank betuigen Zonder hen was het niet gelukt Lofzangen zal ik uit mijn duim zuigen Onder het wierookvat ga ik gebukt Wie beter om mee te starten Dan hij die weet wat mijn schrijven behelst Graag zou ik met hem normalized biljarten Mijn oprechte dank aan Jan Verelst Engie moet ik ook vermelden Onder de vorm van een manager, nen echte struise Begrepen wat ik hem vertelde deed hij zelden, Maar toch, merci Paul Buyse Zoveel toffe mede studenten Ik zal hen 1 voor 1 missen Harten van koekebrood met krenten Uit mijn geheugen zijn ze niet te wissen Het professoren korps van AMS Ben ik dankbaar voor het delen van hun kennis Van een aantal kreeg ik lichte stress Oeps, dit is heiligschennis Namaan, Frdric and Jenny I salute you for your generous feedback Your input was worth more than a penny My French normalized infrastructure stack


x | P a g e

Philippe en Christel, Jullie woorden ware pure erkenning Fijn dat jullie tijd stopten in mijn epistel Sentimenten gespeend van gewenning

Een dankje voor de Koen Motor van de UCC infrastructuur Waar is de kok van toen Hij kookt nu IT met passie en vuur Christof ontmoette nimmer Frank Maar toch waren zij mijn NST referenties Van hen hoorde ik een andere klank Of ware het de foute moppen over haarextensies Marc en Dirk, de nestors Hun feedback was niet om mee te lullen Met hun ideen uiteengezet als volleerde lectors Ik kon er nog 2 thesissen mee vullen De wetenschap bespreek ik met Frederik, Een wijzer man is er niet te vinden Mijn besognes deel ik met Cdric, Ja die 2 zijn echte vrienden Zonder Stefan was het iets anders geworden Voor de verandering gaf hij mij structuur In hart en rede zijn wij verbonden Dankbaarheid tot voorbij ons laatste uur Waar was ik geweest zonder moeder aan mijn zij Terwijl ik de student was uit gaan hangen Droeg zij zorgt voor die 2 parels van mij Voor jouw zijn al mijn koor- en lofzangen En nu mijn liefste meisjes Richt pappie een woordje tot jullie Kleurders van mijn leven met zomer ijsjes De zin, mijn zijn, mijn ware glorie

Drs G


1 | P a g e

1 Executive Summary

Businesses are required to be more and more agile to compete in todays marketplace. An agile

Business requires agile IT. Agile IT is an IT which is able to change quickly and without

introducing a massive amount of unwanted side effects, as those will undermine the agility.

The Generalized Normalized Systems Theory (GNST) studies the effect of change on modular

structures and has come up with 4 principles which, when followed, allow the creation of

modular structures which will stay stable no unwanted side effect know as Combinatorial

Effects (CE) - under change.

IT is not only about applications and software, there is also IT Infrastructure, the backbone on

which all applications run. How well can IT Infrastructure handle change?

This thesis is about applying the General Normalized Systems Theory (GNST) on IT

Infrastructure. When IT Infrastructure is represented by a modular system, the GNST principles

can be tested. A tool is being created to test and evaluate the compliance of a modular system

representing an IT Infrastructure System, with the GNST. The Engie IT Reference Architecture

Library (RAL) is used as a source of definitions of IT Infrastructure Systems.

When an IT Infrastructure System is not compliant with the 4 GNST principles, Combinatorial

Effects (CE) - hidden coupling or dependencies in a system which increase with the size of the

system - are to be expected when the IT Infrastructure System changes.

The thesis shows the GNST can be applied for IT Infrastructure Systems represented by a

modular structure. The non-compliance with the GNST predicts CE which are practically

observed. Multiple examples of CE are given and explained by means of the GNST principles.

Besides the demonstration that the GNST can be applied to IT Infrastructure Systems, the thesis

also demonstrates the usage of the GNST in a new field IT Infrastructure.

The value of the thesis lies in recognizing that knowing and applying the GNST on IT

Infrastructure Systems is an essential skill for an Architect as it allows him/her to create

scientifically proven roadmaps taking into account the impact of future evolutions and change

on the IT System.


2 | P a g e

2 Introduction

2.1 Problem Statement

Today it is all about Agility. Businesses need to react fast on changing conditions of the

marketplace and on what the competition is doing. Businesses change their offerings, services,

restructure internally to be better armed for these turbulent times.

Agility is required at all levels and domains of the organization. The only constant is change. All

this has impact on the IT landscape: Applications as well as Infrastructure. A lot of literature can

be found on creating and changing applications in an agile way, but little guidance, exists with

regards to IT Infrastructure, except the trendy statement put it in the cloud

Can extra guidance be given at the IT Infrastructure level on how to create systems which can

cope with change or can the impact of change be investigated during design time and/or

runtime?

The Generalised Normalised Systems Theory (GNST) is a theory about the behaviour of Modular

Structures under change. Can the Generalised Normalised Systems Theory (GNST) be used to

provide guidance on the design of IT Infrastructure Systems under change?

2.2 Research Question

Can the Generalised Normalised Systems Theory (GNST) be used to study the behaviour of IT

Infrastructures under change?

This leads to the following research questions:

Part 1: Can the Generalised Normalised Systems Theory (GNST) principles be applied to

modular structures representing IT Infrastructure?

Part 2: Can Combinatorial Effects (CE) - hidden coupling or dependencies in a system which

increase with the size of the system - be predicted and recognized at the IT Infrastructure level

by using the Generalised Normalised Systems Theory (GNST)?

Part 3: What is the added value of using the Generalised Normalised Systems Theory (GNST)

at the IT Infrastructure level?


3 | P a g e

2.3 Conceptual Model

Figure 1: Research conceptual model

The Engie IT Reference Architecture Library (RAL, see section 3.2) contains an extensive list of

Infrastructure Systems. Of some of those Infrastructure Systems, a detailed modular structure

will be created. Based on this modular structure the Generalized Normalized Systems Theory

(GNST) will be applied with special attention to compliance with the 4 GNST Principles (see

section 5.1). If the modular structure is not compliant with the 4 GNST Principles, CE

Combinatorial Effects are to be expected.

Based on knowledge of the IT Infrastructure Reality of the studied Infrastructure Systems, CE

can be observed in real life. Those CE can be linked to the predicted CE.

By doing so, the applicability of the GNST for IT Infrastructure can be confirmed.

2.4 Research Methodology

The research will apply the GNST principles to IT Infrastructure. Design Science has been chosen

as approach to conduct this research. Paul Johannesson and Erik Perjons1 propose a process to

perform Design Science. The result of this Design Science process is an Evaluated Artefact.

1 An Introduction to Design Science Paul Johannesson, Erik Perjons - 2014


4 | P a g e

Figure 2: Design Science Process

The Artefact is a Generalised Normalised Systems Theory (GNST) analysis tool, demonstrated

on IT Infrastructure modular structures and evaluated by an Expert Team.

Explicate Problem is handled in Chapter 3 and will focus on the context of the problem

statement, will discuss what IT Infrastructure is and what the Engie IT Reference Architecture

Library (RAL) is about.

Define Requirements is handled in Chapter 4 and will focus on what is expected from the

Artefact to address the Research Question.

Design and Develop Artefact is handled in Chapter 5 and focus on the creation of an Artefact

which can be used to apply the Generalised Normalised System Theory (GNST) at the

Infrastructure layer, and thus providing an answer to Part 1 of the Research Question (Can the

GNST principles be applied to modular structures representing IT Infrastructure ?)


5 | P a g e

Demonstrate Artefact is handled in Chapter 0 and will focus on applying the Artefact to three

Infrastructure modular structures and thus provide an answer to Part 2 of the Research

Question (Can CE be predicted and recognized at the IT Infrastructure level by using the GNST ?)

Evaluate Artefact is handled in Chapters 7, 8 and 9

Chapter 7 will focus on a qualitative analyses of the Artefact demonstration by an Expert team,

and on the quality of the answer to Part 2 of the Research Question.

Chapter 8 will focus on additional feedback by the Expert team with regards to the Artefact and

its applicability in IT Infrastructure

Chapter 9 will focus on the value the Artefact has to IT Infrastructure architecture and to the

Reference Architecture Library (RAL) of Engie IT and thus providing an answer to Part 3 of the

Research Question (What is the added value of using the GNST at the IT Infrastructure level ?)

Chapter 10 will contain the overall conclusion of the Research and additional reflections.

Research Strategies and Methods, Creative Methods are based on the following:

The Generalised Normalised Systems Theory (GNST)

The Engie IT Reference Architecture Library (RAL)

IT Infrastructure knowledge of the Expert Team

ArchiMate and Open Infrastructure Architecture Method (OIAM)

Accumulated knowledge of the writer

Knowledge Base

The GNST has never been applied to an IT Infrastructure modular structures. As such, there is

no formal knowledge base against which the Artefact can be evaluated.

In this research the Artefact will be evaluated by an Expert Team. The accumulated knowledge

in the field of IT Infrastructure of this team will serve as Knowledge Base.

The Expert team is asked to evaluate:

The Correctness of the IT Infrastructure Modular Structure that is being investigated.

The Correctness of the Analyses done in the Artefact (applying the GNST principles).

Value of the Artefact.

The Expert Team consists of people who have:

IT Infrastructure expertise for at least 10 years

Knowhow of the GNST and NST for at least 4 years

IT Infrastructure Management expertise for at least 10 years


6 | P a g e

Expert Team:

Frederik Leemans: IT Enterprise Architect Alkasa consulting

Dirk Timmerman: Infrastructure Architect - Athos

Cdric Carrette: Infrastructure Architect - Carrette GCV

Koen Van den Broeck: Infrastructure Architect - Engie IT

Marc Kimpe: Infrastructure Architect - Cronos

Frank Van der Veken: Security Architect - Engie BeNeLux

Christophe De Clercq: Application Architect - Contribute group (Cronos)

Stefan Thys: Project Manager - Quantum Management and Consulting

Christel Plessers: CIO - Mercedes Benz France

Philippe Le Cerf: CIO - Vinotte

Frdric Deleage: Infrastructure Architect Engie IT

Jenny Edouard: Infrastructure Architect Engie IT

Namaan Boutighane: Infrastructure Architect Engie IT


7 | P a g e

3 IT Infrastructure and the Engie IT

Reference Architecture Library

Before the Artefact can be applied at the level of IT Infrastructure, there must be a common

understanding of what IT Infrastructure is. As the Artefact will be demonstrated on IT

Infrastructure modular structures defined in the Engie IT Reference Architecture Library (RAL),

the meaning and content the Engie IT RAL will be explained.

3.1 IT Infrastructure

The next sections will work towards a definition of IT Infrastructure.

3.1.1 Architecture Frameworks

IT Infrastructure or Infrastructure for short has less focus in Architecture Frameworks and

Methodologies compared to the Application and Business components. Commonly used

Architecture frameworks such as TOGAF do not go into details when it comes down to

Infrastructure.

TOGAF2 refers to the Technical layer when it comes down to Infrastructure and is not alone in

this.

The British Computer Society's "Reference Model for Enterprise and Solution Architecture"3

defines different Types of Architecture and sees IT Infrastructure Architecture as follows:

Technical architecture or infrastructure architecture: The structure and behaviour of the technology

infrastructure. Covers the client and server nodes of the hardware configuration, the infrastructure

applications that run on them, the infrastructure services they offer to applications, the protocols and

networks that connect applications and nodes.

This shifts the question from What is Infrastructure? to What is Technical?

3.1.2 ArchiMate

Like TOGAF, ArchiMate4 talks about the Technology Layer in its framework and about

Infrastructure components in its Meta Model.

This Meta Model contains abstract constructs which can represent infrastructure components.

2 TOGAF Version 9 The Open Group

3 en.wikipedia.org/wiki/Architecture domain

4 ArchiMate 2.0 The Open Group

https://en.wikipedia.org/wiki/Technical_architecture


8 | P a g e

Figure 3: ArchiMate Technology Layer Meta Model

The Technology Layer of ArchiMate describes the Infrastructure in a formalized language.

What ArchiMate, does not provide, is a proper definition on what Infrastructure actually is.

3.1.3 OIAM

The Open Infrastructure Architecture Method (OIAM)5, uses the concept of Infrastructure

Functions of ArchiMate to build a generic library of Infrastructure functions. OIAM has built this

library based on practical experience and the library is maintained by a user community. With

the Infrastructure Functions of the Library, Infrastructure Patterns can be made, which are an

aggregation of the Infrastructure Functions.

OIAM is structured like the Enterprise Continuum of TOGAF with Infrastructure Functions as the

generic building blocks part of the Architecture Continuum:

The Patterns are the generic solutions of the Solution Continuum,

The Specific Patterns as specific solutions of the Solution Continuum,

Deployed Patterns as part of the Deployed Solutions Continuum.

5 OIAM - www.infra-repository.org


9 | P a g e

Figure 4: TOGAF Enterprise Continuum

List of Infrastructure Functions according to OIAM

Table 1: OIAM Building blocks

OIAM is one of the few generally available Infrastructure Framework which provides:

A library of Infrastructure primary concepts (the functions),

A modelling method by using ArchiMate,

A way to focus on Infrastructure Function instead of Infrastructure Construction,

A way to treat Infrastructure from a functional point of view as often done at the Business and

Application layers.


10 | P a g e

3.1.4 GRAAL

In the book Competences of the IT Architect, Wieringa et al6 try to summarize the key

competences of different IT Architecture types, but quickly conclude that, as different sources

use different definitions for both the Architecture domains and Architect classifications, they

require a reference framework to structure their study. The GRAAL7 framework is used to

position the different Architecture domains. With the domains being fixed they compare

different Architect classifications or profiles to see which profile covers which part of the

domains.

The GRAAL framework uses the following layering:

Business environment (BE): entities in the environment of the organisation to which the

organisation delivers products and/or services. For commercial companies, the most important

element types of the business environment are their customers.

Business (B): the products and services that the organisation produces for its environment, the

processes that create these products and services, the employees who perform those processes,

the formal and informal relations between those employees, etc.

Enterprise software systems (ESS): organisation specific software systems that support the

processes and people in the business.

Software infrastructure (SI): software systems that are not specific for the organisation, such as

operating systems, database management systems, email servers, etc.

Physical infrastructure (PI): processors, disks, network routers, switches and cables, and all other

physical objects that are needed to run the software systems that constitute the business

systems and software infrastructure layers.

Figure 5: Classification of architecture disciplines according to NGI

The NGI (Nederlands Genootschap voor Informatica) has plotted on this framework their

classification of architecture disciplines/profiles. By doing so a clear definition of Infrastructure

Architecture and the profile of Infrastructure Architect becomes visible.

6 Competences of IT Architects Roel Wieringa, Pascal van Eck, Claudia Steghuis, Erik Proper - 2009

7 graal.ewi.utwente.nl


11 | P a g e

The combination of GRAAL and NGI bring a definition of Infrastructure which is exactly how it is

treated within Engie IT:

Infrastructure = Physical Infrastructure (according to GRAAL) + Software Infrastructure (according to GRAAL)

Hence, Infrastructure Architecture is about the structure of an Infrastructure system, its

components, their relationship and principles guiding their evolutions8. Infrastructure

Architecture is a conscious restriction of Infrastructure design space9.

3.2 Engie IT RAL

3.2.1 Concept

Since 2009 the group of Infrastructure Architects at Engie IT has been using ArchiMate as

modelling language for all Infrastructure models.

The Infrastructure Usage View (IUV) is a view predefined in ArchiMate which focuses on how

Infrastructure services are realised and how they are used by Applications. This view is very

relevant as Engie IT delivers Infrastructure Services to the internal Business Units of Engie.

Although a good starting point in finding a unified way of working and modelling amongst

Infrastructure Architects, it became clear that models and the names given to the modelling

concepts largely remained un-standardised. Additional normalization resulted in 2011 in the

introduction of the RAL. The RAL is the Reference Infrastructure Library and includes all

conceptual and deployed Architectures. The RAL is a simplified implementation of the

Enterprise Continuum of TOGAF applied at the Infrastructure layer.

Where the starting point of OIAM is Infrastructure Functions, the starting point of the RAL is

Infrastructure Services. At the time the RAL was created, ArchiMate 2.0 did not exist yet and

neither did the concept of the Infrastructure Function. The idea behind the RAL and OIAM is

identical: a library of Architecture Building Blocks which can be combined to create new

Architecture Patterns - this library is referred to as the Architecture Solutions Continuum (ASC).

When those Building Blocks and Patterns are being deployed, they become part of the

Deployed Solutions Continuum (DSC).

The Architecture Solutions Continuum (ASC) contains the conceptual Infrastructure services and

how they should be build,

The Deployed Solutions Continuum (DSC) contains the deployment of such services in a specific

context (for one of the BUs Engie IT creates services for).

8 Defining Architecture IEEE 1471

9 Enterprise Governance and Enterprise Engineering Jan A.P. Hoogervorst - 2009


12 | P a g e

The Architecture Solution Continuum can be split into 3 large categories:

IBS Infrastructure Basic Services

Contains the most elementary Infrastructure Services required to run an application and manage a data centre.

Examples: Housing, Hosting, Network, Tooling, Monitoring, etc.

IPS Infrastructure Platform Services

Contains the Infrastructure Services which are the aggregation of Infrastructure Basic Services and software on which applications can be deployed.

Examples: DB platform, WAS platform, SAP platform, etc.

ISS Infrastructure Solution Services

Contains the Infrastructure Services which are the aggregation of Infrastructure Basic Services, Platform Services and Software.

Examples: Remote Access, Mail, Unified Communication, Voice over IP.

Table 2: ASC as part of RAL

Figure 6: ASC part of RAL

Note that this corresponds entirely with what GRAAL defines as the Physical and Software

Infrastructure:

IBS 1. Physical Infrastructure and Software Infrastructure

IPS 2. A combination of Physical and Software Infrastructure on which


13 | P a g e

Enterprise Software Systems can be deployed

ISS 3. Software Infrastructure

A specific naming convention is applied to all Infrastructure Services defined in the Architecture

Solutions Continuum (ASC) of the RAL. The same principle is used as DNS name, which is

appended to the left to become more specific.

Example:

Level 1: IBS - Infrastructure Basic Service

Level 2: Hosting-IBS Infrastructure Basic Service of type Hosting

Level 3: Virtual-Hosting-IBS Infrastructure Basic Service of type Virtual Hosting

Level 4: Windows-Virtual-Hosting-IBS Infrastructure Basic Service of type Windows Virtual

Hosting

Max 4 levels are defined and in total about 160 Infrastructure services are defined in the ASC.

Each of these services should have corresponding Patterns which are in line with the defined

standards in the company.

When a new service is being created for one of Engie ITs clients, one or more services of the

Architecture Solutions Continuum (ASC) are being instantiated and deployed in one of Engie ITs

Data Centres.

The infrastructure gets a name which will contain 2 parts:

A Deployed Solutions Continuum (DSC) reference name something meaningful to the client

and,

The Architecture Solutions Continuum (ASC) reference, indicating the Type the Infrastructure

Service according to the Architecture Solutions Continuum (ASC)

3.2.2 RAL as a Modular Structure

The RAL is a modular structure. The Services defined in the RAL represent a grouping of

functionalities which are combined together to deliver a service which is useful and meaningful

to Engie ITs clients.

This modular structure exists in the Architecture Solutions Continuum as the different

Infrastructure Basic Services (IBS), Infrastructure Platform Services (IPS) and Infrastructure

Solution Services (ISS) have interdependencies.

Example:

Hosting-IBS always uses Housing-IBS because you need physical location to put a machine and

then the Operating System Software can be installed to create a Hosting-IBS.


14 | P a g e

Figure 7: Dependencies in the ASC part of the RAL

The modular structure exists as well in the Deployed Solutions Continuum (DSC) as it will

combine different instantiations of Architecture Solutions Continuum (ASC) Services. The

dependencies defined in the Architecture Solutions Continuum) (ASC) will reappear in the

Deployed Solutions Continuum (DSC) they exist at design time and thus also during run time.


15 | P a g e

4 Artefact Requirements

This chapter will elaborate on the Requirements of the Artefact

The Artefact must be able to provide an answer to the question how an Infrastructure System

will behave under change.

Generalised Normalised Systems Theory (GNST) studies the impact of change on a modular

structure. The input for the Artefact must thus be a modular structure representing an

Infrastructure System.

The Artefact must thus contain a mechanism to translate the Generalised Normalised Systems

Theory (GNST) concepts toward an Infrastructure Context.

Based on this translation, the 4 GNST can be tested against the modular Structure.

The Artefact must contain a conclusion with regards the evolvability of the Infrastructure

System and provide guidance to improve the evolvability of the Infrastructure System.

Figure 8: Artefact Requirements


16 | P a g e

5 Artefact Design

In the previous 2 chapter it has been defined what is being meant with Infrastructure and what

the requirements are for an Artefact which will evaluate the behaviour of an Infrastructure

System under change.

This chapter will focus on the design of the Artefact. The Generalised Normalised Systems

Theory (GNST) will be shortly introduced followed by the contextualisation of the GNST toward

Infrastructure Systems. The chapter ends with the formal design of the Artefact.

5.1 General info on the Generalised Normalised

Systems Theory

The Normalised Systems Theory (NST) is a theoretical framework which allows the investigation

of Modular Structures under change and which is based on concepts of System Theory. The

theory was first constructed and applied at the software level with focus on Modular Structures

in Software Architecture. It provides an answer to the question on how to make software

evolvable without degenerating the software and keeping it free of Combinatorial Effects.

Combinatorial Effects (CE) are hidden coupling or dependencies in a system which increase with

the size of the system.

A system is considered unstable under change when the impact of a change is directly

proportional to the change itself AND the size of the System.

The NST has been applied at the Software Level10.

The NST has been applied at the level of Industrial Automation Systems11.

The NST has been applied at the level of Business Processes12.

The NST has been applied at the level Enterprise Engineering13

Based on the multiple applications of the NST outside its original Software scope, the theory got

generalized in the General Normalized Systems Theory14.

10

Normalized Systems Herwing Mannaert, Jan Verelst - 2009 11 Towards adaptive flexibility in automation systems: industrial control software based on normalized systems theory - Dirk van der Linden 2014 12

Towards designing Modular and Evolvable Business Processes. - Dieter VAN NUFFEL 2011 13

On the Feasability of Normalized Enterprises: Applying Systems Theory to High-Level Design of Enterprises. - Philip HUYSMANS


17 | P a g e

Figure 9: Generalization of the Normalised Systems Theory - Peter De Bruyn

A system is considered a Normalized System when the modular structure of the System is

compliant with the following 4 principles:

Separation of Concerns (SoC) A primitive should only contain one concern. 2 types of concerns are identified: change driver: each part of the modular structure which can independently change information unit: each part of the modular structure of which we are interested in contains independent information regarding its execution

Separation of State (SoS) When a primitive uses another primitive as it is executed, both primitives should be separated by a state.

Version Transparency (VT) A primitive which is used by other primitives should be version transparent

Instance Traceability (IT) The input received to execute a particular primitive instance, as well as the output delivered by that primitive instance should be traceable to the particular version and instance of that primitive.

Table 3: Normalization Principles

When a System is compliant with these principles, it will have ZERO Combinatorial Effects (CE)

under change which would make the system highly evolvable.

14 Generalizing normalized systems theory: towards a foundational theory for enterprise engineering - De Bruyn Peter - 2014

http://anet.uantwerpen.be/record/irua/opacirua/c:irua:120619


18 | P a g e

5.2 Contextualisation for Infrastructure Systems

In order to investigate if a modular structure is compliant with the Generalised Normalised

Systems Theory (GNST), the concepts of the GNST being Concern, State, Version and Instance

must manifest themselves in the modular structure.

For each module, a manifestation of Concern, State, Version and Instance must be found and

then checked if those manifestations in the module respects the 4 Principles.

For some Infrastructure Systems, State and Instance do not apply (see chapter 6).

Example:

A module representing Calculation

Table 4: Manifestations of C, S, V and I

A similar exercise must be made for each module which is part of the Infrastructure system

under investigation:

What are the manifestations of Concern, State, Version and Instance,

Do those manifestations respect the 4 Principles

If one or more of the principles are not respected, then CE will occur.

5.3 Artefact Description

5.3.1 Artefact input

An ArchiMate model representing an Infrastructure System. The Infrastructure system is the

aggregation of the different modules of which the Infrastructure System is made up.

Dependencies between the modules are shown by means of the used by relation.

5.3.2 Artefact Content

1. GNST compliance check


19 | P a g e

For each module in the Infrastructure System, find the manifestations of Concern, State,

Version and Instance. Then evaluate if the GNST principles are respected. If they are not

respected, note the practical observed CE due to this non-compliance. Summarize the results in

the table below:

Table 5: GNST Compliancy check summary

2. Evolvability of the Infrastructure System

Based on the GNST compliance check, the Artefact will contain a general observation

about the evolvability of the Infrastructure System.

3. Guidance with regards to evolvability

If the GNST principles are not respected, there will be issues related to future changes in

the Infrastructure System. This section can contain guidelines on how to mitigate the

impact or on how to restructure the Infrastructure System to eliminate or mitigate the

impact.


20 | P a g e

6 Demonstrating the Artefact

The Artefact will be demonstrated on 3 Infrastructure Systems defined in the Engie IT RAL:

Housing-IBS

Hosting-IBS

Proxy-network-IBS

The modular structures representing the Infrastructure Systems are not mirrors of the actual

reality and contain simplifications. The objective is to demonstrate the Artefact can be applied,

not to create imitation models.

Before the Artefact is applied, the different modules of the Infrastructure System are

introduced. The detailed study used to eventually fill out the GNST Compliancy check summary

table, can be found in Appendix 1.

6.1 Housing Infrastructure Basis Service

Housing Infrastructure Basic Services (HousingIBS) offer basic Data Centre services to IT

Equipment installed in a Data Centre, such as floor space, power, cooling, cabling.

A Housing Infrastructure System is made up of the following modules:

Location: Delivering a physical location, expressed in x, y coordinates in a physical room.

Power: Delivering electrical power

Cooling: Delivering cooled and conditioned air to IT equipment

Rack: Delivering vertical stacking of equipment (z coordinate)

Cabling: Delivering interconnectivity between IT equipment

The 5 modules can be linked to each other in different topologies.

Topology 1, referred to as Housing 1.0, represents housing of 20 years ago, but still applied in

small data rooms.

Topology 2, referred to as Housing 2.0, represents housing of 10 years ago, but still practiced in

todays data centres

Topology 3, referred to as Housing 3.0, represents the state of the art data centre setup.

For each of the 3 topologies, the Artefact will be applied. The investigation of the

manifestations of Concern, State, Version and Instance is identical in the 3 topologies and will

be introduced before the Artefact is applied do the 3 topologies.


21 | P a g e

6.1.1 Manifestations of Concern, State, Version and Instance

6.1.1.1 Location

Concern: In this simplified model, location addresses 1 concern, delivery of x and y

coordinates.

State: Location has no manifestation of State. Location is a set of physical

coordinates which do not require to persist their state externally nor

exchange their state with other modules.

Version: Location has no manifestation of Version. The model takes the assumption

that the actual Location, does not change.

Instance: Location has no manifestation of Instance. An equipment cannot be at 2

different locations (2 different instances) at the same time.

6.1.1.2 Power

Concern: Power addresses multiple concerns. Delivery of electrical current to a specific

location (physical cabling, copper, insulation, switch boards etc. making up

the power grid) and connecting the IT equipment to the power grid.

State: Power has a binary state on or off. By means of meters installed in the

switchboards, colouring of the switches (on = red, off = green), led indicators,

Power is able to persist its state outside of itself.

Version: Power can have different versions. Electrical power can be delivered in

different form (220V/50Hz, 3x380V/50Hz, 110V/60Hz) and connectors

(outlets and connectors) can differ as well.

Instance: Power has no manifestation of instance.

6.1.1.3 Cooling

Concern: Cooling addresses multiple concerns. Delivery of conditioned air, the

distribution of the conditioned air to the right location and the extraction of

hot air.

State: Cooling has multiples states. The actual cooling installation will persist its

state on a control board, indicating air temperature and humidity. Via sensors

in the room, the distribution of the conditioned air and accumulation of hot

air can be measured. The State of Cooling can be persisted outside the

module, if the modules includes the necessary technologies (sensors and

status indicators etc.) to do so.


22 | P a g e

Version: Cooling exists in different versions. Centralized, decentralized, air cooled,

water cooled etc.

Instance: Cooling has no manifestation of instance.

6.1.1.4 Rack

Concern: Rack can address multiple concerns, depending how it integrates with the

other modules. Primarily Rack delivers vertical placement of IT Equipment a

z coordinate. Rack can also serve as proxy for power, cooling and cabling. In

the different Housing Topologies, the impact of using Rack for one or more

concerns will be addressed.

State: Rack has no manifestation of State.

Version: Rack can have different versions. Racks come in different form factors.

Instance: Rack has no manifestation of Instance.

6.1.1.5 Cabling

Concern: Cabling addresses multiple concerns. It acts a physical medium to transfer

signals over a certain distance (via copper or fibre). It also connects IT

equipment with this physical medium.

State: The State of Cabling can be observed by means of control LEDs (if a signal

detected yes/no, or the transfer speed of the data over the wire). These LEDs

will be available on the IT equipment to which the cabling is connected.

External components to Cabling make the State of Cabling visible.

Version: Cabling can have different versions. The type of wire and insulation of the

wire will determine maximum data transfer rates. The connectors of the wire

come in different form factors.

Instance: Cabling has no manifestation of instance.


23 | P a g e

6.1.2 Applying the Artefact to Housing 1.0

6.1.2.1 Artefact Input Graphical Modular Structure

Figure 10: Housing 1.0 Modular Structure

The Housing 1.0 Pattern delivers the Housing-IBS service as described in the Engie IT

Reference Architecture Library (RAL). This service is used by the IT Equipment.

In Housing 1.0 Rack is only used to provide vertical space to the IT Equipment. The IT

Equipment is directly linked to Rack, Power, Cabling and Cooling.


24 | P a g e

6.1.2.2 Applying the Artefact

1. GNST Compliancy Check

Figure 11: Effect of change to Housing 1.0

Table 6: Housing 1.0 GNST Compliance summary

(1): State concept reduced to persist state external to module


The GNST principles are not respected and CE are expected under change. Observed CE confirm this hypothesis. Housing 1.0 is still used today in

small data rooms. The effect of frequent change is best demonstrated in Figure 11. Housing 1.0 is not an evolvable system.


Cleaner cabling, via cable trays may help reduce the entropy of the system. Use a Housing 2.0 topology.


25 | P a g e




In Housing 2.0, the IT Equipment is no longer directly linked with Cabling, Power and Cooling.

Rack will contain proxies for:

Cabling by means of integrated patch panels and cable trays.

Power by means of Power Distribution Units.

Cooling by means cooling fans at the top and bottom of the Rack.

Rack becomes an Elements, as described in the Normalized System Theory (NST).


26 | P a g e



Figure 13: Power Distribution Units, Patch panels and cable trays




Rack has the characteristics of an Element due to the proxies in Rack. Equipment can be added without introducing CE. When a Rack is full, a

new Rack needs to be installed and at that point CE may be introduced again. CE are still present when changes occur in Cabling, Power and

Cooling.


Plan the layout of the computer room to anticipate the addition of new racks. Use a Housing 3.0 topology.


27 | P a g e




In Housing 3.0, a new module is introduced called Zone, which consists of 2 rows of Racks,

installed back to back, with sufficient space between the 2 rows to allow human interventions.

A Zone is a containerization concept, including all the Proxies for Power, Cooling and Cabling.

More details on a Zone setup can be found in Appendix 1


28 | P a g e



Figure 15: Microsoft seaborne data centre container




Zones can be stack next and onto each other, providing a mechanism to deliver housing facilities. The Version Transparency issues are solved by

adding new containers containing version compliant components. Zones can be added theoretically indefinitely. Practically, there are always

physical limits (for location, cabling, power and cooling) which will restrict this at some point.


If zones can produce their cooling and power themselves, like the Microsoft seaborne data centre container (see Appendix 1 for more info).


29 | P a g e

6.2 Hosting Infrastructure Basis Service

Hosting Infrastructure Basic Services deliver Hosting Services. Hosting is the combination of a

hardware platform and an Operating System (OS), offering the possibility to exploit the

hardware resources via an Operating System (OS). A Hosting Infrastructure System is made up

of the following modules:

Computer Hardware: Delivering process power, memory and Input/output control

Operating System Kernel: Provides access to the Computer hardware

Operating System Stacks: Different software stacks running on top of the OS kernel which

allow applications to get access to the network and storage resources, access to the

graphical power of the hardware, access to the OS process and resource

management capabilities.

Framework stacks: Different software stacks which allow the exploitation of the computer

resources by combining and packaging the functionalities offered by the OS Kernel,

Network, Storage, Graphical, Process and Resource Stacks in different software

packages usable in different programming languages.

The represented simplified Hosting Infrastructure System is OS agnostic. The Hosting

Infrastructure System uses a Housing, Network and Storage Infrastructure System.

The next sections will discuss 2 topologies:

Hosting 1.0, a Physical hosting Topology

Hosting 2.0, a Virtual hosting Topology

For each of the topologies, the Artefact will be applied. The investigation of the manifestations

of Concern, State, Version and Instance is identical in the 2 topologies and will be introduced

before the Artefact is applied do the 2 topologies.


6.2.1.1 Computer Hardware

Concern: Computer Hardware addresses multiple concerns - CPU, GPU, MEM, IO. Computer

Hardware is a fine grained modular structure and has been source of inspiration for

the creation of the Normalised Systems Theory. The assumption is taken that,

although multiple concerns are addressed, they can packaged in such a way that

these multiple concerns are not source of CE.

State: Computer Hardware has manifestation of State, the state is persisted outside the

module and can be interrogated. Example is the ability to lookup CPU and memory


30 | P a g e

usage. Some Computer Hardware will also persist state to transmit information.

Examples are the usage of buffers where one hardware module writes requests for

instruction execution and another module will read those requests and execute

them.

Version: Computer Hardware has manifestation of Version - CPU versions, memory etc.

Compatibility matrices will show which hardware versions are compatible and thus

have Version Transparency.

Instance: Computer Hardware has no manifestation of Instance.

6.2.1.2 Operating System Kernel

Concern: Operating System Kernel addresses multiple concerns. Pushing instructions to the

CPU, transferring data from Memory to buffers, reacting on interrupts, performing

Input/output The OS Kernel is an aggregation of functionalities.

State: Operating System Kernels has a state and will persist this state in logs. Operating

Systems Kernels work in a synchronous mode. State is not used to transfer

information between sub modules.

Version: Operating System Kernel come in different versions, linked to the Operating System

release and Operating System patch level. Version compatibility issues can occur.

Instance: Operating System Kernel has no manifestation of Instance.

6.2.1.3 Operating System Stacks

Concern: Operating System Stacks address multiple concerns. For instance in the Network

stack, the 7 OSI layers are addressed to make sure data can be transferred from one

computer to another.

State: Operating System Stacks will persist their state in logs. Calling functions of an

Operating System Stack happens synchronous, although the internal processing

may be asynchronous.

Version: Operating System Stacks come in different versions, linked to the Operating System

release and Operating System patch level. Version compatibility issues can occur.

Instance: Operating System Stacks have no manifestation of instance


31 | P a g e

6.2.1.4 Framework stacks

Concern: Framework stacks address multiple concerns. They can contain all kinds of

combinations of calls toward the Operation System Stacks and the Operating

System Kernel.

State: Frameworks may or may not persist their state. This will fully depend on the

Framework.

Version: Frameworks come in different versions, linked to the Operating System release and

patch level. Version Compatibility issues can occur.

Instance: Multiple instances of Frameworks may run on the OS.

6.2.2 Applying the Artefact to Hosting 1.0


Figure 16: Hosting 1.0 modular Structure


32 | P a g e



Table 9: Hosting 1.0 GNST Compliance summary


Hosting 1.0 has serious evolvability issues mainly due to non compliance with Version Transparency. The CE are unavoidable unless OS versions

and Commercial Of the Shelf (COTS) Applications would respect the 4 principles.


The rule One Operation System, One Application applies.


33 | P a g e

6.2.3 Applying the Artefact to Hosting 2.0


Figure 17: Hosting 2.0 modular Structure

Hosting 2.0 contains a new module the Hypervisor. A Hypervisor is a special Operating

System. It allows the installation of multiple Operating Systems on top of the

Hypervisor. The Hypervisor virtualizes the Hardware, transforming actual CPUs into

virtual CPUs. The main driver for virtualisation is better use of the hardware resources.


34 | P a g e

6.2.3.2 Artefact


Table 10: Hosting 2.0 GNST Compliance summary


Operating System Virtualisation does not solve the evolvability issues found in Hosting 1.0. Hosting 2.0 has the same limitations.


The rule One Application, one Operating System stays applicable but with the advantage that multiple Operating Systems can run on one

machine.

The usage of Application Virtualisation techniques can solve Version Transparency issues (see Appendix 2 for more information).


35 | P a g e

6.3 Proxy Infrastructure Basis Service

Proxy Network Infrastructure Basic Services offer the functionality to convert N to M outbound

traffic into 1 to M outbound traffic as all outbound N are hidden behind the 1 proxy. It is also

caches information, applies network translation and checks if traffic is authorised based on

allowed targets and Identity information provided by the proxy user. A Proxy Pattern is made

up of the following modules:

Proxy Engine: Performs the Proxy activity based on input from the other modules.

NAT Engine: Performs the Network Address Translation to hide the actual IP of Source and

Target.

Rule Engine: Checks if based on Authorised Targets and Identity information provided by the

Source, traffic is allowed of not.

Caching: Caches information of the Target to optimize traffic.

Authorized Targets: Manages the list of Authorised Targets.

Logging: Logs information on the traffic exchanged between Source and Target.

Proxy controls traffic from the company network towards the Internet. For security reasons, the

usage of a proxy for all Sources connecting to Targets on the Internet, is considered mandatory.

But not all Sources are able to connect to a Target via a Proxy! To study the impact of this, the

Extended Proxy Pattern is introduced, which includes the Source as well.


6.3.1.1 Proxy Engine

Concern: Connectivity between Source and Target.

State: Indirectly persists its state in the Proxy log (who accessed what when). Traffic

between Source and Target is synchronous, so no persistence of exchanged

information.

Version: Proxy Engine is part of the Proxy Pattern. The Version of the Engine will be the

version of the Pattern.

Instance: There is no manifestation of Instance in the Proxy Pattern as a Source will

communicate via one Proxy to its Targets.


36 | P a g e

6.3.1.2 NAT Engine

Concern: Network Address Translation of Source and/or Target.

State: No manifestation of State.

Version: NAT Engine is part of the Proxy Pattern. The Version of the Engine will be the




6.3.1.3 Rule Engine

Concern: Checks compliance with identity and authorised target

State: No manifestation of State

Version: Rule Engine is part of the Proxy Pattern. The Version of the Engine will be the




6.3.1.4 Caching

Concern: Cache information of the Target to avoid unnecessary traffic.


Version: Caching is part of the Proxy Pattern. The Version of the Engine will be the




6.3.1.5 Authorized Targets

Concern: Manages the list of allowed Targets


Version: Authorized Targets is part of the Proxy Pattern. The Version of the Engine will

be the version of the Pattern.



6.3.1.6 Logging

Concern: Logs which source has connected to which target, when and how.



37 | P a g e

Version: Logging is part of the Proxy Pattern. The Version of the Engine will be the




6.3.1.7 Source

Concern: Exchange information with Target.

State: No manifestation of State.

Version: Source can have different versions. Different version of browsers and

different versions of applications.

Instance: Of a specific browser and of a specific applications, multiple instances can be

active at the same time. Each needs to be correctly configured to work with

the Proxy.

6.3.2 Applying the Artefact to Proxy


Figure 18: Proxy modular Structure


38 | P a g e

6.3.2.2 Artefact


Table 11: Proxy GNST Compliance summary


The Proxy Pattern respects the GNST principles and is highly evolvable. However, the Extended Proxy Pattern, being the default usage of any

source to use a Proxy to connect to a Target on the Internet, does not respect the GNST. CE can be expected and CE are observed.


Make sure all sources are Proxy compatible. Use tooling to distribute proxy configuration items to all sources (see Appendix 3 for more

information)


39 | P a g e

7 Evaluation of the Artefact qualitative analyses

The analysis of the Infrastructure Modular Structures was presented to the Expert Team in the form of Appendix 1. The summary of

the analyses has been presented in Chapter 6. The Expert Team was requested to score 3 aspects:

The correctness of the Infrastructure Modular Structure the Artefact input

The correctness of the Artefact Analyses Manifestations of Concern, State, Version, Instance and observed CE.

Did the Artefact analyses provide extra insights?

Correctness of the Infrastructure Modular

Structure

Correctness of the Artefact Analyses Did the Artefact analyses provide extra

insights?

Scoring and scale:

1 - The model has no link with reality

2 - The model lacks key elements of reality

3 - The model contains some key elements of reality

4 - The model contains most key elements of reality

5 - The model is an imitation of reality

Scoring and scale:

1 Analyses in contradiction with reality

2 - Analyses lacks key elements of reality

3 - Analyses contains some key elements of reality

4 Analyses contains most key elements of reality

5 - Analyses is fully aligned with reality

Scoring and scale:

1 Not at all

2 - Minor confirmation current insights

3 - Partially confirms current insights

4 - Confirms current insights

5 - New insight

Average: 4.2/5 Average: 4.3/5 Average: 4.4/5

Table 12: Expert Team Evaluation 11 of the 13 Expert Team members


40 | P a g e

8 Evaluation of the Artefact feedback

The Expert Team did not limit itself to scoring the Artefact but provided additional information

with regards to the value of the Artefact and observed CE which they could link to the a

violation of the Generalized Normalised Systems Theory (GNST) Principles.

8.1 Value of the Artefact

A member of the Expert team considered the GSNT Principles as Input for the creation of

Architecture Principles

Two other members find it to be a Meta model which is in line with practical decision making

and Theoretical model explaining why Infrastructure is so tricky.

8.2 Observed CE

The Infrastructure Modular Structures analysed in Chapter 6 are all part of the Infrastructure

Basis Services (IBS) layer of the Reference Architecture Library (RAL). Expert Team members

provided input to practically observed CE which can be linked to a violation of one of the 4

GNST principles, for the 2 other layers Infrastructure Platform Services and Infrastructure

Solution Services. Table 13 contains some CE, observed at the other layers, and classified

according to the Principle they violate. The full details of the analyses can be found in Appendix

2.

The table demonstrates that CE are to be found in all aspects of Infrastructure both physical

and software and that a detailed analyses could be made of those CE by means of the Artefact.


41 | P a g e

15

Table 13: CE at different layers of the RAL

15

Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration (Doc ID 413484.1)


42 | P a g e

9 Artefact Value

Chapter 6 to 8 focused on demonstrating and scoring the Artefact. The Expert Team already

provided some feedback with regards to the value of applying the Artefact. In this chapter, the

value of the Artefact will be studied from the point of view of the existing Engie IT Reference

Architecture Library (RAL), the value the Artefact has for an Architect and the value for the

Generalized Normalized Systems Theory (GNST).

9.1 Value for RAL Engie IT

The Architecture Solutions Continuum part of the RAL (ASC) contains the Infrastructure Building

Blocks Engie IT uses to construct Infrastructure Services for its customer.

Each of the building blocks is a grouping of functionality and these groupings correspond to real

life building blocks which are available on the market. Infrastructure Building Blocks are driven

by what is available at the market. They deliver a certain grouping of functionality and there is

no control over how they are delivered and realized. Essentially there are black boxes.

The models studied in Chapter 6 show generic models of such black boxes. Applying the

Artefact to these models creates insight with regards to the evolvability. Sometimes evolvability

of the infrastructure is not required. In such case applying the Artefact has no value. But as put

forward in the Problem Statement, an Agile Business required an Agile and thus evolvable IT

Infrastructure. Analysing the IT Infrastructure with the Artefact will provide clarity with regards

to the limits of the evolvability of the IT Infrastructure Systems put in place or IT Infrastructure

Systems which the company plans to put in place.

Creating models which focus on the modular structure of Infrastructure Systems is a necessity

to apply the Artefact. Making such models for Infrastructure Systems which require a high

degree of evolvability, is valuable. It allows to apply the Artefact and make theoretically and

practically sound predictions about the evolvability of an Infrastructure System. Infrastructure

Systems can thus be build or purchased with evolvability in mind and the limitations are known

up front.

9.2 Value for the Architect

Architects are often requested to create roadmaps. A roadmap is all about the evolution of a

system. The usage of the Artefact will help the Architect making scientifically correct

statements about the evolvability of an IT System. The Artefact should be the mandatory tool


43 | P a g e

for such types of analyses. The tool becomes for the Architect what a Risk Taxonomy is for a

Risk Manager, or Statistics and Data Mining Algorithms are for a Data Scientist.

The ex-ante proven evolvability issues can be used as input for:

Architectural Risk Analysis

Triggering mitigation actions

o Close follow up of system usage and evolution

o Provide tooling to temper the CE (see Appendix 3)

IT budget creation or IT investment planning

9.3 Value for the Generalized Normalised Systems

Theory GNST

The demonstration of the Artefact in Chapter 6 shows that the GNST can be applied on modular

structures representing IT Infrastructure. The theory has been made applicable and practical in

a new field. It shows the General nature of the theory and contributes to the further

proliferation of the theory in other parts of IT and science.


44 | P a g e

10 Conclusions and Reflections

Recalling the Research Question:

Can the Generalised Normalised Systems Theory (GNST) be used to study the behaviour of IT

Infrastructures under change?

This leads to the following research questions:

Part 1: Can the Generalised Normalised Systems Theory (GNST) principles be applied to

modular structures representing IT Infrastructure?

Part 2: Can Combinatorial Effects (CE) - hidden coupling or dependencies in a system which

increase with the size of the system - be predicted and recognized at the IT Infrastructure level

by using the Generalised Normalised Systems Theory (GNST)?

Part 3: What is the added value of using the Generalised Normalised Systems Theory (GNST)

at the IT Infrastructure level?

10.1 Conclusions

Using Design Science Research Methodology, an Artefact has been designed (Chapter 5),

demonstrated (Chapter 0) and evaluated (Chapter 7) which is used to test the Generalized

Normalised Systems Theory on a modular structure representing an Infrastructure System. The

Engie IT Reference Architecture Library has been used as source for Infrastructure Systems. The

construction of the Artefact has been validated and evaluated (Chapters 7 and 8) by an Expert

Team and the value of the Artefact has been discussed (Chapter 9)

The successful usage of the Artefact leads to the conclusion that:

1. The Generalised Normalised Systems Theory (GNST) principles can be applied to modular

structures representing IT Infrastructure.

2. CE can be predicted in IT Infrastructures using the GNST principles. Predicted CE can be recognized

in IT Infrastructure Systems.

3. Using the GNST at IT Infrastructure level provides valuable insight into the evolvability of IT

Infrastructure Systems. It can be used to analyse:

i. Existing IT Infrastructure Systems from which evolvability is expected.

ii. The design of IT Infrastructure Systems (to be build or to be purchased) and predict the

evolvability of the System.

iii. Create Roadmaps of IT Infrastructure System


45 | P a g e

10.2 Reflections

The subject of this research has led to a number of reflections which do not answer the

Research Question but who do merit to be mentioned or should be subject of further

investigated.

10.2.1 GNST knowledge as essential Architecture Skill

The GNST can be applied on any modular structure and most system can be represented by a

modular structure. The trick is to find the correct manifestations of Concern, State, Version and

Instance. Once these manifestations are known, the presented Artefact can be used to analyse

the behaviour of the modular structure under change.

Knowing and applying this is an essential skill for an Architect.

Within Engie IT, for some years now, Infrastructure Architects are being trained to model in

ArchiMate and to understand the usage of views and viewpoint. Knowing and applying the

GNST concept is the next skill which needs to be taught to all Architects and applying the

Artefact should become mandatory for every Architecture of an IT Systems which is bound to

evolve.

10.2.2 Artefact evolution

Infrastructure Systems are packed with CE they are all over the place. But are all CE equally

harmful? Appendix 3 talks about tooling which help to reduce the effect of CE or who will

automate the resolution of CE.

The Artefact should be further refined to make a distinction between benign CE and harmful

CE. A link with Architecture Risk and risk mitigation should be made as well.

The refinement the Artefact could be a subject for a new Master Thesis.

10.2.3 Roadmaps and Lehmans Law

An important trigger for the development of the Normalized Systems Theory is Lehmans Law

of increasing complexity and degeneration of software due to change.

Verelst and Mannaert16 argue based on this law that:

If the cost of a software change at T0, is X0

16

Normalized Systems Herwig Mannaert, Jan Verelst - 2009


46 | P a g e

Then the cost of the same change at T1 will be X1

Where T1 > T0 and X1>X0

Cost of change increases over time.

What if the same reasoning is applied at IT Infrastructure level with regards to changes on IT

Infrastructure components?

Would it be better, from a financial point of view, to upgrade as soon as possible when new

version of a Software Infrastructure Component is released, or to wait till the existing

components are out of support?

Would it be better to invest if a Zone concept in a Data Centre (according to les rgles de lart

as discussed in 6.1.4), or will the sum of all incremental costs be lower (or higher) than the

initial up-front investment?

Which elements need to be part of such a business cases and how could the degeneration

effect described by Lehman, be factored in.

Trying to answer those questions could be a subject for a new Master Thesis.

10.2.4 Configuration is the new Code

Infrastructure Systems are customized by means of setting parameters and configuration

settings. The total sum of all these configuration is as valuable as the source code of in house

developed applications. The way Infrastructure Systems are configured has impact on the

evolvability of the Infrastructure Systems, similar to the way code is written has impact on the

evolvability of an application.

The next major technological shift at the Infrastructure Layer will be the Software Defined

Network, Software Defined Data Centre and Software Defined Infrastructure.

Structuring policies and configuration will be essential for proper functioning and the

evolvability of the IT Systems.

Can the N

applying the gnst to the engie it ral-final

Documents