Summary Lecture of: 22.10 - TU Dresdenst.inf.tu-dresden.de/files/teaching/ws13/fps13/Summary... · 2013. 11. 14. · Future-Proof Software-Systems: Summary 22.10.2013 Summary 22.10.2013

Future-Proof Software-Systems: Summary

Condensed Summary of Previous Lectures

Summary Lecture of:

22.10.2013(9 slides)

I prefer dialog - rather than monolog:Please feel free to ask questions at any time

Future-Proof Software-Systems: Preferred Interaction Style

My Preferred Interaction Style

Summary 22.10.2013

Copyright Frank J. Furrer 2013 2

I am available for additional questions or discussionsafter each lecture

Lecture Website:http://st.inf.tu-dresden.de/teaching/fps13

Future-Proof Software-Systems: Summary 22.10.2013

Summary 22.10.2013

Software is one of the most important key success factorsfor today‘s and tomorrow‘s products and services

http://myauto24.blogspot.ch/2013/

… etc


Therefore we need agile, affordable, dependable software – what we call

„future-proof software-systems“

We – as software engineers – have a high responsibility to produce

„good“ software

Software production has mutated from an art to an industrial activity –

guided by well-founded architecture principles


Summary 22.10.2013

“It is not the strongest of the species that survives,nor the most intelligent that survives.It is the one that is the most adaptable to change.”

Charles Darwin: The Origin of Species (1859)

Software must not only be affordable and dependable – itmust also play its role as a key competitive factor


Charles Darwin: The Origin of Species (1859)

Future-proof software must allow to implementnew requirements in a short time, withreasonable cost and with adequate quality

Key SW-property: Agility


Summary 22.10.2013

„The three devils of systems engineering are:

Complexity,

Change,

Uncertainty”Anonymous



Summary 22.10.2013

Definition:

A future-proof software-system is a structure

that enables the management

of complexity, change and uncertainty

Parts of the systemand their relationsships

Activity: Steering thedevelopment & evolution


of complexity, change and uncertainty

with the least effort, with acceptable risk and with specified quality properties

Providing the best valuefor the resources ‘money‘

and ‘time-to-market‘

Having an adequate probability forundesired effects and consequences

Assuring the desired properties(„Fit for Purpose“)


Summary 22.10.2013

Agility

Future-Proof Software-Systems Coordinates

System Stateat time t Loss of agility


BusinessValue

System Stateat time tn

at time tn+T

System Stateat time tn+kT

Loss of agility


Summary 22.10.2013

Future-ProofSoftware System

(FPSS))Structure Architecture


(FPSS))

Manifesto of Future-Proof Software-Systems:

1. „Fit-for-Future“ of an IT-system depends onits structure and is determined by its

architecture

2. The agility must continuously be improved

3. Future-proof software-systems need strongarchitects and a farsighted management


Summary 22.10.2013

Safety

Security

Agility

Availability

etc.

syste

mor

an

exte

nsio

n Fm

• Functionality and architectureare (nearly) orthogonal

• Architectures differ by theirquality properties

• Architecture assessment &evaluation optimum


Safety

Security

Agility

Availability

etc.

Fu

ncti

on

ality

of

asyste

m

F1

F2

F5F4F3

A1

System & software architecture

AnA4 A5A3A2 A9

ArchitecturePrinciples

enforce


Summary 22.10.2013

Future-ProofSoftware-System

Structure

enables

Architectureforms

Future-ProofSoftware-Systems

Engineer


http://berxblog.blogspot.ch

Engineer

ArchitecturePrincipleArchitecture

PrincipleArchitecturePrinciple

Part 1, Slide 90


Condensed Summary of Previous Lectures

Summary Lecture of:

5.11.2013(11 slides)


Architecture Erosion

http://thoreau.colonial.net/Students/EricksonHoyt/erosionSummary 5.11.2013

Sources of Architecture Erosion:

• technological change

• progress in software-engineering

• new laws & regulations

• accumulation of mistakes + shortcuts

• sloppy system extensions

… and some more


Quality Properties:• Business Value

•Agility• Security

• Availability• etc.

Time

Continuouslyimprove thearchitecture

… and some more


Architecture Viewswww.123rf.com

Sys Mgmt

Security

Safety

etc.

Summary 5.11.2013


Stakeholders

etc.

Architecture documentation:

Documentation Framework

Views:

Overarching documentation


How much Architecture is enough?

http

://w

ww

.skyscra

pern

ew

s.o

rgh

ttp:/

/w

ww

.dim

en

sio

nsin

fo.c

om

/dim

en

sio

ns-o

f-a-d

og-h

ou

se

Summary 5.11.2013


Architecture work (% total €)

Project effort (€)

10 %

100 %

htt

p:/

/w

ww

.dim

en

sio

nsin

fo.c

om

/dim

en

sio

ns

G. Fairbanks / ISBN 978-0-9846181-0-1


Legacy Softwareh

ttp:/

/w

ww

.nzz.c

h/aktu

ell/

sta

rtseite

/h

inte

rtuerc

hen

htt

p:/

/w

ww

.123rf

.com

/ph

oto

_4985178_o

ld-r

usti

ng-s

cra

pped-c

ars

-in

-a-j

un

k-y

ard

.htm

l

Summary 5.11.2013

Summary 5.11.2013


http

://w

ww

.nzz.c

h/aktu

ell/

sta

rtseite

/h

inte

rtuerc

hen

-der-b

an

ken

-bei-d

en

-gold

-etf-1

.5956390

htt

p:/

/w

ww

.123rf

.com

/ph

oto

_4985178_o

ld

Liability Asset

good:

• invaluable implicit knowledge of thedomain and the business processes

• stable operation (mature)

• good solutions/algorithms

• often: suprisingly good code

bad:• eroded architecture• badly or not documented• obsolete technology (HW & SW)• lost knowledge (people left)• difficult integration context

Summary 5.11.2013


Architecture Principle A1:Architecture Layer Isolation

Isolate the architecture layers via standardized, technology-independent and product-independent mechanisms.

Never implement technical functionality in the applications.

A1

Summary 5.11.2013


Never implement technical functionality in the applications.

Justification: Any reliance on specific technologies or productsgenerates dependencies which (massively) reduce agility.

Architecture layers should be able to evolve in their own pace withoutimpacting the other layers by force

IndustryStandards


ApplicationsArchitecture (Functionality)

BusinessArchitecture (Business Processes)

InformationArchitecture (Information & Data)

Orc

hestr

ati

on

Tech

nolo

gy

Serv

ices

Technology& ProductIndependence


TechnicalArchitecture (Technical Infrastructure)

IntegrationArchitecture (Cooperation Mechanisms)

Bu

sin

ess

Pro

cess

Tech

nolo

gy

Serv

ices

Tech

nolo

gy

Serv

ices

Tech

nolo

gy

Serv

ices


Architecture Principle A2:

Partitioning, Encapsulation & Coupling

1. Partition the functionality and data into encapsulation unitsaccording to their coherence and cohesion (thus minimizing

dependencies)

2. Isolate the encapsulation units by strictly hiding any internaldetails. Allow access to functionality and data only through stable,

A2Summary 5.11.2013


details. Allow access to functionality and data only through stable,well specified interfaces governed by contracts

3. Minimize the impact of dependencies between the encapsulationunits by using adequate coupling mechanisms

Justification: These 3 principles minimize the number and theimpact of dependencies. The resulting system therefore offers theleast resistance to change, because any change affects the smallestpossible number of system elements. A low resistance to changecorresponds to high agility.


FF

F

F

F

F

F

FF

F

F

FF

F

F

F

F

FF

F

F

F

F

F

FF

IF

IF

IF

IF

IF

IF

IF

IF

IF

IF

IF

Summary 5.11.2013


FFF

F

FF

FF

F

FF

FFF

F F

FF

FF

F

IF

IF

IF

IF

IF

IF

IFIFIFIF

IF IF

IF

IF

IF IF

IF

IF

IFIFIF

Partition,encapsulate,and couple as loosely as possbile


Summary 5.11.2013 Q: Boundary between Architecture and Design?

System

System-of-Systems

Arc

hit

ectu

re

Relationsship:Contract


Module

ComponentApplication

System

TechnologyDependence

Desig

n

Part: Container forfunctionality & data

Part: EJB,Java Class

Relationsship:Web-Service


Summary 5.11.2013

Q: Granularity ofthe EncapsulationUnits?

System-of-Systems

System

loose


Application

Component

Module

Encapsulation

Coupli

ng

tight


Summary 5.11.2013

Continuation:

Architecture Principle A2:

Partitioning, Encapsulation & Coupling

A2


Part 2, Slide 41

How do we:

• partition

• encapsulate

• couple

a system?

Documents

Summary Lecture of: 22.10 - TU Dresdenst.inf.tu-dresden.de/files/teaching/ws13/fps13/Summary... · 2013. 11. 14. · Future-Proof Software-Systems: Summary 22.10.2013 Summary 22.10.2013