HiLCoE

School of Computer Science &Technology

CS754 - Software Architecture and Construction

Lecture – I
Enterprise Architecture
Autumn 2016

Nassir D. /PhD
Assoc. Professor (Software Engineering)
nassir@hilcoe.net
 Agenda

• Overview

• Architecture scenario

• Milestones

• Evolution of S. Architecture, Design and Coding

• Architecture in a program

• Software crisis

• EA Motivation

12/28/2016 HiLCoE CS754 - SAC 2

 Exercise Zero
(based on the topics attended so far)
What do you think when you hear the phrase SA?

• Curious?,
• Dismissive?,
• Challenging?
 In the same token, what do you think of EA?

12/28/2016 HiLCoE CS754 - SAC 3

 Architecture scenario
• A good Design is the key to a successful product.
• Roman architect Vitruvius, 2000 years ago
– Durability: firmitas
– Utility : utilitas
– Charm : venustas
• Negotiating and Balancing between Functionality, and Quality
requirements on one hand, and possible solutions on the other
hand
• Ex: The warship Vasa, 1620
Sweden (Gustavus Adolphus) and Poland
 Stakeholders involvement

• Building Drawings (electrical wiring, water supply, civil, etc. ) :

Vision/Views

12/28/2016 HiLCoE CS754 - SAC 4

 Software Architecture Milestones
• 1969: I.P. Sharp @ NATO Software Engineering
conference:
“I think we have something in addition to software engineering [1968, ..]
This is the subject of software architecture. Architecture is different from
engineering.”

• 1972 (1969): Edsger Dijkstra, program families

• 1978/79: David Parnas, program families
• 1985: Ideas from David Parnas
• 1987: Zachman Framework
• 1989: M. Shaw
• 1992: Perry & Wolf modified by Boehm
– Software architecture = {Elements, Forms,
Rationale/Constraints}

12/28/2016 HiLCoE CS754 - SAC 5

 Some Milestones, cont’d…
• 1995:
IEEE Software special issue on Software Architecture
• 2000:
– Views and Viewpoints standardised via IEEE-1471
– SEI’s “ATAM” analysis method published
– RUP becomes “architecture centric”
– J2EE 1.0 specification released

• 2001:
– The Working International Conference on Software Architecture
(WICSA) conference series starts

• 2002:
– .NET 1.0 released

12/28/2016 HiLCoE CS754 - SAC 6

 Some Milestones, cont’d…

• 2003:
– Bass, Clements and Kazman, 2nd Edition
– Practitioners (software Engineers) admit software architecture exists!
• 2005:
– The SOA open Group and software industries IBM, Oracle, Microsoft
– IASA is founded and starts growing; Intr’l Assoc. SA
– New “Perspectives” concept identified
• Nick Rozanski and Eoin Woods Software Systems Architecture viewpoints and
perspectives practitioner-oriented book
– WICSA series (The Working International Conference on Software Architecture )

12/28/2016 HiLCoE CS754 - SAC 7

 Some Milestones – School of thoughts

• 1995: Philippe Kruchten’s “4+1” viewpoint

– Logical, Process, Development, Physical View + Scenario
– IEEE Software special issue on Software Architecture

• 1996: Shaw and Garlan’s ; Hofmeister et al.:

– “Software Architecture: Perspectives on an Emerging Discipline”
– Conceptual, Module, Execution, Code View
• 1998:Bass, Clements and Kazman
– Published “Software Architecture in Practice”, 1st edition
– Module, Component and Connector, Allocation View

12/28/2016 HiLCoE CS754 - SAC 8

 The Present
• The language of SWA is widely used
– Even if rarely defined or understood
• Good core of knowledge emerging (Books)
– Approaches and techniques
• Organisations & certification emerging

• Organisations are seeing value

– Supply: IBM, Microsoft, Evolution-Detica,…
– Demand: Hartford Financial, UBS, BP, …
• Some agreement on fundamentals
– Stakeholders, structures, qualities
– Understanding, designing, trading-off, delivering

12/28/2016 HiLCoE CS754 - SAC 9

 Overall Evolution

EDI EAI CORBA XML Web Services Business

Function / Process
Automation

BPEL, WSDL
Service Oriented

EDI – Electronic Data Interchange Component Based COM, EJB

EAI – Enterprise Application Integration
CORBA – Common Object Request Broke Architecture
XML – extensible Markup Language
Web Services Object Oriented C++, VB, Java
COM – Common Object Model
EJB – Enterprise Java Bean
BPEL – Business Process Execution Language Procedural
PL/1, COBOL
WSDL – Web Services Description Language

12/28/2016 HiLCoE CS754 - SAC 10

 What is the Problem?
This is a simple
theS tor ag e

aW ar ehous e software system!

U M L- A Gener ated As s oc iati on C l as s :aN av P oi nt A ss oc iation ( 0.5)
1.0)

aR oute

U M L- A G ener ated D ependenc y C lass :aR outeC oll ec ti on As s oc iati on ( 0.5)

U M L - A G enera ted De pend enc y C lass :aR ou teC ol l ec tio n Ass oc iatio n ( 0. 25)
theV ehi cl eC ollec ti on
U M L- A Gener ated As s oc iati on C l as s :aW ar ehous e As s oc iation ( 1.0)

aV ehi cl e

U M L- A Gener ated D ependency C l as s :theR outer D ependency ( 1.0)

U M L- A G ener ated D ependenc y C las s:theR outer D ependenc y ( 0.5)
U M L- A G ener ated D ependenc y C l ass :theR outer AsAUs oci
U M L- G L-ation
M ener ( 0.25)
AU ated
Gener
M L- AA
Uated
ss
G
Mener
oci
L- A
As
Uation
ated
G
Ms ener
oc
L- C
A
iati
Aslas
ated
Gener
son
oc
U
s:aN
CM
iation
Aslated
L-
as
Uav
sMA
oci
sPoint
:aN
C
Gene
Aation
L- lA
sU
ass
av
soc
MAs
Prated
:aN
L-
C
Generiati
oisA
las
nt
oc
avP
on
GA
iation
s:aN
Ass
enera
atedss
CoilAs
oc
as
nt
avP
iation
sA
(ted
1.0)
:aN
ss
ocoint
D
oc
av
epend
Ciati
(APoi
iation1.0)
las
s soc
on
Cnt
s:theW
lency
As
iati
( 1.0)
ass s:theR
on
oci
Carl ass
(ation
eh
1.0)
ous
:aR(eC
outer 1.0)
outeC
Asol lecollec
s oci tion tio
ation D (epen
n0.25)
A ssdenc
oc iati
y on
( 0.5)
( 0.5)
U M L- A U M L- Aass
G ener ated D ependenc y C las s:theR outer D ependenc y ( 1.0)
U M L- AU Gener
M L- AU ated
M
Genera
L- AA
UsG
Msoc
ted
ener
L- A
iati
U
Asated
M
Gsoci
on
ener
L- A
C
As
UalG
ated
ti
M
asson
ener
oci
L-
s :theVehic
C
AAs
U
ation
lated
Gener
ML-
as
s oc
s:CA
theVe
iation
Ulas
ss
ated
M
Gen
leC
oc
L-
s:theVehi
hic
ol
A
C
erate
iation
AUlec
lsG
M
ass
leC
soc
ener
L-
tion
d:theV
ollec
CA
iati
UAss
clas
ated
G
M
leC
on
ener
L-
ociati
ti
sehi
on
:theVehic
oll
A
CAs
cl sG:theVehic
lection
ated
Gener
ali
G
asseC
on
enera
oci ener
zation
oll
CAation
lated
ss
ec
G
leC
as ated
liener
oc
tizs:th
(on
atio
ol
1.0)
CAs snDoc
iation
lection
las
aliz
eVehi
Gener
leC ependency
s:theVehi
(ati
ol
1.
C
iation
lec
con
0)
las
G
al
leCener
iz
tion
s(ation C
o:theVehic
1.0)
Cllclaliz
G
ec
ass
leC (lati
ener
tio :theV
oll
1.0)
non :theR
ection
ali
Ge
leCzation
ehic
(neral
1.0)outer
ol lection
G
l eC
iener Daliz
zationGependency
(ollec
1.0) ener
ti on
(ati
1.0on
aliz
Gener
) (ati ( 0.5)
1.0)
on
al iz(ation
1.0) ( 1.0)
aT r uc k aShip aA ir plane theW ar eho us eC o l lecti on U M L- A Ge nerate d Gen erali z ation C lass :avail ableV ehic le C ol le c tion D epe ndenc y (1.0 )
U MU L-M A L-GAener Generatedated As sAsoc isoc
ationiatiConlass
C l as
:theV
s :avail
ehi cl
ableV
eC ollehic
ec tileC
on D
ollec
ependenc
ti on D ependenc
y ( 0.5) y ( 0.5)
U M L- A Gener ated D ependenc y C l as s :theR outer As s oc iation ( 0.5)
U M L- A Gener ated D ependency C l as s :theR outer As s oc i ation ( 0.25)

U M L- A G ener ated D ependency C l ass :theR outer D ependency ( 1.0)

U M L- A G ener ated D ependenc y C lass :theR outer D ependenc y ( 1.0)
U M L- AU G
Mener
L- A ated
G ener
Asated
s ociAation
ss ociCation
las s:aD
C las
iffic
s:aDi enci ffiy ciAs
enc
s oci
y Aation
ss oci(ation
1.0) ( 1.0)
t heR ou ter U M L- A
UM Gener
L-UAMG
ated
enerAs
Gated
socAiati
s soc
on iati
CL-
sl as
onsG
iC:aD las
L- UA ML-
ener
U ated
A ML-
Gen A As
Uerated
M
Gen oc
A
U M ation
erated
As ener
sL- oAiffic
sC
G
M:aD
iency
slass
ciatio
UAs
ated
ener
L- iAffic
AC:aD
o nciatio
ss iency
As
Gl a
atedoc
sn
enersoc
iffic
s:aD
C aA
siati
ienc
iation
Aslatedisffic
soc soc
on
s:aD
C ie
As iati
las(iffic
yiation
Assncy1.0)
ocion
s oc
:aD
Cie
A i(ffi
liass
sncy
ation 1.0)
ation
soc c:aD
A s( 1.0)
ienc
Ci ation
soc
lass y :aD
iffic A
iienc
ation
(ss
1.0)
oc
ifficiation
y Asi(enc
1.0)
s oc ( 1.0)
y iation
As so
U M L- A G ener ated A s soc iati on C las s :aN av Point As s oci ation ( 0.25) U M L- AU G
Mener
L- A ated
G enera
As sted
ociAation
ss ociCation C las
las s:aS ur s:aSurp
pl us As slus As son
oc iati oci(
U M L- A G ener ated As s oci ation C las s:aN avP oint A s soc iati on ( 0.25)
U M L- A G ener ated
U M L- As s oci
A Gener ation
ated A sCsoc
lass :aW
iati on ar
C lehous e As
as s :aW s oci ation
ar ehouseU MAsL-(soc
A0.5)
Gener
iati onated AsUs oc
( 1.0) M L- Aon
iati G ener
C l asated
s :aNAs
av sPoc iation
oi nt A ss C
ocl ass :aN (avP
iation oi nt A ss oc iati on ( 0.25)
0.25)
U M L- A G ener ated D ependenc y C las s :theW ar ehous eC ollec ti on D ependenc y ( 1.0)
avai lableVehic leC ol lection aR outeC oll ec ti on
U M L- A G ener ated D ependency C l ass :theR outer As s oc i ation ( 1.0)
U M L- A G ener ated D ependenc y C las s:theR outer A s soc iati on ( 0.5)
U M L- A G ener ated As s oc i ation C lass :theW ar ehous eC oll ec tion D ependency ( 0.5)
U M L- A G ener
UM ated
L- ADGener
ependenc
atedyDCependenc
las s :theRyouter
C l as sA:theR
s soc iati
outeron As
( 1.0)
s oc iation ( 1.0)

theC ar g oR outer

U ML - A Genera ted As soci a ti on C l as s: theW a r ehou s eCo l lectio n De pende nc y ( 0.25)

U M L- A Gener ated A s soc iati on C l as s :aR oute As soc iati on ( 0.5)

theAW T aLoc ation

U M L- A G ener ated A ss oc iation C las s:theR outer A s soc iati on ( 0.25)

U MMAL- A Gener ated Ass:aN

socociati on CCl As
as sss:aR oute As0.5)
socociati on ( 0.25)
MUL-
U M L- A G enerUated AL-
ssGAoc
Gener
iation
ener ated
ated ssAs
CAlas ocsiation
iati
av on
Point
C las lsas
:aR :aR
oc oute
A ss(As
iation
oute ocsiation
iation ( 0.25)
( 0.25)
U M L- A G ener ated As s oci ation C las s:aN U av
M L-
Point
A Gener As soc
ated
iati on
As s(oc
0.5)
iati on C l as s :aR oute As s oc iation ( 0.25)

aVehi c eD ialog aW ar ehouseD ialog aPor tD ialog aR outer D ialog aN avPoint

U M L- A G ener atedUAs
M sL-
ocAi ation
Gener Cated As soc
lass :aN avPiati
ointonACslsoc
as siati
:aWonar (ehouse
0.5) As soc iati on ( 0.5)

U M L- A G ener ated As s oci ation C las s:aW ar ehous e A ss oci ation ( 0.5)

availableG oods aPor tC oll ec ti on

U M L- A GUener
M L-ated
theT im eN eeded
A G ener ated
A ss oci As sCoci
ation lasation
s:aWCar
las s:aWear
ehous A ehous e As s (oci
ss oc iation ation ( 0.5)
0.5) We have to do better!
U M L- A Gener ated As s oc iati on C l as s :aW ar ehous e As s oc iation ( 0.5)

aPor t aSur p l us aD iffic iency

U M L- A G ener ated A ss oc iation C las s :aW ar ehous e A ss oc iation ( 0.5)
U M L- A G ener ated
U MAs
L-sAoci
Gener
ation ated
C lass
As:av
socailiati
ableG
on Coods
l as s :aW

theG oods
As s oci
ar ehouse
ation ( 0.5)
As soc iati on ( 0.5)

Monolithic : Software Architecture

12/28/2016 HiLCoE CS754 - SAC 11
 Thank you,
for today.

12/28/2016 HiLCoE CS754 - SAC 12

 HiLCoE
School of Computer Science &Technology

CS754 - Software Architecture and Construction

Lecture – II
Enterprise Architecture
Autumn 2016

Nassir D. /PhD
Assoc. Professor (Software Engineering)
nassir@hilcoe.net
 Agenda

• Software Crisis
• Architecture Vs Design

• Knowledge Source

– Traditional Architecture limitation

• EA Approaches

• EA way of Thinking

– Points of view
• Types of points of view
– Stakeholders
12/28/2016 HiLCoE CS754 - SAC 14
 Symptoms of the Software Crisis

• Software in the 60’s

– Was full of errors,
– Could not be maintained or modified,
– Was not delivered on time,
– Did not meet the requirements,
– Implementation not engineering, ...

12/28/2016 HiLCoE CS754 - SAC 15

 Causes of Software Crisis
• There were no established foundations for
– Programming methodology,
– Project organization and management,
– Testing and quality assurance,
– Technical support, Tools, ...

• Today these foundations exist, ...

but

• Are we still in a software crisis?

12/28/2016 HiLCoE CS754 - SAC 16

 35 years of research in SE (Maarten Boasson)
• Software Crisis now worse than in 1960’s
– 85% of large software projects fail
• Never complete
• Way over budget and/or over time
• Reduced functionality
– Reliability of software very questionable
– Incredible waste of resources
– Development effort out of proportion
 The underlying causes were architectural!
But, where was the architecture hidden?
12/28/2016 HiLCoE CS754 - SAC 17
 Exercise on what SA … Address?
– What is the role of architecture from programming, design
and requirement engineering perspectives?

– What are architectural aspects and that are not?

– How would you measure the cost and the benefit? How
architecture documentation be useful?

– Which views, stakeholder, have you found useful or not in

software systems? Why?

– How an architecture document can be a blueprint or

roadmap for the organization?
– Who is Architect?

12/28/2016 HiLCoE CS754 - SAC 18

 Software Architecture way of thinking?

• Focus Solution centric

• Approach Model driven
• Primary concern Fundamental Structure
• Target Audience Downstream designers and Implementers
12/28/2016 HiLCoE CS754 - SAC 19
 The Motivation – Enterprise Architecture

• Rapid and continuous growth of enterprise so is software

– size, complexity, heterogeneity, distribution
– reliance on legacy software, hardware, and environment
• Alignment with context
– Stakeholders concern (vision, strategies, ROI, goals and policies)
• Agility
– Business, Technology, Customer
• Interoperability with heterogeneous platform/infrastructure
– each hardware device runs its own software
– Business processes

 Engineering systems of systems

12/28/2016 HiLCoE CS754 - SAC 20
 Rationale of EA
• The key reasons:
• Enables managed innovation within the enterprise;
• Effective management and exploitation of information through IT
is critical to business survival and success

• Current IT systems do not really meet the needs of business

– Fragmented, duplicated
– Poorly understood
– Not responsive to change
• Investment in Information Technology
– Focussed on system maintenance
– Tactical developments rather than a strategic plan
• Good information management = competitive advantage

12/28/2016 HiLCoE CS754 - SAC 21

 Where do Architectures Come From?

Knowledge Repository from:

• The result of a set of Business and Technical decisions;

• In any development effort, the requirements make explicit

some - but only some - of the desired properties of the final
system;

• Failure to satisfy non-documented constraints can cause as

many problems as if it functioned poorly.
– Supplemental constraints

12/28/2016 HiLCoE CS754 - SAC 22

 Traditional S. Architecture limitations

• The traditional approaches although have understood

architecture as a blueprint, they are restricted to system
structure.
• Solution implementation architecture limited to:
• Software modeling, design, and implementation
o Approaches – OOM, Modular, SOA, …?

• Disconnect between Business Strategy and IT Execution.

• Two traits common to virtually all of the successful / and
absent from failures object-oriented systems
 Existence of strong Architectural Vision
 Well-managed Iterative and incremental development cycle.
—Grady Booch [Stikeleather 96]

12/28/2016 HiLCoE CS754 - SAC 23

 Whereas, Architecture – attempts …
• Integrating the business as well as information aspects:
– People, Processes, Business and Technology views into
considerations at all levels of enterprise.
– Identifying IT capabilities required to support required
enterprise business capabilities (top, middle and bottom).

• To deal with Application Frameworks, defining Business

components, addressing Enterprise Integration pattern and
enterprise wide IS Solutions or Applications;

• HENCE?
 it requires pre-thought EA.
12/28/2016 HiLCoE CS754 - SAC 24
 EA - Approach

• EA is based on Top-Down, Middle-Out and Bottom-Up

approaches to:
– Identify IT capabilities required to support required
enterprise business capabilities.

• Unlike software Architecture, it is not only a matter of

developing a system, rather should communicate and
share the vision at different viewpoints.
• Accommodate OOM, SOA and so on as an
architectural style to provide end-to-end alignment of
business and IT.

12/28/2016 HiLCoE CS754 - SAC 25

 EA way of thinking about “Architecture”

Where requirements are

defined as properties

EA way of Thinking
• Focus Mission centric
• Approach Principle driven
• Primary concern Properties essential to fitness for purpose
• Target Audience All stakeholders
Properties == Any relevant aspect that matters, including principles
and structural constraints (e.g., structural models), decisions
12/28/2016 HiLCoE CS754 - SAC 26
 So, Architecture is?

• Fundamental concepts or properties of a system in its

environment embodied in its elements, relationships, and in
the principles of its design and evolution (ISO/IEC/IEEE 42010 )

• Properties == Any relevant aspect that matters, including

principles and structural constraints (e.g., structural models),
decisions

• Architecture binds the mission, its solution and their

environment
– Fit for purpose (Necessary and Sufficient)
– Everything you need and nothing you don‘t

12/28/2016 HiLCoE CS754 - SAC 27

 Architecture (EA) Vs Design (SA inward)

12/28/2016 HiLCoE CS754 - SAC 28

 Points of View

• In addition to the subsystems and other software

elements, you have to also consider different points
of view of the system.

• Each point of view is concerned with a different part

of the architecture, or you could say that each point
of view requires its own architecture.

12/28/2016 HiLCoE CS754 - SAC 29

 Many types of points of view …

 Technology Architecture;
 Network Architecture;
 Security Architecture;
 Data Architecture;
 Systems Architecture;
 Software / Application Architecture;
 Information Architecture;
 Business Architecture;
 Etc …
 Do they have something in common?

12/28/2016 HiLCoE CS754 - SAC 30

 Stakeholders

• Those who care if the system gets built

– Can be for some interest
– Includes people, groups and entities
• The reason we build systems
– Systems are built for stakeholders
– Design decisions must reflect their needs
– A wide community often increases the chances of success?
• Stakeholder focus
– Ensuring that the right system is built
– System-wide (or cross-system) consistency

12/28/2016 HiLCoE CS754 - SAC 31

 Facilitates Communication Among Stakeholders

• Business and technology stakeholders abstraction.

• Different stakeholder may be concerned with different

aspects of the system supported by the architecture.

• Stakeholders may be concerned with the same system aspects

from different perspectives.

• Can you give examples of different concerns or perspectives

related to specific stakeholders?

12/28/2016 HiLCoE CS754 - SAC 32

 Stakeholders

Stakeholders influence on the

architect

12/28/2016 HiLCoE CS754 - SAC 33

 More on Stakeholders , cont’d…

• Stakeholders (Top to bottom)

– Project manager;
– Business analyst,
– Users,
– Developers,
– Maintainers,
– interactions with other systems, run time system, and
hardware
Note
Describe the solution from respective points of view. For any particular project, identify the
points of view that will need to be documented in the architecture.

12/28/2016 HiLCoE CS754 - SAC 34

 Requirements based on Stakeholders

• Business managers
– Use the architecture to understand how system availability and
reliability requirements will be met.
– Use the architecture to help understand how the system can be
implemented on schedule and budget.

• Project manager
– Use architecture for planning and assigning work.
– Use architecture to help clarify how functional scope (Use Cases) will
be supported.
• Analysts, Designers, and Developers
– Use the architectural views and guidelines to ensure consistency with
the architecture.

12/28/2016 HiLCoE CS754 - SAC 35

 Thank you,
for today.

12/28/2016 HiLCoE CS754 - SAC 36

 HiLCoE
School of Computer Science &Technology

CS754 - Software Architecture and Construction

Lecture – III
Enterprise Architecture
Autumn 2016

Nassir D. /PhD
Assoc. Professor (Software Engineering)
nassir@hilcoe.net
 Agenda

• Enterprise

• Enterprise Architecture

• Enterprise Architecture Layers

• Meta Architecture

• The EA – Drivers

• EA Perspectives

12/28/2016 HiLCoE CS754 - SAC 38

 Overview on Enterprise
 EA in Government organizations
• Collection of organizations that share a common set of goals
 Example 1
• Government Agency
 The case of U.S.A. Federation by 11 Architects

• Key goals
– citizen-centered, results-oriented and market-based;

• On a holistic policies basis

– To uncover common business services Ex Utilities ;
– Allows underlying systems and applications to interoperate;
– Additional benefits include common technology platforms, data
exchange and application development standards.
– Facilitates seamless delivery of e-services for Citizens and Businesses alike.

12/28/2016 HiLCoE CS754 - SAC 39

 Enterprise, Cont’d…
• A business association consisting of a set of interacting
business functions able to operate as a separate entity
(Part of a corporation or Corporation)
 Example 2
• Large corporations may comprise multiple enterprises –
Multi National Companies Ex Microsoft;
 In the same token, EA formulates policies on
– Reuse : Common technology platforms, data exchange
standards and application development standards
– SA should be consistent with the Enterprise Architecture.

• EA could be EEA “Extended Enterprise Architecture”

– That includes partners, suppliers and customers.

12/28/2016 HiLCoE CS754 - SAC 40

 What is Enterprise Architecture?
• Enterprise Architecture is:

The organizing logic for business processes and IT capabilities

reflecting the integration and standardization requirements
of the firm’s operating model. [1]

A conceptual blueprint that defines the structure and operation of

an organization. The intent of an enterprise architecture is to
determine how an organization can most effectively achieve its
current and future objectives. [2]
[1] MIT Center for Information Systems Research
[2] SearchCIO.com

12/28/2016 HiLCoE CS754 - SAC 41

 Enterprise Architecture (EA), Cont’d…

"The EA discipline defines and maintains the

Architecture models, Governance and transition
initiatives needed to effectively co-ordinate semi-
autonomous groups towards common business
and/or IT goals.“ =IBM=

• Two key reasons why you need an enterprise

architecture:
– Critical to business survival and success
– Enables managed innovation within the
enterprise
12/28/2016 HiLCoE CS754 - SAC 42
 EA, cont’d ...
• EA includes four main architectures, namely,
Business architecture, Data/information architecture,
Application architecture and Technology
architecture. By IBM; Zachman; TOGAF ,…
• EA focus at macro level, unlike Software Architecture
focus at a micro level of architecting.
• Software architectures should be consistent with the
Enterprise Architecture.

12/28/2016 HiLCoE CS754 - SAC 43

 EA purposes

• To provide consistency in software development throughout the

Enterprise;

• To remove inefficiencies that have been introduced over time as the

Enterprise systems were developed;

• To implements high level corporate requirements and constraints

imposed on the project by the EA; that impact all or most systems
– corporate security (physical, internet, data)
– governance requirements
– Standards, business best practices, corporate culture, innovation and so on

• Remember – even if the Enterprise Architecture is not formally documented, there is

one! There are systems, networks, applications, data, standards, and business
practices that already exist in your company, unless you are working for a true startup
company.

12/28/2016 HiLCoE CS754 - SAC 44

 HIERARCHY OF ARCHITECTURE

• Architecture in an Enterprise is composed of layers of

architecture,
– From very high broadly defined architecture at the Enterprise level
through very detailed architecture at the project level.

• These layers are:

– Enterprise
– Product Line or Program
– Project

• A layer describes a group of related software components

12/28/2016 HiLCoE CS754 - SAC 45

 The Holistic view Ex - Vendor

• Architecture can be described in a hierarchical fashion,

starting with a high level overview and continuing to more
detailed descriptions of the individual subsystems.

Enterprise Architecture

Program or Product Line Architecture

Project Architecture

12/28/2016 HiLCoE CS754 - SAC 46

 Examples on the Hierarchy
Example 1 - Such as a whole city master plan or all the
systems in a corporate enterprise; Architecture in the large

Example 2 - Such as a complex of buildings or a software

program or product line; Medium

Example 3 - Such as an individual building or the

architecture of one software product; Small

12/28/2016 HiLCoE CS754 - SAC 47

 E. Architecture Description Encompasses
• The Enterprise wide a very high level description of IT
resources and their relationships.
• Infrastructure
– Networks
– Computers and their relationships
• Information Systems
– Software applications and their relationships
– Databases and their relationships
• Governance
• Policies, Procedures, Guidelines, Standards, Best Practices, Tools

• Business strategies
– High level BP (segments) , Functional and quality requirements

12/28/2016 HiLCoE CS754 - SAC 48

 Product Line Architecture
• A high level description of a set of software
products that are related;
• To provide consistency in software development
throughout the product line;
• To remove inefficiencies;
• Implements requirements that impact all or most
products in the product line such as basic features
and processes or user interface standards;
• Project architecture must fit into that product line
architecture.
12/28/2016 HiLCoE CS754 - SAC 49
 A Program Architecture
• High level description of a set of software projects
that are related; Relationships between the smaller projects.
• High level requirements, functional and non-
functional, that will be implemented by the various
projects; Supplemental reqt’s.
• To coordinate the work of the different project
teams in the program;
• To provide a complete, though high-level, description
of the architecture with an indication as to which
projects are implementing which parts of the
architecture.
12/28/2016 HiLCoE CS754 - SAC 50
 The Project Architecture
• Describes the architecture of a single project;
• Maintenance of existing software – modifying existing
code;
• To re-architect some part of the existing software for
efficiency, ease of maintenance, or to update to new
standards;
• Installation of third party software – “plugs in” to the
Enterprise architecture;
• Customizations and integrations, and how the new
software will be deployed, additional code, integrate;
• New software development –to create the architecture for
the project, ROI, prototyping and testing to find the best
solution.

12/28/2016 HiLCoE CS754 - SAC 51

 The Project Architecture
• researching the existing software,
• analyzing the software for problem areas,
• recommending new architecture and
strategies for fixing those problems, and
• describing how you will migrate from the old
to the new architecture, including any impacts
on other applications.

12/28/2016 HiLCoE CS754 - SAC 52

 To start with the Solution Architecture …
• Meta Architecture (MA) to identify purpose, concerns,
characteristics and drivers of a project in an enterprise.
• MA refers to the information you will use to guide and document
architectural decisions.
• Information about the architecture
– Enterprise standards, Reference architectures, patterns,
guidelines, candidate solutions, project purpose and requirements
• Relationship with organizational structure and information
model
• The Holistic view , lessons learnt from previous projects,
•

• Trade-off limitations of previous project and product Architectures.

• Among many WHICH architectural style is best fitting AND HOW?
– Alternatives considered and design patterns

12/28/2016 HiLCoE CS754 - SAC 53

 Meta Architecture
• Who uses this information?
• The Project Architect need this information.
• It is good to document your decisions and
alternatives considered so this information is
available to anyone who maintains the
architecture over time.
• The project sponsor may wish to review this
information before approving your architecture.
• The development team will reference this
information when making design decisions.

12/28/2016 HiLCoE CS754 - SAC 54

 The industry practice
• Enterprise Architecture (EA) is emerging as a
key practice in dealing with business and
technology complexities.
• The case 500 fortune companies by IBM

• EA frameworks and methodologies are being

used to address challenges and improve the
return on technology investments.

12/28/2016 HiLCoE CS754 - SAC 55

 The EA - Drivers
• EA main concerns:
– Vision
– Agility
– Consistency
– Simplicity
– Interoperability
– Reuse
– Business & IT Alignment, Governance, Strategy and so on

• Characteristics: (ROI , Durability, Usability, Efficiency, Duplication,

Fragmentation, Dependability, Availability, Integrity, Completeness,
Security, …)
• Hint – An SOA as architectural style is best fitting. Provide solutions
based on Service Engineering.

12/28/2016 HiLCoE CS754 - SAC 56

 EA Perspectives

 EAF has Four main components in common,

Business Architecture
Information Architecture
Information Systems Architecture
 Data Architecture and Application Architecture
Technology Architecture

• Solution Architectures should be consistent with the

Enterprise Architecture.

12/28/2016 HiLCoE CS754 - SAC 57

 EA with perspectives

• Business Architecture

Defines the business vision, strategy, governance, organization, and

key business segments. Shows how the organization meets its
business goals, develop baseline and target architectures and analyze
the gaps.

• Data/Information Architecture

Describes the structure of an organization's logical and physical data

assets and data management resources.

12/28/2016 HiLCoE CS754 - SAC 58

 EA with perspectives, cont’d…

• Application Architecture

Provides a blueprint for the individual application systems to be

deployed, their interactions, and their relationships to the core
business processes of the enterprise. Shows how the IT systems
meets its business goals of the enterprise, develop baseline and target
architectures and analyze the gaps.

• Technology Architecture

Describes the logical software and hardware capabilities that are

required to support the deployment of business, data, and application
services.

12/28/2016 HiLCoE CS754 - SAC 59

 Homework …?

Why we are not satisfied with all the design,

implementation, and requirement engineering
options we have so far?

12/28/2016 HiLCoE CS754 - SAC 60

 Thank you,
for today.

12/28/2016 HiLCoE CS754 - SAC 61

 HiLCoE
School of Computer Science &Technology

CS754 - Software Architecture and Construction

Lecture – IV
Enterprise Architecture
Autumn 2016

Nassir D. /PhD
Assoc. Professor (Software Engineering)
nassir@hilcoe.net
 Agenda
• Overview
– EA perspectives
• Framework and Architecture
• EA Framework Models
• Reference Architectural Framework
• EA Framework Approaches
– Pragmatic EA Framework
– The Open Group Architecture Framework – TOGAF
– Zachman Framework
• Appendix
12/28/2016 HiLCoE CS754 - SAC 63
 EA Perspectives

 EAF has Four main components in common,

Business Architecture
Information Architecture
Information Systems Architecture (Software Architecture)
 Data and Application Architectures
Technology Architecture

• Software architectures should be consistent with the Enterprise

Architecture.
• ‘‘An effective enterprise architecture is critical to business survival
and success and is the indispensable means to achieving
competitive advantage through IT.’’ open group

12/28/2016 HiLCoE CS754 - SAC 64

 EA with perspectives

Business Architecture
Defines the business vision, strategy, governance,
organization, and key business segments;
Shows how the organization meets its business
goals;
Develop baseline and target architectures and
analyze the gaps.

12/28/2016 HiLCoE CS754 - SAC 65

 Business Architecture; As-Is & To-Be

• Addresses the following questions:

– What are the critical business problems and opportunities?
– What are the major goals of the company?
– What Strategies does the company plan to reach those goals?
• New product lines.
• New markets.
• Reduce operating costs.
• Increase customer satisfaction.
• CBR - Provides a high-level blueprint of all critical business events and
processes, describing interdependencies.
• Business scenarios are used to help identify and understand business
needs, and thereby to derive the business requirements that the
architecture development, and ultimately the IT, has to address.

12/28/2016 HiLCoE CS754 - SAC 66

 Business Architecture; As-Is & To-Be

 Analyzes the organization business drivers (Concerns and

Characteristics).
• Concerns:
– Vision
– Agility
– Consistency
– Simplicity
– Interoperability
– Reuse
– Business & IT Alignment, Governance, Strategy and so on

• Characteristics: (ROI , Durability, Usability, Efficiency,

Duplication, Fragmentation, Dependability, Availability,
Integrity, Completeness, Security, …)

12/28/2016 HiLCoE CS754 - SAC 67

 Enterprise - Business perspectives importance?

• Architecture from Organization perspective–

– Help to manage complexity
– Maintainability
– Ability to move into new lines of business
– Ability to run on important platforms/innovation
– Ease of learning by new employees
– Generalists or specialists?
– Require architect of business and technology strategic alignment and
capabilities matching

12/28/2016 HiLCoE CS754 - SAC 68

 Example - To Manage Complexity

• Architecture represents a high level abstraction of the

system(s).
– Abstractions focus on specific concerns of a group of stakeholders.
– Each abstraction eliminates details that do not pertain to the concern
being addressed.
– Most architect stakeholders can understand this representation.

• Multiple views and models are used to depict concepts.

– Simple models make the architecture easy to understand.
• Work can be condensed into architectural components.

12/28/2016 HiLCoE CS754 - SAC 69

 EA with perspectives

Data/Information Architecture

Describes the structure of an organization's

Logical and physical data assets; and
Data management resources.

12/28/2016 HiLCoE CS754 - SAC 70

 Information Architecture
• Analyzes the key information assets of the enterprise.
• Consists of data models and databases that serve the
business and its strategies, standards, and policies.
• Includes an inventory of files, databases, and data
warehouses required to support current and planned
applications.
• It covers:
– Types of information and locations
– Timing and sequencing of information to meet business needs
– The types of information needed to be shared

• Focus is on providing common, shared, distributed, accurate,

and consistent data resources.

12/28/2016 HiLCoE CS754 - SAC 71

 EA with perspectives, cont’d…

Application Architecture

Provides a blueprint for the individual application

systems
to be deployed, their interactions, and their relationships to
support the business processes or services of the
enterprise.
Shows how the IT systems deployed meets business
goals of the enterprise,
Develop baseline and target architectures and
analyze the gaps.

12/28/2016 HiLCoE CS754 - SAC 72

 Application Architecture
• A description of the major logical grouping of capabilities
that manage the data objects necessary to process the data
and support the business function.
• Models the core business applications required to successfully
run the business.
• Identifies all legacy systems, software packages, and
distributed systems.
– Includes strategic value for each application and the infrastructure.
– Includes an assessment of health and quality of applications.
• Identifies new applications to satisfy business needs.
• Interdependencies and interoperability between applications
is identified.

12/28/2016 HiLCoE CS754 - SAC 73

 EA with perspectives, cont’d…
Technology Architecture
Describes the logical software and hardware
capabilities that are required to support the
deployment of (corporate requirements)
business, data, and application services.

Provides the link between the application, business, and

data architecture interoperable technology platforms.
SaaS, Paas and DaaS (to remove inefficiencies)
ESB
Reading Assignment : iCloud Service

12/28/2016 HiLCoE CS754 - SAC 74

 Technical Architecture

• ESB - Takes into consideration underlying

technologies required to run applications.
– Computing platforms
– Networks
– Operating systems
– Database management systems
– Storage devices
– Middleware
• Identifies candidates for phasing out.

12/28/2016 HiLCoE CS754 - SAC 75

Enterprise - Technology perspectives importance?

• Three fundamental reasons from a technical

perspective:
– Early design decisions
• earliest point at which decisions can be analyzed

– Transferable abstraction of a system

• can promote large-scale reuse

– Communication among stakeholders

• a basis for mutual understanding, negotiation, & consensus

12/28/2016 HiLCoE CS754 - SAC 76

 Example - Early Design Decisions

• dictates organizational structure

– Work breakdown structure can inherit from the
architectural structure to some degree.
– Developers can be assigned functionality based on
architectural components.
– Scheduling functionality implementation can depend on
architectural component availability
– Specialization may exists based on the architecture.
– Set of decisions lead to …

12/28/2016 HiLCoE CS754 - SAC 77

 A Framework and Architecture?
• Framework:
– Provides a practical starting point for an Architecture Project (Avoid
Panic).
– Describe a method for Designing IS in terms of a set of BB.
– Tools and common Vocabulary.
– Recommended standards and compliant products to implement BB.
– Contains a Baseline set of resources for reuse.
– Systematic – “Codified common sense”
• Deliverables
– Formal products
– Contractually specified Charter
– Outputs from a project
– Contain many artifacts

12/28/2016 HiLCoE CS754 - SAC 78

 Architecture , …
• An Architecture is the fundamental
organization of something, embodied in:
– its components,
– their relationships to each other and the environment,
– and the principles governing its design and
evolution.
• Building blocks
– components that can be combined with other
building blocks to deliver architectures and
solutions.

12/28/2016 HiLCoE CS754 - SAC 79

 EA Framework Models
• Enterprise Architecture models
– Represent the enterprise's organization and structure;
– Provides enterprise view of the systems architecture as a whole;
– Facilitate communication between the business and IT stakeholders
– Represent the complex interactions between people, processes and
technology.

• A good enterprise model should

– Represent both the as-is and to-be views of the enterprise;
– Include both business-oriented views and technical views;

• The EAF should guide the processes concepts, tools, and technology used
within software projects.

12/28/2016 HiLCoE CS754 - SAC 80

 Reference Architectural Framework

 To define an architecture framework that facilitate the

development of architectures at enterprise, domain and
solution views by providing linkages with:
 EA patterns and guidelines
 Architecture repository
 Enterprise and Domain Solution portfolios
 Domain specific architectural patterns and solution patterns
 Solution Implementation projects
 To identify key deliverables of conceptual, logical and solution
architectures;
 To define templates that will be used for documenting
conceptual, logical and solution architecture.

12/28/2016 HiLCoE CS754 - SAC 81

 Example Reference Architectures, Cont’d…
• US Government Federal Enterprise Architecture (FEA) Reference
models and DoDAF
• Canadian Government Service Reference Model
• Australian Government Architecture (AGA) Reference Model
• Open Group SOA reference Architecture (generic)
• Enhanced telecom Operations Map (eTOM) reference model for
telecom
• Frameworks such as DOFAF, MODAF, and TOGAF are classified as
Implementation Frameworks and/or methodologies in combination
with a framework.
• Zachman Framework , EEAF and OTHERS …

12/28/2016 HiLCoE CS754 - SAC 82

 EA Frameworks

• Defacto Reference Architecture models

– The Open Group Architecture Framework - TOGAF

– Pragmatic EA Framework

– Zachman Framework

12/28/2016 HiLCoE CS754 - SAC 83

 Thank you,
for today.

12/28/2016 HiLCoE CS754 - SAC 84

 HiLCoE
School of Computer Science &Technology

CS754 - Software Architecture and Construction

Lecture – V
Enterprise Architecture
Autumn 2016

Nassir D. /PhD
Assoc. Professor (Software Engineering)
nassir@hilcoe.net
 Agenda

• Overview
• EA Framework models
– Pragmatic EA Framework
– The Open Group Architecture Framework – TOGAF
– Zachman Framework

• Assignment
• References

12/28/2016 HiLCoE CS754 - SAC 86

 TOGAF Origins
• Customer initiative
• Originally based on TAFIM (U.S. DoD - Technical Architecture Framework
for Information Management )
– Cross-Industry, Vendor & Technology Neutral
– 300+ member organisations worldwide
– It was first developed in 1995 by the Open Group Architecture Forum
• A generic framework, not an architecture
• For developing architectures to meet different business needs
• Not a “one-size-fits-all” architecture
• Used in major IT projects worldwide
– IBM, HP, Sun, Infosys, Academics, practitioners, …..
– Industry Consortium: Not-for-profit operations
• Training and certification
– EACoE

12/28/2016 HiLCoE CS754 - SAC 87

 TOGAF at a glance
• An effective, industry standard framework and method
for enterprise architecture;
• Complementary to, not competing with, other enterprise
frameworks;
• A repository of best practice – “Demystifies” architecture
development;
• A framework and method for achieving the
“Boundaryless Information Flow” vision;
• provides a mechanism for approaching architecture from
business architecture and then to technology
architecture.
• Access to integrated information to support business
process improvements
12/28/2016 HiLCoE CS754 - SAC 88
 TOGAF Architecture levels

• Strategic Architecture
– Provide direction and guidelines to DA
– is done in alignment with a business strategy
– is to address business objectives, goals, etc.
– should be done to identify segments or business subject areas
• Segment (or Domain) Architecture
– Business architecture that growth to EA
– Ex. SOBA addresses business agility through identification of key business
subject areas (business capabilities),
• Capability Architecture
– Solution architecture at all levels;
– The ”right granularity” of capabilities is important in that it affects the ability
of change and business service reuse.
– Ex. The risky SOA initiative is where SOA is left to pure solution
implementation at individual projects level - i.e. technology solution project
centric SOA. / Not strategic

12/28/2016 HiLCoE CS754 - SAC 89

The TOGAF Architecture Development Method (ADM)

– The preliminary phase

– Architecture Requirements Management
o Phase A: The Architecture Vision
o Phase B: The Business Architecture
o Phase C: The ISA
o Phase D: The Technology Architecture
o Phase E: Opportunities and Solutions
o Phase F: Migration Planning
o Phase G: Implementation Governance
o Phase H: Architecture Change Management

12/28/2016 HiLCoE CS754 - SAC 90

 Architecture Process (TOGAF ADM)
Preliminary Phase Define principles,
Framework and Adapt framework
Principles

A: Define scope; create vision; obtain approvals

H: Establish for procedures for managing change to
new architecture A.
Architecture
Vision
H. B. B: Develop a business
Architecture
Change
Business architecture
Architecture
Management

G: Provide architectural oversight of the

implementation
C. C: Develop data and
G.
Requirements Information application
Implementation
Governance Management Systems architecture
Architecture

F: Prioritize, select major work F. D. D: Develop a technology

packages, develop migration plan Migration Technology architecture
Planning E. Architecture
Opportunities
and
Solutions
E: Check point suitability for implementation

Enterprise Continuum
TOGAF Resource Base Solution Architecture
Continuum Continuum

12/28/2016 HiLCoE CS754 - SAC 91

 Preliminary Phase
• This phase prepares the organisation for
undertaking successful enterprise architecture
projects
– Understand business environment
– High level management commitment
– Agreement on scope
– Establish principles
– Establish governance structure
– Agree method to be adopted
• It is Meta-Architecture
12/28/2016 HiLCoE CS754 - SAC 92
 Requirements Management

Ensure that every stage of a EA project is

based on and validates business
requirements.
– Architects need to be enterprising to innovate
new value;
– Constantly plan for adaptiveness to change

12/28/2016 HiLCoE CS754 - SAC 93

 TOGAF Architecture Vision

• Initiates one iteration of the architecture process

– Sets scope, constraints, expectations
– Required at the start of every architecture cycle

• Create the Architecture Vision

• Validates business context
• Creates Statement of Architecture work

12/28/2016 HiLCoE CS754 - SAC 94

 Architecture Vision
• The architectural vision conveys the direction we want the architecture to go in
order to support the system being built.
• May be documented in the SAD as “goals and constraints”
• The vision will:
– Be high level and not go into detailed solutions.
– Be tied to overall system requirements
– Identify architectural goals like
• Layering strategies
• Mobility
• Maintainability
– Identify architectural strategies
• E.g use web services wherever possible; look at existing solutions first;
etc.
– Identify high level constraints that the architecture must adhere to.
• No strategic vision, no EA – rather than Tactical approach!

12/28/2016 HiLCoE CS754 - SAC 95

 Creating Architecture Vision

• Understand the problems the architecture is to

solve.
• Understand the general system requirements.
• Understand the constraints the architecture must
adhere to.
• Understand the principles inherited from the
Enterprise Architecture.
• Identify major architectural goals, constraints, and
principles.
12/28/2016 HiLCoE CS754 - SAC 96
 Ex - Service Oriented EA Development Roadmap
ADM is agnostic to architectural style Ex. Using SOA

This vision includes:

-EA Business vision
-EA Technology vision
-EA Service Delivery vision

12/28/2016 HiLCoE CS754 - SAC 97

 Review on EA …
• Enterprise Architecture …
– Lay out holistic view of a company's structure, personnel, technology and
business.

– Lay out the goals, policies, principles, standards and guidelines of the
enterprise.

– Describe an organization's present and future vision and objectives so that

they are consistent with its strategic direction.

– Helps in planning and improving for optimizing business by addressing its

critical components and their relationship (facilitates Application,
technology, systems alignments).

– Promotes and aligns IT initiatives throughout the enterprise

– Facilitates the alignment of enterprise applications, technology services

and systems with the enterprise business objectives.

12/28/2016 HiLCoE CS754 - SAC 98

 Enterprise Standards
 EA group defining standards for the whole enterprise like:
• Reference architecture
• Approved architectural patterns
• Approved design patterns
• Security standards (physical, digital, and information)
• Privacy standards
• Standards for how to network systems
• Databases and how they may be used
• Approved products and tools
• Maintenance and Support requirements
• Architectural style (Ex. SOAML) than structured, predefined views,
• Principe driven then technology/model driven and
• Reuse /SBB / than monolithic approach;

12/28/2016 HiLCoE CS754 - SAC 99

 Pragmatic EA Framework

Enterprise Cross Domain Architecture Publish

Use
Reuse Architecture
Conceptual Logical Solution
Architecture Architecture Architecture Repository
Context
(Enterprise
Architecture
Patterns and
Guidelines) Reuse
Domain Architecture

Use Solution
Conceptual Logical Solution Implementation
Architecture Architecture Architecture projects

Enterprise Solution Portfolio

Domain specific Domain Solution
Architecture & Portfolio
Solution Reuse
Solution Patterns Implementation Solution Solution
projects New solution set set
set

Domain Solution Portfolio

Context = Business, IT, Architecture Solution Solution
set set

Domain Solution Portfolio

Solution Solution
set set
12/28/2016 HiLCoE CS754 - SAC 100
 Domain Architecture

Domain

Business
Business Services
identification and Business
Process analysis

Domain Service Structure

If it is data-driven then the information model will Service Portfolio

/ Catalog
be more important than in case of feature-driven.
12/28/2016 HiLCoE CS754 - SAC 101
 Pragmatic EA approach
• Conceptual Architecture; Logical Architecture and Solution Architecture

Conceptual architecture sets the scope for the architecture work and
defines conceptual target state architecture (vision). It defines the road-map from current
state to the target state at a conceptual high level. This architecture must be validated and
approved by the stakeholders and sponsors in order to continue with the next architecture
phase (i.e. Logical Architecture)

The Logical Architecture work is based on the approved conceptual

architecture deliverables and defines detail architectural specifications that will be used by
the next solution architecture phase. This logical deliverables must be approved before the
solution architecture phase starts.

Solution Architecture provides detail descriptions of how the

capabilities/components defined and specified in the logical architecture are going to be
built, deployed and managed.

12/28/2016 HiLCoE CS754 - SAC 102

 Conceptual Architecture

• Drivers input
– New/changes to capabilities, Outstanding gaps/issues/pain points
Technical Objectives (e.g., Simplification),
– Identify the main drivers for this architecture work,
– Documented drivers.

• Alignment input
– Identify Existing business principles, IT Principles, standards and
guidelines.
– and understand the Principles, standards and guidelines that apply to
this architecture.

12/28/2016 HiLCoE CS754 - SAC 103

 Conceptual Architecture steps/deliverables

 Business Architecture
 Current state business architecture
 Develop and/or validate business strategy (i.e. conceptual target
state or vision)
 Identify Business capabilities that are new or to be enhanced
 Roadmap as to when the business capabilities are required to be
in place
 Document any non-functional requirements which may be raised
as a concern by the business stakeholder at this level – example is
performance or transaction integrity or security i.e. Drivers.

 Information Architecture
 Identify Information/data needed at the conceptual level to
support the conceptual target state

12/28/2016 HiLCoE CS754 - SAC 104

 Conceptual Architecture steps/deliverables

• Application/Services Architecture
 Current state application/service architecture related to the
current state business architecture captured earlier in the
business architecture.
 Identify IT Capabilities and their inter-dependencies
 Develop target state architecture based on the identified IT
capabilities
 Buy-versus-build analysis
 Roadmap as to when the IT capabilities are delivered in
applications/services based on the business architecture
roadmap defined earlier.

12/28/2016 HiLCoE CS754 - SAC 105

 Conceptual Architecture steps/deliverables

• Technology Architecture
 Describe the relevant Current state for technologies;
 Identify integration points – conceptual description of the
technology requirement associated with the identified IT
capabilities;
 Define conceptual target state technologies that
correspond with the application/services target state
defined earlier;
 Technology roadmap based on the application/services
roadmap developed earlier.

12/28/2016 HiLCoE CS754 - SAC 106

 Logical Architecture steps/deliverables
 Business Architecture
 Business processes and service identification – process and entity
services. Define and document the details of the business processes
and/or entity services that are in the scope of this work.
 Document all other dependent business processes including the manual
processes.
 Document details on non-functional requirements which may be raised
as a concern by the business stakeholder – example is performance or
transaction integrity or security.
 Make sure that the business capabilities roadmap developed at the
conceptual architecture is still valid – if not, update the roadmap with
detail descriptions.

 Information Architecture
 Define the details of Canonical information/data exchange model and
schema (i.e. common data types) for the scope of the work. Define the
details of data types to be used for the business processes and/or entity
services in the scope of this work.

12/28/2016 HiLCoE CS754 - SAC 107

 Logical Architecture steps/deliverables

 Application/Service Architecture
 Identify existing or new applications (i.e. reuse of existing
enterprise applications or buying new packaged applications). Buy-
versus-build analysis must have been done in the conceptual
architecture phase if new vendor packaged applications are
recommended.
 Define and document the details of existing or new business
services to support the business process done in logical business
architecture
 Define interfaces and dependencies at a logical level.
 Define how new and/or packaged applications will be integrated
by specifying the integration technologies and approaches (this
should use the integration patterns from patterns repository).
 Make sure that the Application/Services roadmap developed at
the conceptual architecture is still valid – if not, update the
roadmap with detail descriptions.

12/28/2016 HiLCoE CS754 - SAC 108

 Logical Architecture steps/deliverables

 Technology Architecture
 Identify key technology components/building blocks and describe
how they support the IT capabilities identified in the conceptual
architecture phase. That is, infrastructure components/services
required to support the business/IT capabilities
 Define in detail the required interface and integration technologies
 Develop security architecture and identify (define) required
security technologies or approaches.
 Make sure that the technology roadmap developed at the
conceptual architecture is still valid – if not, update the roadmap
with detail descriptions.

12/28/2016 HiLCoE CS754 - SAC 109

 Example – Enterprise wide Validation Roadmap

12/28/2016 HiLCoE CS754 - SAC 110

 Solution Architecture steps/deliverables

 Business
 Describe how business processes and services will be
implemented – for example, Service Orchestration

 Information
 Services interfaces WSDL and SOAP defined based on the
canonical data exchange model (i.e. common data types)

12/28/2016 HiLCoE CS754 - SAC 111

 Solution Architecture steps/deliverables

 Application example services

 Describe in detail how services specified in the logical architecture
phase are going to be implemented and/or reused.
 If the conceptual and logical architecture phases have specified
new packaged applications to be purchased based on buy-vs-build
analysis, describe the details on how these packaged applications
are going to be used and integrated following the guidance
defined in the logical architecture phase.

12/28/2016 HiLCoE CS754 - SAC 112

 Solution Architecture steps/deliverables

• Technology
 Describe in detail how the infrastructure services specified in the logical
architecture phase will be built and/or existing services reused.
 Describe in detail how the specified platforms/technology
components/products will be configured and deployed
 Describe in detail how the performance, scalability, load-balancing,
disaster-recovery, management and monitoring concerns are addressed

12/28/2016 HiLCoE CS754 - SAC 113

 Solution Architecture
Solution Architecture

• Business process and activity model

• Business data concept (information) model

Drive

• Application/Service Architecture
• Data Architecture

Drive

SOA Infrastructure Architecture

Input

Input

Develop Implementation Plan

(both Services and infrastructure)

Input

Prioritize Implementation Projects

12/28/2016 HiLCoE CS754 - SAC 114

 SOE Solution Implementation (Service Delivery layer)

SOE Solution Implementation (Service Delivery Layer)

Service Design and Implementation Infrastructure Implementation

Test Deploy Manage

Publish Discover

Service Repository
or Registry

12/28/2016 HiLCoE CS754 - SAC 115

 Review on EA, Cont’d…

• The EA discipline defines and maintains

– Architecture models and governance;
– Effectively co-ordinate semi-autonomous groups towards common
business and/or IT goals. Ex. Government agencies

• EA includes four architectures aspects

– Business Architecture,
– Information Architecture,
– Information Systems Architecture (Data and Application
Architectures)’
– Technology Architecture.

• But EA does not provide a direct solution implementation.

– EA must accommodate an architectural style for solution
implementation.

12/28/2016 HiLCoE CS754 - SAC 116

 Reading Assignment

Zachman Enterprise Framework features and

challenges

12/28/2016 HiLCoE CS754 - SAC 117

 Deliverable Assignment
• Write-up Assignment (either Q1 or Q2) using a case study on
 Q1. Intra & Inter-enterprise Interoperability Why and How?
 DaaS
 SaaS
 PaaS
 Q2. EA Governance
 Business
 IT
 ESB/Service
• A group of THREE students.
 Deadline for submission (printedcopy@the reception and email)
 Wednesday January 04th , 2017; nassir@hilcoe.net Note: Presentation will be announced

12/28/2016 HiLCoE CS754 - SAC 118

 References
• Bass, L, Clements, P., and Kazman, R.: Software Architecture in Practice, second
edition, SEI Series in Software Engineering, Pearson Education, Inc., Addison-
Wesley, 2003.
• Bosch, J.: Design and Use of Software Architectures: Adopting and Evolving a
Product-Line Approach, Addison-Wesley, 2000.
• Clements, P., Kazman, R., and Klein, M.: Evaluating Software Architecture: Methods
and Case Studies, SEI Series in Software Engineering, Addison-Wesley, 2002.
• Hohmann, Luck: Beyond Software Architecture: Creating and Sustaining Winning
Solutions, Pearson Education, Inc., Addison-Wesley, 2003.
• M. Jazayeri, A. Ran, and F. van der Linden: “Software Architecture for Product
Families. Principles and Practice”, , Addison-Wesley (2000)
• Frank Buschmann, Régine Meunier, Hans Rohnert, Peter Sommerlad, and Michael
Stahl, Pattern-Oriented Software Architecture - A System of Patterns, Wiley and
Sons, 1996.
• TOGAF Version 9 The Open Group Architecture Framework (TOGAF), ISBN: 978-90-
8753-230-7, Document Number: G091, Published by The Open Group (2009).
www.opengroup.org/bookstore/catalog/g091.htm
• Daniel Minoli, Enterprise Architecture A to Z, CRC press Taylor , Francis Group
NY(2008).
12/28/2016 HiLCoE CS754 - SAC 119
 References
N. Dino, et al: (2012) A New Way of Architecting Enterprise. MEDES
Management of Emergent Digital EcoSystems, ISBN 978-1-4503-1755-
9 publisher ACM New York, NY, USA.
http://sigappfr.acm.org/MEDES/12/http://sigappfr.acm.org/MEDES/12
/
N. Dino, et al: (2012) Business and IT Strategic Alignment applying
SOEA Framework. International Refereed Journal of Engineering and
Science (IRJES); ISSN (Online) 2319-183X, ISSN (Print) 2319-1821,
Volume 1, Issue 4, PP.46-51. www.irjes.com.
• John Fronckowiak, SOA Best practices & Design patterns: key to
successful soa implementation, by Oracle Corp (2009).
• Mary Shaw, Paul Clements, The Golden Age of Software
Architecture, IEEE SOFTWARE (2006).
• A. Zachman (1996), “The Framework for Enterprise Architecture:
Background, Description and Utility,” Zachman International.

12/28/2016 HiLCoE CS754 - SAC 120

 Thank you.

12/28/2016 HiLCoE CS754 - SAC 121