HOPEX IT Architecture Training Handout

UNDERSTANDING THE IT SYSTEM

Foreword

• Purpose of this guide

This document is to be used to support HOPEX IT
Architecture training course.

• Document Reference
MARC Version: 1.0

Page 2
Before we start

Time keeping

Alarms

Facilities

Phones

Page 3
Training Objectives

You will understand how You will be able to build a

1 to take stock of existing 2 repository full of IT
IT in your company architecture components

Learn the correct use of

3 MEGA Architecture 4
You will understand the
functions for modeling project flow to guide IT
based projects. architecture projects

You will be able to model Appreciate the

5 your own IT architecture in 6 added value of a
your company repository backed
tool.

Page 4
Training Agenda

1 Pre course recap

2 Main Architecture Concepts

3 Inventory of Application Assets

4 Inventory of Application Components

5 Describing Application Environment

6 Describing Application Architecture

7 Describing Technical Infrastructure

8 IT City Planning

9 Mastering the HOPEX Repository

Page 5
What Do We Cover?
Models not diagrams…

• Rather than thinking of diagrams as ‘the bit that adds value’ for
organisations and end users, at MEGA we see diagrams as only part
of that value.

• With MEGA, diagrams are used to describe a specific object, and this
object sits within a wider database.

• Because MEGA is a database, we can re-use objects, we can make

associations between them and we can ask questions of the
information contained within the database.

• MEGA can produce a number of different types of outputs. Diagrams

are just one example and the approach allows us to capture various
level of detail.

Let’s look at these levels of detail…

Page 6
What Do We Cover?
Capturing the right level of detail and Modeling ‘top
down’ is key. We represent this with a 3 sided pyramid:
Process models are captured
from enterprise level through
to work instruction level
(covered in MEGA BPMN)
Functional process
models are captured
detailing what the
organisation does to
provide products and
services to customers
unconstrained by
implementation
(covered in MEGA
BPMN) Architecture models are
developed to understand
how the IT system breaks
down (covered in this
course)
Page 7
Architecture Modeling
Key principles of Modeling:

• A Model is a simplified representation of the real

‘system’
• The model often comprises a number of different views
• It describes the way the system works
• It enables analysis of its behavior
• It allows us to communicate ideas in a common form
Simplic
ity is
key:
Page 8
“If you can’t explain it
simply, you don’t
understand it well
enough”

Page 9
Architecture Modelling
What does this mean?

• The Model provides a simplified representation of a

complex world
• Modeling is about being pro-active as opposed to
reactive
• It gives us understanding and therefore control
• Modeling allows us to carry out impact assessment
• Informed decisions can therefore be made based on
findings from the model Page 10
Architecture Modeling
The Burj Khalifa…
Your definitions
will determine
what and how you
model:

One business, multiple views:

Each view / representation has a
specific purpose. A
representation is a reduction of
reality designed to the interests of
the reader:

Page 11
Architecture Modeling

Modeling cycle
following definition Collect
Information
work:

Collaborate Analyse,
Create
Integrate Share &
Models
Review
Communicate Modelin
g Cycle

Generate Harmonise
Documentati and
on Associate

Page 12
 Architecture Modeling
A little about MEGA (the tool)

Page 13
13
Architecture Modeling
MEGA is a collaborative Modeling tool with a central repository:

Capture Business Integrate & Analyse in Publish Websites,

Models a Central Repository Documents & Reports

Page 14
15
Architecture Modeling
Objects

An Object represents an aspect of the reality being

described in the model:

Org Unit Process Application Risk

Each Object is defined with a set of properties, allowed Page 15

associations and describing Diagrams.
Architecture Modeling

Object Associations

• Associations are the link between different objects

For example: linking an application to an Org-Unit
• Associations can be created either in the text editor
(properties) or in the graphical editor (on the diagram)

Object Description (Diagrams)

• An Object may be described by a Diagram.

• Specific Diagram types exist to describe an Object
• Objects may appear on multiple Diagrams Page 16
Architecture Modeling

Object properties
• The properties of an Object allow the capture of significant information that will
sit in the Repository
• Properties options are pre-defined for each Object type
• The text editor enables you to define the properties of Objects

Properties

Page 17
Training Agenda

1 Pre course recap

2 Main Architecture Concepts

3 Inventory of Application Assets

4 Inventory of Application Components

5 Describing Application Environment

6 Describing Application Architecture

7 Describing Technical Infrastructure

8 IT City Planning

9 Mastering the HOPEX Repository

Page 18
Main architecture objects
Understanding terminology…

Application Architecture:
• An application architecture is a logical
composition of applications and their
interactions
• It provides a simplified representation of all or
part of the IT system.
• An objective of application architecture is to
provide IT solutions that deliver functionalities
that are necessary to the running of a business

Page 19
For example…

The Expedia which delivers ‘search

Travel booking for flight’ and ‘place a
Application… booking’ Functionalities

provides a
location proposal
Service…
Main architecture objects
Understanding terminology…

Concept Description Examples

• HOPEX
Modeling Suite
A collection of applications that provides
• MS Office
Application System a consistent set of functionalities.
• Adobe Creative
Cloud

• HOPEX IT
A set of software components and their
Architecture
interactions that enables the user to
Application • MS Word
perform specific tasks.
• Adobe Illustrator

Page 21
Main architecture objects

• Understanding terminology…

Application
System

Application

Page 22
Main architecture objects

Concept Description Examples

• Process
A service is a consistent processing unit
modelling
that coordinates a set of interactions,
• Word
with the purpose of implementing one or
Service Processing
more functionalities.
Service

• Diagram
A service can be further divided into sub-
creation
services.
Sub-Service • Spell Checking

• Model business
A feature that the business needs in process
order to meet and achieve their work. • Create
Functionality
customer letter
Page 23
Main architecture objects

• Understanding terminology…

⤔ A functionality may be provided by:

Dictionary
physical resources: a letter scale, a forklift,
a machine tool.
v
Bilingual assistant
human resources: a mover, a bilingual
assistant.

Electronic IT resources (IT Services or Applications)

translator
Page 24
Breakout activity 1
GYMGO software solutions:

• You will be given a table of items relating to the

solution
• You will see:
Application Systems
Applications
Services &
Functionalities
• Work as a team to categorise them accordingly
• Choose a presenter
• Present your decisions & thought process
• You have 10 minutes to complete this task before
presentation
Page 25
Breakout activity 1
Work as a team to categorise the following items accordingly.
 Why? What? How?

Objective Application Service

Requirement Application System Functionality
Risk Technical Message flow
Indicator Infrastructure Content
MAIN CONCEPTS:
Channel

Who? Where? When?

Org-Unit Site Timer

Database Time periods
Role
IT City planning area Time Line
Person

With What? Etc.

Server Project
Network Note
Network node External Reference
Training Agenda

1 Pre course recap

2 Main Architecture Concepts

3 Inventory of Application Assets

4 Inventory of Application Components

5 Describing Application Environment

6 Describing Application Architecture

7 Describing Technical Infrastructure

8 IT City Planning

9 Mastering the HOPEX Repository

Page 28
Project flow
Key stages for architecture work…

1 2 3
Rediscover Analyse the Align the IT
Knowledge Deployment System with
of the IT of Corporate
System Applications Strategy

• Construct the IT City Plan

• Inventory of • Inventory of Sites • Define the Target
Applications • Describe Technical
• Inventory of Application Infrastructure
Components
• Describe Application
Environment
• Describe Application
Architecture Page 29
Project flow

• Key deliverables for stage 1 1

Rediscover
Steps: Deliverables: Knowledge
of the IT
System
Inventory of Applications List of Applications

Inventory of Application
Application Tree Diagram
Components

Overview of Applications / Application

Describe Application Environment
Environment Diagram

Describe Application Architecture Internal application Architecture Diagrams

Page 30
Project flow

• Remember…
Collect
Collaborate Information
Integrate
Communicate

Analyse, Share Create

& Review Models
Modelling
Cycle

Generate Harmonise
Documents and Associate

Page 31
Where to Start?
Inventory of Application Assets

Page 32
Where to start?
Inventory of application assets

• Creating a common view - an ‘as-is’ picture:

• It’s important to have a common view of application
assets
• This is an agreed and shared view across entire
company
• This is obtained by creating a catalog of applications
in the repository
• We use an Application Sheet Template
• The information should be reviewed to eliminate any
redundancies / duplications
• The information can then be entered into the HOPEX
repository

Page 33
Breakout activity 2
Gathering information

• Think about where you would start at the beginning of the

project. It is likely that you will always need to gather
information in order to make an inventory list of current
applications within the IT system.
• Think about:
• How would you approach this?
• Who would you approach in your organization?
• How would you prepare for any meetings?
• What information would you gather/ what questions might you
ask?
• Discuss this in your groups and choose a new presenter
• Present back your findings
• You have 15 minutes to complete this before presenting back

Page 34
Exercise 1

INVENTORYING APPLICATION ASSETS

Everyone still on board?
Key learning points:

Use of the sheet template allows us to gather

application information
We can use this to inventory and build a
catalogue of applications
This enables the definition of scope of the
architecture project
Analysis helps to answer:

• Which applications are in my IT system?

• Do I have to describe all of them?
• Are they all equally important?
• Should some applications be retired?

Page 36
Training Agenda

1 Pre course recap

2 Main Architecture Concepts

3 Inventory of Application Assets

4 Inventory of Application Components

5 Describing Application Environment

6 Describing Application Architecture

7 Describing Technical Infrastructure

8 IT City Planning

9 Mastering the HOPEX Repository

Page 37
Inventory of App Components
Application Tree Diagram

Page 38
Remember?
It’s all about Applications

APPLICATIONS

The way they The way their Their Their Their

break down components delivery of key deployment distribution in
according to interact within business and Technical IT City
Hierarchy their Functionalities Infrastructure planning
Architecture Areas
Page 39
Project flow

• Key deliverables for stage 1 1

Rediscover
Steps: Deliverables: Knowledge
of the IT
System
Inventory of Applications List of Applications

Inventory of Application
Application Tree Diagram
Components

Overview of Applications / Application

Describe Application Environment
Environment Diagram

Describe Application Architecture Internal application Architecture Diagrams

Page 40
Inventory of application components

• Application tree diagram

Why? What? How?

Objective Application Service

Requirement Application Functionality
System Message flow
Risk

MAIN CONCEPTS:
Technical Content
Indicator Infrastructure Channel

Concepts Who? Where? When?

introduced Org-Unit Site Timer
within this Role Database
IT City planning Time periods
section: Person area
Time Line
With What? Etc.
Server Project
Network Note
External
Network node Reference
Page 41
Inventory of application components
Application tree diagram

• The Application Tree

Diagram is used to
identify the breakdown
of an application into its
components
• Sub-applications at the
higher level
• Services implementing
functionalities at the
lower level
Page 42
Breakout activity 3
Application tree

Within your groups:

• Brainstorm one or two iPhone Applications (or
Android if you’re that way inclined)
• For each Application, brainstorm the Functionalities
it will provide.
• Imagine how the Functionalities will be materialized
in IT Services.
• Using the flip chart provided, create an Application
Tree
• Discuss this in your groups, rearrange / modify as
required
• Choose a new presenter
• Present back your Application Tree discussing your
thought processes
• You have 20 minutes to complete this before
presenting back Page 43
Inventory of application components
Application tree diagram

• Functional example:

Page 44
Exercise 2

BREAKING DOWN AN IT SYSTEM INTO ITS COMPONENT PARTS

Everyone still engaged?
Key learning points:

Breaking down an application into its

components provides a clear view of its
structure
A diagram is only a partial view of the
repository
Some objects can be named according to
their context (i.e. Applications, Services).
Removing an object from a diagram does
not necessarily delete it from the repository.

Page 46
Training Agenda

1 Pre course recap

2 Main Architecture Concepts

3 Inventory of Application Assets

4 Inventory of Application Components

5 Describing Application Environment

6 Describing Application Architecture

7 Describing Technical Infrastructure

8 IT City Planning

9 Mastering the HOPEX Repository

Page 47
Describing Application Environment
Overview of Applications / Application Environment Diagrams

Page 48
Project flow

• Key deliverables for stage 1

1
Rediscover
Steps: Deliverables: Knowledge
of the IT
System
Inventory of Applications List of Applications

Inventory of Application
Application Tree Diagram
Components

Overview of Applications / Application

Describe Application Environment
Environment Diagram

Describe Application Architecture Internal application Architecture Diagrams

Page 49
Describing application environment
Understanding terminology…

• We are now going to focus on Application Environment:

This represents the external view - the applications are black

boxes. We are interested only in the exchanges between
the applications and not in the internal structures of these
applications.

• Next we will focus on Application Architecture:

This represents the Internal view - this means “opening the

black box” to reveal how the application functions within.
We see that the applications are made of components and
call upon components of other applications.
Page 50
Describing application environment
Understanding terminology…

Customer Relationship
Management (CRM)
Application user

We’re
interested in
Customer the external
Data view - the
Invoicing Warehouse interactions
Application Application

Page 51
Describing application environment
Understanding terminology…

Why? What? How?

Objective Application Service

Requirement Application Functionality
System Message flow
Risk

MAIN CONCEPTS:
Technical Content
Concepts Indicator Infrastructure Channel
utilised/ Who? Where? When?
introduced
Org-Unit Site Timer
within this Database
Role Time periods
section: Person
IT City planning
area
Time Line
With What? Etc.
Server Project
Network Note
External
Network node Reference

Page 52
Describing application environment

Concept Description Examples

Issuing and
A message flow represents a channel for
Message reception of an
information exchanged between applications.
Flow order or an invoice.

Information item,
A content represents the information element
goods or service. A
Content carried by the message flow.
report for example.

Page 53
Describing application environment
Understanding terminology…

Message flows and Content - more information…

• A message flow is defined by its content, a sender, and
a receiver
• The Content represents the information exchanged.
• Content may be reused in different messages.

Page 54
Describing application environment

Concept Description Examples

• Financial
An org-unit represents a person or a group of Management,
persons that intervenes in the enterprise business Sales
processes or information system. An org-unit can Management
Org-unit be internal or external to the enterprise. • Customer,
Supplier

A timer allows you to indicate the time and/or date

• Automatic batch
when an operation must be triggered, or when a
processing
Timer message is sent.

Page 55
Describing application environment
Overview of Applications / Application Environment diagrams

• Overview of Applications diagram:

A global Application Architecture Diagram presenting main
exchanges between applications at enterprise level.

Page 56
Describing application environment
Overview example:

• Overview of Applications / Application Environment

diagrams

Page 57
Describing application environment
Overview of Applications / Application Environment diagrams

• Application Environment diagram:

Used to place / display the application in its environment without
considering its internal architecture.

Applications
and Org-units
The that We don’t
Application being Information exchange show
described flows information exchanges
exchanged with the between
described these…
application

Page 58
Describing application environment
Overview of Applications / Application Environment diagrams

• Application Environment diagram example:

Page 59
Describing application environment
Overview of Applications / Application Environment diagrams

• Keys steps:

1 2 3 4

Identify Identify Identify Add Time

Applications Interactions Exchanges Elements
Identify applications Identify other Identify exchanges / Complete the
exchanging data with interactions with the information flows and diagram with any
the studied external environment their content. Only timing elements
application. - users, customers, those that flow where necessary.
partners etc. from/to the
application being
studied
Page 60
Describing application environment
Overview of Applications / Application Environment diagrams

• In an Application
Environment diagram, we do
not show: Sub-
Applications
Sub-applications – we are
concerned with the interfaces
with the application and not its
structure Items
NOT
Services owned or used by the shown
described application - these
will appear in its internal Databases Services
architecture
Databases - an application
does not generally access a
database directly
Page 61
Breakout activity 4
Application environment

• In this section we will consolidate information

from different sources to obtain a complete
view of the “Production Activity Control System”
environment. Before creating the Environment
diagram in HOPEX, within your groups:
• Review the information in Sections 1.5 and 3.2
• Complete the table in Exercise 3.
• Choose a new presenter to discuss your result
• You have 15 minutes to complete this before
presenting back
Page 62
Exercise 3

DESCRIBING THE ENVIRONMENT OF AN APPLICATION

Everyone feeling good?
Key learning points:

Describing the environment of an

application provides a view of interactions
with:
• Other Applications in the IT system
• Org-units that use the Application
Remember the difference - message
flow/content
Importance of the maintaining coherent list
of applications:
• Changes may impact several
Environment Diagrams.

Page 64
Training Agenda

1 Pre course recap

2 Main Architecture Concepts

3 Inventory of Application Assets

4 Inventory of Application Components

5 Describing Application Environment

6 Describing Application Architecture

7 Describing Technical Infrastructure

8 IT City Planning

9 Mastering the HOPEX Repository

Page 65
Describing Application Architecture
Internal Application Architecture Diagram

Page 66
Project flow

• Key deliverables for stage 1

1
Rediscover
Steps: Deliverables: Knowledge
of the IT
System
Inventory of Applications List of Applications

Inventory of Application
Application Tree Diagram
Components

Overview of Applications / Application

Describe Application Environment
Environment Diagram

Describe Application Architecture Internal application Architecture Diagrams

Page 67
Describing application architecture
Understanding terminology…

• We have looked at the External View:

CRM

user

Customer
Data
Invoicing Warehouse
Page 68
Describing application architecture
Understanding terminology…

• We now need to look at the Internal View:

CRM
user

Customer Data
Invoicing Warehouse
Page 69
Describing application architecture
Understanding terminology…

Why? What? How?

Objective Application Service

Requirement Application Functionality
System Message flow
Risk

MAIN CONCEPTS:
Technical Content
Indicator Infrastructure Channel
Concepts
Who? Where? When?
utilised/
Org-Unit Site Timer
introduced Database
Role
within this IT City planning Time periods
Person area
section: Time Line
With What? Etc.
Server Project
Network Note
External
Network node Reference

Page 70
Describing application architecture

Concept Description Examples

A role is an element of the internal architecture of

an application (or a service). It represents an
external participant with which the application (or Senders of orders,
service) needs to communicate with in order to be receivers of
Role able to function. Identifies the sender or receiver of invoices, etc.
the message content, internal view of the
application.

A database is an organised collection of data. Its

structure can be logically described via a data model
or physically depicted via a relational model. CRM database
Database
A database stores data physically or logically.
Page 71
Describing application architecture
Internal application architecture diagram

• Internal Application Architecture diagram:

Describes the interactions between the components of an application
system or an application in a well defined context. It defines the
architecture and internal exchanges necessary for correct operation.

Page 72
Describing application architecture
Internal application architecture diagram

• Keys steps:

1 2 3 4

Add Connect External Add Internal Reorganize and

Components Messages Messages Rename Roles
Add the necessary Connect messages Identify and add (Optional) Grouping
applications in its from the exterior to "internal" messages received or sent
internal architecture, the sender or receiver necessary for messages into the
services and application or application operation same role and
databases services and external services renaming the role to
required. explain reason of the
grouping.
Page 73
Describing application architecture
Internal application architecture diagram

• This diagram uses information from the

application environment diagram:

Page 74
Describing application architecture
Internal application architecture diagram

• We can then add the detail:

Page 75
Describing application architecture
Internal application architecture diagram

• We then go down a further level:

Page 76
Describing application architecture
Internal application architecture diagram

• We can then add the detail:

Page 77
Describing application architecture
Internal application architecture diagram

• Elements appearing in the Environment Diagram

identify:
Requests from other applications, org-units, etc.
Results expected by other applications, org-units, etc.

• Elements appearing in the Internal Architecture

Diagram are those necessary for correct operation of
the application:
Internal components (modules, services, databases)
enabling fulfillment of application "contracts"
Calls for services of other applications

Page 78
Describing application architecture
Internal application architecture diagram

• A "User" service can be supplemented by an external reference

containing description of the user interface.

Page 79
Describing application architecture
Internal application architecture diagram

• A service can itself be described by a Service

Architecture Diagram and broken down into
several sub-services:

Page 80
Describing application architecture
Internal application architecture diagram

• Service Architecture diagram:

An application service architecture is a logical composition
of IT software components and their interactions that
implements functionalities delivered by the application.

Page 81
Exercise 4

DESCRIBING THE INTERNAL ARCHITECTURE OF AN APPLICATION

Everyone still awake?
Key learning points:

The internal architecture diagram gives a

view of the internal working of an application

It is a link between the description of the

environment of the application, and the
description of its component

It is possible to drill down from one level of

description to another (i.e. application
architecture to service architecture)

Page 83
Training Agenda

1 Pre course recap

2 Main Architecture Concepts

3 Inventory of Application Assets

4 Inventory of Application Components

5 Describing Application Environment

6 Describing Application Architecture

7 Describing Technical Infrastructure

8 IT City Planning

9 Mastering the HOPEX Repository

Page 84
Describing Technical Infrastructure
Analysing the Deployment of Applications

Page 85
Project flow

• Key stages for architecture work…

1 2 3
Rediscover Analyse the Align the IT
Knowledge Deployment System with
of the IT of Corporate
System Applications Strategy

• Inventory of Applications • Inventory of Sites • Construct the IT City Plan

• Inventory of Application • Describe Technical • Define the Target
Components Infrastructure
• Describe Application
Environment
• Describe Application
Architecture
Page 86
Project flow

• Key deliverables for stage 2

2
Analyse the
Steps: Deliverables: Deployment
of
Applications
Inventory of Sites Site Tree Diagram

Describe Technical Infrastructure Technical Infrastructure Diagram

Page 87
Describing technical infrastructure

• Understanding terminology…
Why? What? How?

Objective Application Service

Requirement Application Functionality
System Message flow
Risk

MAIN CONCEPTS:
Technical Content
Indicator Infrastructure Channel
Concepts
utilised/ Who? Where? When?
introduced Site
Org-Unit Timer
within this Role Database
section: IT City planning Time periods
Person area
Time Line
With What? Etc.
Server Project
Network Note
External
Network node Reference
Page 88
Describing technical infrastructure

• Understanding terminology…
Concept Description

A technical infrastructure describes a collection of hardware and other

equipment used for running IT applications and allowing them to
communicate.
Technical
The TI may be defined across several sub-sites and used by several
infrastructure
applications.

Page 89
Describing technical infrastructure

• Understanding terminology…
Concept Description

A site is a geographical or physical location.

Sites may be generic such as Head Office, Branch Office, Plant or they
can be precise geographical locations such as the Boston Subsidiary,
Site the Melbourne Plant.

Sites can also be

broken down:

Page 90
Describing technical infrastructure
Inventory of sites

• Keys steps:

1 2 3

Create a List of Define How They Create the Model

All Sites Break Down of Sites
Think about all sites of Define an appropriate Using the Site Tree
interest where IT level of decomposition, diagram, create the
components such as for example: model to document
servers, networks, Enterprise, Building, all sites showing how
gateways and Office… they decompose
workstations are to be
placed
Page 91
Project flow

• Key deliverables for stage 2

2
Analyse the
Steps: Deliverables: Deployment
of
Applications
Inventory of Sites Site Tree Diagram

Describe Technical Infrastructure Technical infrastructure Diagram

Page 92
Describing technical infrastructure

• Understanding terminology…
Why? What? How?

Objective Application Service

Requirement Application Functionality
System Message flow
Risk

MAIN CONCEPTS:
Technical Content
Indicator Infrastructure Channel
Concepts
utilised/ Who? Where? When?
introduced Org-Unit Site Timer
within this Role Database
Time periods
IT City planning
section: Person area
Time Line
With What? Etc.
Server Project
Network Note
External
Network node Reference
Page 93
Describing technical infrastructure
Communications Viewpoint:

• Understanding terminology…
Concept Description

A network is a communication system that allows interconnections

between computers or between computers and their peripheral
Network devices.

A Network Node is a hardware device providing network connection

such as a modem, a router, a bridge, etc. It is part of the architecture
Network
of a network or is used to interconnect multiple networks.
Node

Page 94
Describing technical infrastructure
Execution Platform Viewpoint:

• Understanding terminology…
Concept Description

A server is a computer that shares its processing and storage capacities

between multiple users (applications or org-units).
Server

A workstation is a computer that allows an end user (org-unit) to run

applications.
Workstation

Page 95
Describing technical infrastructure
Technical infrastructure diagram

• Technical infrastructure
diagram:
This diagram describes the
material resources required by
the application such as servers,
workstations and their
peripherals, along with elements
that enable communication
between application such as
network and exchange
protocols. It also includes the
additional supporting software
associated to the required
hardware. Page 96
Describing technical infrastructure
Technical infrastructure diagram

• Keys steps:

1 2 3 4

Identify TI’s Inventory of Inventory of Connect Software

Required Components Software to the TI
From inventory of Place all servers, Define inventory of Connect software
sites work, confirm all Workstations, software components components to the
sites have been Networks and hosted by the TI such technical
identified. Think Network Nodes onto as Applications, infrastructure.
about ‘business’ sites relevant sites. Databases etc.
and ‘technical’
premises, etc.
Page 97
Describing technical infrastructure
Technical infrastructure diagram

Leveraging Technical mapping:

• Indicators in the repository or supervision tools
linked to the repository

Examples of supervision tools:

• Supervision of the servers and the networks
• Calculation of the criticality of a server

Page 98
Exercise 5

DESCRIBING TECHNICAL INFRASTRUCTURES

Almost There…
Key learning points:

These steps allow us to recover the

knowledge of our technical infrastructure
This method can be used for understanding,
and leveraging the technical infrastructure
We can use this for analysing current
deployment, to improve current deployment
or to analyse the best deployment of a new
application

Page 100
Training Agenda

1 Pre course recap

2 Main Architecture Concepts

3 Inventory of Application Assets

4 Inventory of Application Components

5 Describing Application Environment

6 Describing Application Architecture

7 Describing Technical Infrastructure

8 IT City Planning

9 Mastering the HOPEX Repository

Page 101
Project flow

• Key stages for architecture work…

1 2 3
Rediscover Analyse the Align the IT
Knowledge Deployment System with
of the IT of Corporate
System Applications Strategy

• Inventory of • Inventory of Sites • Construct the IT City Plan

Applications • Describe Technical • Define the Target
• Inventory of Application Infrastructure
Components
• Describe Application
Environment
• Describe Application
Architecture Page 102
Project flow

• Key deliverables for stage 3 3

Align the IT
Steps: Deliverables: System with
Corporate
Strategy
Construct the IT City Plan IT City Zoning Diagram

2 main reports:
Define the target
• Functional Analysis of Applications Analysis
• IS Compliance with City Plan

Page 103
IT city planning
Understanding terminology…

What is It City Planning?

• Based on the principles of actual city planning
• It is a framework for structuring and organising
applications into categorised blocks in order to
rationalise and/or pool it resources
• It allows us to analyse the current system; its strengths
and weaknesses related to how well it delivers (or
does not deliver) expected functionalities
• Provides information that can be used to improve
Information Systems and to consolidate Applications,
which can then generate savings

Page 104
IT city planning
Understanding terminology…

Why City Planning?

• Large enterprises inherit systems that are complex,
difficult to upgrade, not optimised and often
redundant
• IT City Planning will therefore appeal to companies
with monolithic systems who are looking to restore
some agility to their IT system
• Essentially, it is geared towards three main goals,
each leading to savings:
Increasing flexibility. Replace Applications without
disrupting the business
Eliminating redundant applications.
Reducing the diversity of the technology.
Page 105
IT city planning

• Understanding terminology…
Why? What? How?

Objective Application Service

Requirement Application Functionality
System Message flow
Risk

MAIN CONCEPTS:
Technical Content
Indicator Infrastructure Channel
Concepts
utilised/ Who? Where? When?
introduced Site
Org-Unit Timer
within this Role Database
section: IT City planning Time periods
Person area
Time Line
With What? Etc.
Server Project
Network Note
External
Network node Reference
Page 106
IT city planning

Concept Description

An IT City Plan is a breakdown of the IT System into areas according to

a particular grouping criterion. Major grouping criteria include the main
business functions of the company, the technological environment or
IT City Plan
any other relevant criterion within the business context.

In an IT City Plan, an IT City Planning Area is the unit within which

applications are grouped according to the chosen criterion.
IT City
Planning An IT City Planning Area is broken down into sub-areas, right down to
Area the appropriate level of individual grouping blocks.

Page 107
IT city planning
Constructing the IT city plan…

• Typical IT City Planning Areas (adapt these as

necessary)
Activities exchanging information
with exterior (channel management,
formatting of exchanged data)

Shared dynamic
reference data

Analysis, Business process activity

statistics, areas as such
management, Shared business function data
"reporting" … (warehouses)

Management of "support"
resources for basic business
functions
Page 109
IT city planning
Constructing the IT city plan…

• Functionalities are key:

• Required Functionalities
are defined by the business
and are linked to IT City
Planning areas:
• Applications have already
been modelled. They
breakdown into IT Services
offering delivered
Functionalities…
Page 110
IT city planning
Constructing the IT city plan…

• IT City Zoning diagram

• It is used to describe the
hierarchy of city planning
areas and the distribution
of applications and
services in these areas.
• Application projection is
done by analyzing the
correspondence between
application
functionalities/data and IT
City Area
functionalities/data.. Page 111
IT city planning

• Constructing the IT city plan…

This is an example of
a “standard” IT City
Plan based on
Functional Areas.

Although there is no
single way to use IT
City Planning, this
example is often
adapted by clients.

Page 112
IT city planning
Keys steps:

• Constructing the IT city

plan…

1 2 3 4

Adapt Standard Break it Down Link Criterion to Analyse the IT

City Plan Further the plan City Plan
Create a basic city Breakdown the areas Link required Generate the
plan using the into lower levels. functionalities and ‘Functional Analysis
standard approach, any technical of Applications’
breaking down by infrastructures etc. to analysis report.
business functions the areas, districts
and blocks Page 113
Project flow

• Key deliverables for stage 3

3
Align the IT
Steps: Deliverables: System with
Corporate
Strategy
Construct the IT City Plan IT City Zoning Diagram

2 main reports:
Define the target
• Functional Analysis of Applications Analysis
• IS Compliance with City Plan

Page 114
IT city planning
Define the target…

Functional analysis of
applications report:
• This analysis is designed to
compare a set of
applications supplying
functionalities with a set of
expected functionalities
(functional scope) defined
by the business.
• It helps you to identify
expected functionalities
which are not covered by
applications. Page 115
IT city planning

IS Compliance with City Plan

• The IS is compliant against the IT city plan if all applications
can be located in the functional areas where they are
compliant with the area definition (set of functionalities,
exchange rules with other areas...).
• This report enables you to detect areas for improvement.

Page 116
IT city planning

• Define the target…

This is an
example of a
“IS Compliance
with City Plan”
report

Page 117
Exercise 6

CONSTRUCTING AND ANALYZING THE IT CITY PLAN

Well done!
Key learning points:

It City Planning gives us the ability to improve

by helping us understand the answers to
important questions like:
Are there huge applications that cover
several zones?
Do zones exist where required functionalities
are not provided?
Do we have several applications providing
the same Functionalities?

Page 119
IT Architecture
What have we discovered?

• We now have the ability to:

Take stock of the existing IT in our own company
We do this by creating an inventory of applications
and developing the repository
• We understand the project flow:
Rediscovery of the IT system
Analysis of deployment
Improve and align IT system with strategy
• Model the IT system within your own company
Page 120
Remember?
It’s all about Applications

APPLICATIONS

The way they The way their Their Their Their

break down components delivery of key deployment distribution in
according to interact within business and Technical IT City
Hierarchy their Functionalities Infrastructure planning
Architecture Areas
Page 121
Training Agenda

1 Pre course recap

2 Main Architecture Concepts

3 Inventory of Application Assets

4 Inventory of Application Components

5 Describing Application Environment

6 Describing Application Architecture

7 Describing Technical Infrastructure

8 IT City Planning

9 Mastering the HOPEX Repository

Page 122