Architecting modern information systems M1 enterprise architecture

Architecting of modern
information systems
Module 1
Enterprise architecture
A. Samarin

Importance of architecture

 No architectural blueprint  No disruption of river traffic activities
 38 years of construction  The committee evaluated 50 projects
 160 rooms, 497 doorways, 950 doors  Three architectural techniques
 Over 20 tonnes of paint required  8 years of construction
 Modernised for new technology

© A. Samarin 2012 Architecting of modern information systems - Module 1 2

The distinction between architecture, design
and implementation

• architectural specifications are intensional (i.e. there
may be many possible instances) and non-local (i.e.
mandatory for all parts of a system)
• design specifications are intensional and local
• implementation specifications are extensional (i.e. only
one instance is possible) and local


Terminology (1)

• system, noun
– functional entity formed by a group of interacting, interrelated or
interdependent parts
– Etymology: from the Latin systēma, which in turn is derived from
the Greek σύστημα meaning “together”.
– Remark: We deal with holistic systems "The whole is more than
the sum of its parts."

• architecture, noun
– fundamental orderliness (embodied in its components, their
relationships to each other and the environment), and the
principles governing the design, implementation and evolution, of
a system
– Remark: The architecture is usually the top level of abstraction of
the system in that it is the main factor which forms that system

Terminology (2)

• architect, noun
– <building construction> qualified individual who leads a design
team in the planning and design of buildings, and participates in
the oversight of building construction
– Etymology: from the Latin architectus, which in turn is derived
from the Greek arkhitekton, where arkhi means chief and tekton
means builder.
– Remark: In the broadest sense, an architect is a person who
translates a customer’s requirements into a viable plan and guides
others in its execution.


Terminology (3)

• architect, noun
– <systems construction> person, team or organisation responsible
for the architecture
– Remark: There are several different types of architect:
• enterprise architect, who architects an enterprise as a whole;
• solutions architect, who architects particular solutions (which
may comprise several IT systems);
• enterprise solutions architect, who architects enterprise-wide
solutions;
• business architect, who specialises in business architecture;
• business process architect, who specialises in business
processes;
• BPM/SOA architect, who specialises in BPM and SOA;
• chief architect, who is the leader of an architecture group.

Terminology (4)

• to architect, verb
– to define, document, maintain, improve and validate an
architecture


Any system has an architecture

• Accidental vs. Designed

• Implicit vs. explicit
• Descriptive vs. prescriptive
– blueprint
– roadmap
– principles
• Relativity of systems
– system for somebody is a component for another

• Different stakeholders see the same system differently
– you must to speak differently!

The purpose of the EA

• Enabling enterprise to manage more effectively

• Connect strategy with its execution

• EA is at the heart, a comprehensive view of IT and the
business. This allows the business leaders and CIO to see
the impacts of change, decisions and opportunities.


Architectural principles

• Principles are general rules and guidelines, intended to be
enduring and seldom amended, that inform and support
the way in which an organization sets about fulfilling its
mission.
• Typical definition pattern: reference, statement, rationale,
implication, sources
• Example of statements:
– Applications Do Not Cross Business Function Boundaries
– Applications Respect Logical Units of Work
– Applications Are Modular
– Application Functionality is Available Through an Enterprise Portal
– IT Systems Are Scaleable

Process and services are recursively
related
• All processes are services
• Some operation(s) of a service can be implemented as a
process
• A process includes services in its implementation


Big pictures are mandatory (1)


Big pictures are mandatory (2)


Horizontal and vertical processes are related


Long-running processes to be identified


Business events are potential decoupling
points


Business logic is not duplicated

Before After


Different stakeholders have different
views
• Strategy
– top manager
• Business
– manager
– process owner
– super-user
– user
• Project
– manager
– business analyst
• IT
– manager
– enterprise IT architect
– solution architect
– developer
– operator


Any principle can be ignored if you
master it


Communication to stakeholders

• Explain to each group of stakeholders
– Artefacts under their control
– Relationships under their control
– How to address their concerns (i.e. carry out a particular potential
change)

• Example
– architectural framework for improving BPM systems
– A comprehensive set of recommendations, models, patterns and
examples of how to transform existing disparate IT systems into a
coherent, agile and flexible BPM/SOA solution


Strategy: top managers

• The architectural framework is not about how to make
your products better, different and more attractive for the
market place – this is for you to decide

• What it offers is to help you reduce the overheads in
doing so – your flexible BPM system will become an
enabler for your business innovations


Business: enterprise architects

• Help in the definition of the different types of architecture
Maturity Technology Data Application Business Enterprise
level architecture architecture architecture architecture architecture
Optimising

Managed

Defined

Under
development

Initial

None

BPM, SOA and Enterprise Architecture - Part 3 22

Business: managers

• The architectural framework goal is to help you to
streamline your critical business processes by
– automating their management
– eliminating work which does not add value
– integrating existing applications around the business needs
– evolving information systems
in a coordinated manner

• Should make use of the
synergy that exists between
business needs
and IT potentials


Business: process owners

• The architectural framework classifies all human activities
as intellectual (evaluation, decision-making, etc.),
verification or administrative
• The goal is that the humans should perform only
intellectual activities, and other activities should be
automated (which may also improve quality)


Business: super-users

• Proactive control over execution of business processes
• Delegation of complex tasks to less-qualified staff
members
• Some maintenance without systematic involvement
of the IT


Business: users

• Common dashboard (over different applications) with
tasklist, worklist, notifications

• Common approach for the implementation of different
solutions


Project: managers

• Achievement of common understanding within a project
through clarification of the different views of artefacts
• Better visibility of artefacts
• Shorten the gap between modelling and implementation

Today Tomorrow


Project: business analysts

• The architectural framework offers a modelling procedure
to guide you to produce executable models
• Such a model acts as a skeleton or foundation to which
the IT attaches services to obtain the implementation


Project: business analysts

• A modelling procedure
– four-phase guidance to produce executable models
– diagramming style
– naming conventions Human
“workflow”
– several practical patterns Data
structures Roles
• Promoting joint work between
the business and IT
Documents
Events
Rules
Processes
• Quick iterations for building Services
an operational prototype Audit
trails
KPIs


IT: managers

• Considerable reduction of TCO
Each subsequent solution is cheaper because it
TCO reuses the same tools, the same services, the same
architecture

Maintenance Typical IT projects
approx. 80 %

First BPM/SOA project

Initial
development Further BPM/SOA projects
approx. 20 %
Life-cycle
v.1 v.2 v.3 v.4 v.5

IT: enterprise IT architects

• Architected flexibility – your BPM system is easily
adaptable to practically all aspects of the organisation
– policies and priorities
– constantly changing business processes
– business innovations
– computer knowledge and culture of the users
– IT systems
– size and complexity
– data
– SLA


IT: architects

• Implementation layers of artefacts


IT: architects (cont.)

• Relationship of BPM/SOA with other technologies


IT: developers

• Transformation from typical inter-application data flows to
end-to-end coordination of services


IT: operators

• The architectural framework helps to manage the
complexity of a mixture of interconnected and
interdependent services by making explicit all
relationships between services
• It thus allows a correct evaluation of the availability of
business-facing services from the known availability of
technology-related services


Human dynamics is critical


Role of architecture

• Consider a complex and dynamic system with many
– artefacts
– relationships
– potential changes
– stakeholders

• Explain to each group of stakeholders
– artefacts under their control
– relationships under their control
– how to address their concerns


Architecture used to construct Garthage

• Enterprise architecture is sometimes translated into
French as “urbanisation”


Some terminology

• framework, noun
– coherent set of ideas, principles, agreements and practices which
provides the basis or outline for something intended to be more
fully developed at a later stage
• reference model, noun
– abstract framework for understanding entities and relationships
between them in a particular problem space or domain
– Remark 1: A reference model is independent of the technologies,
protocols and products, and other concrete implementation
details.
– Remark 2: A reference model is often used for the comparison of
different approaches in a particular problem space or domain.
– Remark 3: A reference model is usually a commonly agreed
document, such as an International Standard or industry
standard.

Timeline of EA frameworks


Business needs for EA


Some EA frameworks

• The simplest
• Zachman framework
• The Open Group Architecture Framework (TOGAF)
• Federal Enterprise Architecture Freamework (FEAF)
• Model of C. Longépé


Some EA concepts

• Nomenclature / taxonomy of artefacts
• Building blocks
• Layers
• Improvement cycle
– As-is architecture
– Transitional architecture(s)
– To-be architecture
• Governance processes
• Top-down vs bottom-up
• Views and viewpoints


Views of information system


The simplest
Strategy and Planning

IT Architecture

Infrastructure

• Pros:
– Simple and easy to understand for everyone
– Historically well known

• Cons:
– Too simple
– Do not show the constraints and links between layers
– Requires to be described twice for the as-is and for the to-be


Zachman framework (1)


Zachman framework (2)

• WHAT – assets (physical and electronic ones)
• WHO – roles (e.g. people, organizations)
• WHERE – places (physical and virtual ones)
• HOW – functions (actions of making some assets from
other assets, adding value, etc.)
• WHEN – events (temporal, systematic, spontaneous,
external, internal)
• WHY – reasons (e.g. motivation, rules, internal and
external constrains including desired performance,
principles)


TOGAF (1)

• www.theopengroup.org


TOGAF (2)


TOGAF – Architecture development method
(ADM)


FEAF (1)


FEAF (2)

• Four reference models for the US governmental agencies


Model of C. Longépé
Métier
Description du métier
compréhensible par les
acteurs du métier

Fonctionnelle Description et
structuration fonctionnelle
du système d’information
Système d’Information

(Services)

Applicative Description et structuration
Système informatique

du système informatique
en composants logiciels
(Implémentation des
Services)
Technique
Infrastructure de fonctionnement
:: du système d'information et des
:: : : composants logiciels et
applicatifs


Comparison


Practical EA tools

• Nomenclatures
– Technical artefacts
– Business artefacts
– Organisational artefacts

• Organisational standards
• Documentation templates
• Rules (architecture know-how)
• Formal reviews of projects
• Qualification procedures


Collection and alignment of EA
Livre Blanc : Tools:
• Vue 6 • PM methodology tailoring
• Vue 7 • “Dossier architecture”
• NOCA • “Fiche chiffrage”
• Fiches • “Fiche qualité”
Operation units

Collection of EA rules
signalitiques
& security • Configurateur

Use of EA
Projects
Tool reviews
Architecture
Feasibility studies
Competence centers Enterprise

Capitalization
Macro-planning

PMO


Vue 6 – conceptual architecture


Vue 7 – technical architecture


Nomenclature Composante d’Architecture
(NOCA)

• Technical components (M-F-A-T)
– TSM, Jonas…

• Architectural services (M-F-A-T)
– E-paiement, Backup, Trésorerie…

• Architectural standards (M-F-A-T)
– JSR, HTTP…


NOCA – 1st classification

SERVICES INFRASTRUCTURE
• First classification is by
SERVICES APPLICATIFS
services
SERVICES SECURITE
• Organisation "historical" SERVICES RESTITUTION

SERVICES EXPLOITATION

SERVICES FONCTIONNELS /Métiers

SERVICES SUPPORT - Help Desk Métier

SERVICES GESTION DE PROJETS

SERVICES GENIE LOGICIEL


NOCA– 2nd classification

• Second classification is in accordance with used architecture
framework (Longépé):
– Business
– Functional
– Application
– Technical


NOCA– 3rd classification

• Third classification is by responsible person
– Who should be contacted…
– Who is responsible for further evolution…

moyen de stockage Infrastructure Spécialiste N.N.
Stockage

Type de Composant Référence Composant

S.S.S Tivoli Storage Manager
Sauvegarde
TSM -IBM
N.N., S.S.S Sauvegarde Veritas NetBackup

S.S.S high cost Baie Hitachi
S.S.S medium cost Sata-medium
S.S.S low cost Sata-low
S.S.S very low cost robot sun


NOCA – dynamics

• Current state of a component
VERT – Industrialiser et à recommander
JAUNE – Non industrialiser mais à recommander
ROUGE – A ne plus recommander

BLANC – A discuter avec EA

• Help to make a decision
– Chose existing VERT else JAUNE
– Avoid ROUGE

• Promote convergence
• Identify needs for feasibility studies


Descriptions of some components for
non-IT stakeholders
• Fiche fonctionnelle

• Fiche solution


“Configurateur” EA

• Ask user-oriented questions
to produce a EA check-list
• Rule engine for EA
• Generate “vue 6”


An example

• BPM, SOA and EA for e-Government


BPM, SOA and EA for e-Government:
steps of evolution

E-Social system

Target architecture

Introductory architecture

Portal-centic


existing applications

Partners

Portal

Application 2
Application 1

Application 3
Internal Internal Internal
existing existing existing
application application application Government


introductory architecture

Partners

Collaborative extranet (ECM-based)
between partners and government
e-Government
e-gov e-gov e-gov
service service service

Coordination and integration (BPM/SOA-based)

application application application Government

ECM – Enterprise content management


transitional architecture

Partners

e-Government
e-gov e-gov e-gov


BPM/SOA
application application service
applicationservice Government


future architecture

Partners

e-Government



service service service service service


an e-Social system

Partners

Social collaborative network (ECM-based)
e-Social system

public professional social


public private social public voluntary
service service service service service


use together different BPM tools

Partners

Definition of page flows
e-Government
e-gov e-gov e-gov

Orchestration and integration (BPM/SOA-based)
Coordination and choreography of services

Internal Internal BPM/SOA
Process mining existing
existing Case management
application application service service Government


Examples from ARIS

• A EA tool from Software AG
• Artefacts and relationships between them
• Impact analysis


Main view


Organisation


Department


All IT tools


Generic IT tools


Application portfolio for the whole
organisation


Application portfolio for one complex


An application dependencies


Submit purchase requisition process


Sourcing 1 process


Sourcing 2 process


Sourcing 3 process


Choose supplier process


A complex validation process


Treat disbursement application


Register disbursement application


Homework 1

• Propose some principles for business, data/information,
application, or technical architecture

• Add architecture into your project management practices

• You are in charge of the IT architecture for Tunisia.
Explain it to:
– the President
– any minister
– somebody in the cafeteria


Architecting modern information systems M1 enterprise architecture

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Architecting modern information systems M1 enterprise architecture

Ähnlich wie Architecting modern information systems M1 enterprise architecture (20)

Mehr von Alexander SAMARIN

Mehr von Alexander SAMARIN (16)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Architecting modern information systems M1 enterprise architecture