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 Lehman’s 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, Frédéric 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 ideeën 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 Cédric,
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 today’s 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 Perjons
1
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
Cédric 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 - Vinçotte
Frédéric 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

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 al
6
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, it’s
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 IT’s clients, one or more services of the
Architecture Solutions Continuum (ASC) are being instantiated and deployed in one of Engie IT’s
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 IT’s 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

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 (Housing–IBS) 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
today’s 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
(1)
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
(1)
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 CPU’s into
virtual CPU’s. 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 Lehman’s Law
An important trigger for the development of the Normalized Systems Theory is Lehman’s 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 règles de l’art
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 Normalized Systems Theory be used to structure policies and configurations to allow
maximum evolvability?
The study of this subject will require extensive knowledge about infrastructure configuration
and infrastructure policy setting in a wide range of technologies.
This should be a subject at PhD level.

47 | P a g e
Appendix 1: Applying the GNST on the
RAL/ASC Engie IT
In this section, 3 Infrastructure services will be investigated with the GNST
Housing-IBS
Housing Infrastructure Basic Services offer basic Data Centre services to
hardware devices installed in a Data Centre. Such as floor space, power, cooling,
cabling
Hosting-IBS
Hosting Infrastructure Basic Services deliver the externally visible functionality of
Hosting. Hosting is the combination of a hardware platform and an OS, offering
the possibility to exploit the hardware resources via an Operating System
Proxy-network-IBS
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.
These Services are a grouping of functionalities. For each of the 3 services, a model is made
where the service is decomposed into smaller modules (functions) which will interact with each
other. The GNST principles will be investigated on the modular structure representing the
Infrastructure System. Besides the GNST principles, Coupling and Cohesion of the modular
structures will be investigated as well.
A1.1 Module: Housing-IBS
The Housing pattern is used to install and operate physical IT Infrastructure components
(referred to as “Equipment”) such as server equipment, network equipment, storage
equipment, etc .... A well known realisation of a Housing Module is a Data Centre. But not all IT
Infrastructure equipment is located in state of the art Data Centres or in Data Centres all
together.
The Housing pattern itself has the following modules:
Location: Housing an IT Infrastructure component require a physical location. The Location
module represents a room, somewhere geographically located on earth, which will
deliver a number of square meters on which something can be located.
Power: The Location will be equipped with electricity to power the IT infrastructure
components located in the room. The distribution of the electricity requires physical
space and thus uses the Location module.

48 | P a g e
Cooling: IT Infrastructure equipment is temperature sensitive and requires conditioned
airflow for proper functioning. The equipment generates heat which needs to be
extracted from the location where the equipment is located to avoid overheating of
the equipment and impacting other equipment. This is done with the Cooling
module ( air conditioning).The Cooling module will take up physical space and uses
the Location module.
Rack: A Rack is a construction allowing the storage of IT Infrastructure equipment between
the floor of the room (z=0) and the height of the rack (z= about 2,5 meter). The
Racks will occupy physical location (typically about 1 square meter per Rack) and
uses the Location module.
Cabling: IT Infrastructure equipment is connected to other IT Infrastructure equipment via
networks of a different kind - LAN (Local Area Network) (Front end, Back end, Out of
band), SAN (Storage Area Network). This requires the availability of a connection
media - cabling. Cabling and the Cabling Infrastructure (cables, patch panels, active
equipment …)) requires physical space and uses the Location Module.
There are different possibilities on how these modules are linked to each other and how the
Equipment will be linked to those modules. They range from a Housing pattern dating back
from 20 years ago (but still used today) to a Housing pattern which represents how modern
Data Centres are constructed.

49 | P a g e
A1.1.1 Housing 1.0
Figure 19: Housing 1.0 modular Structure
Location: Offering square meters, x and y coordinates in a room. In Housing 1.0 the x, y are
offered via the Rack module to the Equipment. A Housing 0.0 would be a module
without racks and the equipment would be placed directly on the floor or on a
table, having a direct link between the equipment and the location.
Power: In Housing 1.0 electricity is offered directly to the equipment, meaning that for
each equipment added to the rack, a direct electricity cable exists between the
electric switch board and the equipment.
Cooling: In Housing 1.0 the air conditioning equipment is cooling the location as a whole
meaning it extracts the hot air from the location at a central place (sealing) and
pumps cold and conditioned air into the room from a central place (floor).
Rack: In Housing 1.0 IT Infrastructure equipment is considered to be stacked in a Rack and
not directly on the floor.
Cabling: In Housing 1.0 cabling is done point to point, meaning that if there are cabling
needs between 2 or more equipments, those are made directly between the
different equipments, via the shortest possible route.
Equipment:The IT Infrastructure Equipment which needs housing will be placed in a Rack,
requires Power, Cooling and Cabling.

50 | P a g e
A1.1.1.1 Cohesion
The 5 modules used in Housing 1.0 all exhibit a high level of cohesion. Relevant functions are
put together.
Location → delivery of square meters
Rack → delivery of vertical location on a certain square meter
Cooling → extraction of hot air produced by the equipment
Power → delivery of electricity (Power, Voltage, Ampere)
Cabling → delivery of IT connectivity
A1.1.1.2 Coupling
Rack, Power, Cooling, Cabling have strong coupling with Location. They cannot exist without
Location and evolutions in Rack, Power, Cooling and Cabling will impact Location and vice versa
(see further).
The Equipment module has strong coupling with modules Rack, Power, Cooling and Cabling of
Housing 1.0
Housing 1.0 exhibits strong coupling features between the different modules. Evolutions in one
of the modules will have an effect on the depending modules.
A1.1.1.3 Separation of Concern (SoC)
Location, Rack, Cooling and Equipment seem to be well separated because they each address a
different concern (x, y, z, air, equipment).
Power addresses multiple concerns:
 Availability of voltage and current in the right format (frequency, Ueff)
 A secured transport mechanism of fuses, switches and cabling, toward a
physical location.
 Power connectivity
Cabling addresses multiple concerns:
Depending on the type of required connectivity, different kinds of cables need to be used
 Cabling: the cable itself to transfer signals (copper or fibre based)
 Connectivity : interface with the IT equipment
Not all modules of Housing 1.0 respect the SoC of the GNST, CE can be expected under change
(see section A1.1.1.7)
A1.1.1.4 Separation of State (SoS)
In Housing 1.0, the concept of SoS as described in the GNST does full apply.
Some physical equipment can persist their state externally by means of some sort of indicator.
For instance, a LED, indicating if there is power connected to a power supply, a LED indicating if

51 | P a g e
there is Ethernet signal and what the available speed is, or meters that indicated a certain
relevant value of the equipment, like temperature and humidity.
Physical equipments will not exchange their state with each other by persisting the state
outside the equipment.
In the context of Physical Equipment, like housing, Separation of State is reduced to externally
persisting the state of the module, but not used for exchanging states between modules.
A1.1.1.5 Version Transparency (VT)
Cabling: Changing cables should not have an effect on the Housing of the equipment.
However, over the past 20 years, cabling has changed and has had a profound
impact on the equipment. Not only the cable itself has evolved (max length,
shielding etc ..) but cable interface/connectors have changed as well. This is
typically triggered by the introduction of new technologies in a Data Centre which
require the installation of new equipment. To be able to fully exploit the
capabilities of the equipment, one must interconnect the new equipment with the
existing equipment. This can introduce the usage of a new type of cable and
connector. In case of a different connector, all equipments in the Data Centre will
need to be updated to be able to connect and interact with the new equipment.
This may lead to the replacement of equipment, or upgrade of equipment (install
new interface cards), installation of drives, upgrades of the software (e.g. OS)
running on the equipment. The choice of the wrong cable in a Data Centre has an
enormous impact on the evolvability of the Housing capabilities of the Data Centre
Examples17
:
Figure 20: going from BNC to CAT3/5/6 cables
17
www.lascon.co.uk/SAN-Cables-and-Connectors.php

52 | P a g e
Figure 21: Different SCSI cables and connectors
Figure 22: from SCSI to FC and from SC to LC Fibre connectors
Rack: In Housing 1.0, the rack is considered only to offer vertical space to the equipment.
Is has no other structuring functionality. A new version of the Rack module in which
equipment is already installed will have an important impact on the housing of the
equipment (needs to be relocated) but will not affect the functionality of the
equipment - as could be the case for cabling changes. A new physical location of the
equipment will require adjustments of the cabling and power. Limitations in terms
of cable lengths (of both data and power) may trigger the installation of new cables.
If the new Rack has a different footprint - more or less square meters, different
width, depth, height - then this could get an impact on the location and every
aspect of the Housing, depending on whether the new rack is to be installed on free
square meters, or to be put on square meters which have racks on them.
Power: A different version of the Power module should not impact the Housing. One can
say that, within a country the way power is transported and connected is stable as
well as the power signature ( voltage level, frequency).
 Voltage levels and frequency
 Authorized cable types,
 Fuse standards,
 Outlets
 Connectors

53 | P a g e
If however those would indeed change, then the impact would be Data Centre wide
with serious CE as a result
 Voltage levels and frequency
o All power modules of the Equipment would need to be changed to cope
with new Voltage levels and frequencies
 Authorized cable types,
o Voltage and frequency have an impact on power cable insulation
o New cabling would be required to bring the power to the equipment
 Fuse standards,
o Fuses limit the amount of current that can be transferred on a circuit of
cables and thus the max amount of equipment which can be connected to
one circuit.
o Redistribution of the equipment over the power circuits will be required,
which will trigger changes to the cabling to the Equipment
 Outlets and Connectors
o Power cords of the Equipments would need to be changed to allow a
connection with the power grid
Cooling: New versions of cooling should not impact the Housing of the equipment. As long
as the cooling module is able to subtract the heat coming from the equipment in
such a way that the equipment operates in the thermal supported zone of the
equipment, there is no issue replacing one cooling equipment with another.
However the cooling equipment may take up extra square meters, impacting
Location. It may even trigger the move of Racks, Power, Cabling and Equipment.
Location: Changes in the Location have a direct impact on all other modules. Relocating
Cabling, Power, Cooling and Rack has a physical impact on the Equipment with
direct impact on the functioning of the Equipment during the relocation as a result.
The Equipment needs to be brought off line till the moment the new physical
location is ready to be used by Cabling, Power, Cooling and Rack. As long as all 4 are
not operational, the Equipment cannot be brought online.
A1.1.1.6 Instance Traceability (IT)
In a physical model such as Housing 1.0, the concept of Instance Traceability as described in the
GNST does not apply. Physical equipments will not exchange information with each other.
A1.1.1.7 Adding an equipment
Adding an equipment to a Data Centre organized according to Housing 1.0 will have the
following effect:
 Add to existing rack
 Bring power cabling towards the new equipment
 Bring IT connectivity towards the new equipment

54 | P a g e
For small or empty Data Centres this should be no problem. But when they become full and
large, then the impact of adding an equipment will be bigger → instability related to change
and the size of the system.
A rack containing 20 pieces of equipment with each 2 power connection and 2 IT connections
and where all cables are just coming out of a 20 x 10 cm hole in the ground at the bottom of a
rack, will provide an interesting challenge to add another equipment with 4 additional cables.
The lack of structure will degrade the infrastructure as a whole and lead to situation like “don’t
touch any cable, we don’t know what they are used for and are afraid we lose connectivity”.
The writer of this thesis can testify he has re-cabled (re-factored) racks in Data Rooms to lower
the Entropy of the cabling the Data Centre, on multiple occasions.
Figure 23: Result unstructured cabling
When there is no more space in a rack, an extra rack needs to be added. When the Data Centre
is organized in “streets” (racks aligned to each other in a structured way)this poses no problem,
as long as there are square feet available.
The adding of an equipment can have an effect on the Power as the Power module may have
reached its limits in terms of ability to deliver the required voltage and current.
The adding of an equipment can have an effect on the Cooling Module as this one may have
reached its limits in terms as the ability to extract heat from the new equipment. This can be
due to the max cooling capacity of the Cooling Module or the inability to deliver the correct
cooling to the location of the equipment. This is typical for a cooling installation at one end of
the room, blowing cold air in the room. Next to the air blower it’s 16° but at the other side to
the Data Centre it’s 28° due to bad cold air distribution and hot air abstraction.
A1.1.1.8 Conclusion
Housing 1.0 is a pattern which will not be found anymore in modern Data Centres but still exists
is small data rooms around the globe. It has serious limitation in terms of growth (CE expected).
To temper these effects, a good view must exists on:

55 | P a g e
 types of required IT connectivity to foresee: cabling
 max cooling and cold/hot air distribution/removal
 Max power capabilities
 Max amount of racks and distribution
A1.1.2 Module: Housing 2.0
Figure 24: Housing 2.0 modular Structure
In Housing 2.0, the Rack plays a more prominent role. It no longer serves only as the provider of
vertical space, but the rack will be organized in such a way that it will provide the necessary
power and connectivity/cabling to the IT Equipment. This is realized with the installation of
patch panels inside the rack and have power distribution units inside the rack.
The Rack will help the cooling as it will be equipped with fans which will actively suck in cold air
into the rack (from the bottom) and vent hot air at the top.
A1.1.2.1 Cohesion
As in Housing 1.0 each module has a high degree of cohesion.
The Rack module offers the necessary proxies toward Cooling, Power and Cabling, but it is not
the primary source of those.
A1.1.2.2 Coupling
Rack, Cooling, Power and Cabling as still strongly coupled with Location. Equipment is now
more stronger coupled with Rack and Rack will be the entry point (delivery of proxies) towards
Power, Cabling and Cooling

56 | P a g e
A1.1.2.3 Separation of Concern (SoC)
Rack is now addressing besides the delivery of vertical space, also the availability of Power,
Cabling and Cooling. It does this by providing proxies for Power, Cabling and Cooling but not by
providing the actual power, cabling and cooling - which is done in the Power, Cabling and
Cooling modules.
The Rack is now addressing the cross cutting concern that every housing of an equipment needs
to see address: space, cabling, power, cooling. By the inclusion of these cross cutting concerns
by means of proxies, the Rack becomes more in line with what is defined as an Element in the
NST.
.
Figure 25: Patch panels and power distribution units
A1.1.2.4 Separation of State (SoS)
As explained in section A1.1.1.4, in the context of Physical Equipment, Separation of is reduced
to externally persisting the state of the module, but not used for exchanging states between
modules.
A1.1.2.5 Version Transparency (VT)
The version transparency issues as described in Housing 1.0 are still valid in Housing 2.0.
However due to Rack element, the impact of changes can be lowered, tempering the CE.
Rack: Changing Rack means moving the equipment, just like in Housing 1.0. However,
the new Rack will be equipped with the same proxies as the old Rack. The moved
Equipment will be quickly connected to the necessary Power, Cabling and
Cooling and be brought online more quickly than in Housing 1.0 where it is not
advisable to bring a system online while the provisioning of cabling and power is
still ongoing for all other equipments.

Applying the GNST to the Engie IT RAL-final

Applying the GNST to the Engie IT RAL-final

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (19)

Similar to Applying the GNST to the Engie IT RAL-final

Similar to Applying the GNST to the Engie IT RAL-final (20)

Applying the GNST to the Engie IT RAL-final