FPSS WS1415 Part1 V08 20141112 - TU...

Future-Proof Software-Systems

1Dr. Frank J. Furrer - WS 2014/15

Future-Proof Software-Systems(Zukunftsfähige Software-Systeme)

Frank J. FurrerDr. sc. techn. ETH-Zürich

TU Dresden WS 2014/2015

Part 1Part 1

V0.7 / 27.10.2014

Future-Proof Software-Systems: Interaction Style


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

I am available for additional questions or discussionsafter each lecture

My Preferred Interaction Style:

… or at any time via e-mail:[email protected]

Future-Proof Software-Systems: Lecture Summary


Lecture Summary

Content:

1. What future-proof software-systems are

2. Why future-proof software-systems are key successfactors for today‘s and tomorrow‘s products and

services

3. Which body of knowledge exists for future-proofsoftware-systems

4. How the context for future-proof software-systemsdevelopment & evolution should look

Future-Proof Software-Systems: Lecture Summary


Lecture Summary

Objectives:

1. Understand „future-proof software systems“, theirstructure, properties and their quality attributes

2. Learn the principles, concepts and methods to design,implement and evolve future-proof software systems

3. Know the skills which are needed by a „future-proofsoftware-systems engineer“

4. Accept the (economical, ecological, societal) businesscase for future-proof software systems

Future-Proof Software-Systems(Zukunftsfähige Software-Systeme)

Frank J. FurrerDr. sc. techn. ETH-Zürich

TU Dresden WS 2014/2015

ExamsExams

Copyright Frank J. Furrer 2013 6

Future-Proof Software-Systems: Exams

Exams:

[Official Text]:

Participants can receive a mark via an oralexam or a not graded certificate of

attendance.

http

://w

ww

.resu

mew

ritingserv

ice.b

iz



Oral Exam

Participants can receive a mark via an oral exam(3 credits ECTS)

Please check your exam regulations which type ofcredit (mark/certificate) you need. If you areinterested in an examination date, please write anemail to [email protected] (Secretary ofthe Chair of Software Technology). She willschedule the exams.

DO NOT CONTACT ME DIRECTLY. THANKS



Certificate of Attendance

Participants can receive a not graded certificateof attendance.

(NO credits ECTS)

If you are interested in a not graded certificate ofattendance, please write an email [email protected] (Secretary of theChair of Software Technology). She will arrangethe certificate.

DO NOT CONTACT ME DIRECTLY. THANKS.

For the not graded certificate you need to sign theattendance list provided during each lecture.



#

AErkennung derZusammenhängedes Prüfungs-gebietes

(Understanding)

BEinordnung speziellerFragestellungen in dieZusammenhänge desPrüfungsgebietes

(Reasoning)

CGrundlagenwissen gemässdem Stand des Studiums

(Knowledge)

1. What is a goodfuture-proofsoftware-architecture?

Why?

Which are the contra-productive behaviors ofan IT architect?

Which is the most importantskill of a successful ITarchitect?

Why?

2. Why are architectureprinciples soimportant?

Have architectureprinciples to be strictlyenforced in eachsituation and in eachproject?

Which is the resistanceencountered by an ITarchitect while trying toenforce architecture-principles?

Sample Exam Questions



Exam Procedure (15 minutes)

1. Greeting and identification (Examiner,

examination assistant, and student)

2. Question 1: from Group A

3. Question 2: from Group B

4. Question 3: from Group C

5. If time left: additional questions

6. Short Break

7. Feedback



#

AErkennung derZusammenhängedes Prüfungs-gebietes

(Understanding)

BEinordnung speziellerFragestellungen in dieZusammenhänge desPrüfungsgebietes

(Reasoning)

CGrundlagenwissen gemässdem Stand des Studiums

(Knowledge)

1. What is a goodfuture-proofsoftware-architecture?

Why?

Which are the contra-productive behaviors ofan IT architect?

Which is the most importantskill of a successful ITarchitect?

Why?

2. Why are architectureprinciples soimportant?

Have architectureprinciples to be strictlyenforced in eachsituation and in eachproject?

Which is the resistanceencountered by an ITarchitect while trying toenforce architecture-principles?

Sample Exam Questions



Questions

Future-Proof Software-Systems: Content


Future-Proof Software-Systems:

Content

Future-Proof Software-Systems: Lecture Structure


BusinessCase

justifies

Future-ProofSoftware-System

QualityProperties

definedby

Structure

enables

Architectureforms

guide

control

DevelopmentProcess

builds

ArchitecturePrinciples

enforce

Future-ProofSoftware-Systems

Engineer

leads

appliesMetrics

quantify

uses

Conceptual Context:(Lecture Map)

WorkingEnvironment

is embedded in



Content

Part 1: Introduction & Motivation

Part 2: Architecture Principles

Part 3: Some Specific Architecture Topics

Part 4: The Role, Personality and Context of the „Future-Proof Software-System Architect“

Context & Motivation Future-Proof Software-Systems Business Value Agility Resilience Managed Evolution Business Value & Architecture Erosion, Technical Debt Key Importance of Architecture Industrial Architecture




Context & Motivation

Future-Proof Software-Systems: Context


htt

p:/

/web

.kyo

to-i

net

.or.

jp/p

eop

le/s

-oga

/old

com

/in

de

x.h

tml UNIVAC 120 (1953)

Decimal storage: 120 digits„Program“: Wired Panel

htt

p:/

/ww

w.m

oto

rbas

e.co

m/p

ictu

re/b

y-id

/43

79

41

61

1

Land Rover 1953: SLOCs = 0(SLOC = Source Lines of Code)

CRAY Titan (2013)

http

://ww

w.ew

eek.com

/servers/slidesh

ow

s

Data storage: 710 Terabytes RAM30 Petabytes Disk

Computing Power: 17,59 Petaflops

Mercedes S-Class 2013: SLOCs 100 Million

http

://myau

to2

4.b

logsp

ot.ch

/20

13

/

+ 60 years



Software has evolved from a system building block

to a major industrial asset

with a large financial investment

and tremendous impact on the business opportunities

Many software modules have a long life span.

They need to be maintained and evolved over manyyears/decades

Therefore: Our software needs to be future-proof

(Definition follows later)



Example: VW Phaeton(Automotive Software)

Electrical/Electronic Architecture

http://delphi.com/manufacturers/auto/ee/

A modern luxury car contains70 … 100 electronic controlunits (= ECU‘s) in the form ofnetworked microprocessors

http://www.cars2review.com/2013-volkswagen-pheaton/

A modern luxury car iscontrolled by approx. 100Million source lines of code(SLOC‘s)

2014: 90% of the innovationin cars is due to software



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

Software determines (to a large extent):

Functionality

Quality Properties, such as safety, security,availability, integrity, performance etc.

Competitiveness

Revenue generation

Innovation capacity

Intellectual Property Rights ( IPR protection)

http

://ww

w.ch

ange-m

anagem

ent.co

m



… a little bit of history:

The first computer program: Lady Ada Lovelace (1843)

„Computation of Bernoulli Numbers“

(based on the work of Charles Babbage „The Analytical Engine“)

http://axsoris.com

2014:

The world software market exceeded $500 billion

(not including embedded software!)

http://www.itp.net

… Software production has become a major industry



Programs Functionality

Historical Context:

2010

2000

1990

1960

1950

Object Technology Systems Partitioning, Encapsulation

Component Systems Re-Use

Service-Oriented Systems Sustainability

Systems-of-Systems Interoperability



Technical Context:

1960

TechnicalInfrastructure

ApplicationSoftware

1980


ApplicationSoftware

InfrastructureServices

2000


ApplicationSoftware


CommoditiesSourcing

2020


ApplicationSoftware


CommoditiesSourcing



very high

Size/Complexity

low

Criticalityvery strong

weak

Rate of Change

slow

very fast

Range Context:



very high

Size/Complexity

low


weak

Rate of Change

slow

very fast

Example:Mobile Phone Software



very high

Size/Complexity

low


weak

Rate of Change

slow

very fast

Example:Aeroplane ControlSoftware



very high

Size/Complexity

low


weak

Rate of Change

slow

very fast

Example:Global BankingSoftware



Software-Systems: Impact Factors

„The three devils of systems engineering are:

Complexity,

Change,

Uncertainty”Anonymous

What do they do to our software?

How can we fight them?



Complexity

“Complexity is that property of an IT-system which makes it difficult

to formulate its overall behaviour, even when given complete

information about its parts and their relationships“



Change

“Continuous – sometimes disruptive – change force relentless

adaptation of the system to new requirements, to changes in the

environment and to technological progress“



Uncertainty

“Uncertainty – both during development and during operation –

forces weakly founded decisions with possibly far-reaching

consequences“

?

?

?

?? ?

? ?

? ?



Complexity

Change

Uncertainty

How can we successfully fight them?

… by using principles, methods,

metrics, strategies and processes for

future-proof software-systems

Future-Proof Software-Systems: ???



Future-Proof Software-Systems

Future-Proof Software-Systems: Definition


Definition:

A future-proof software-system is a structure

that enables the management

of complexity, change and uncertainty

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

http

://ju

liecole

man

.org



Definition:





Parts of the systemand their relationsships

Architecture

Activity: Steering thedevelopment & evolution

Strategy

Best value for theparameters ‘money‘ and

‘time-to-market‘ Agility

Acceptable probabilityfor undesired effectsand consequences Resilience

Assuring the desirednon-functional properties

„Fit for Purpose“



Future-Proof Software-Systems:Primary Characteristics

Definition:





Agility Resilience

Business Value

Domain-specificQuality Properties



Primary Characteristics:

Business Value

Agility

Resilience

Secondary Characteristics:

Non-functional properties:

o Reusability

o Hardware Resource Consumption

o Adherence to industry-standards

o etc.

What are the characteristics of Future-Proof Software-Systems?

«as good asnecessary»

«continuousimprovement»




Business Value

Agility

Resilience

What are the characteristics of Future-Proof Software-Systems?

Definition

Metric

Example

Importance



Metric: Quantitative measurement of a product or a process attribute

Metric Definition

Future-ProofSoftware-System

QualityProperties

definedby

Metrics

quantify

1) Metrics are indispensable for the

management of future-proof software-

systems („you cannot control what

you cannot measure“)

2) Metrics are expensive. You need a

very clear purpose and great staying

power

Future-Proof Software-Systems: Business Value



Business Value



Business Value: Definition

Business Value (of a software development) =

The opportunity to gain an advantage for the business

• Financial advantage (earnings), but also:

• Cost avoidance

• Competitive advantage (innovative functionality),

• Compliance to laws and regulations,

• Process improvements

• etc.

htt

p:/

/blo

g.e

nfo

cu

ssolu

tion

s.c

om



Metric: NPV (Net Present Value)

Business Value: Metric

NPV = Net Present Value(€)I = Investment(€)i = Yearly interest rate (%)n = year (n=0: Project start)

(1 + i)n

Benefityear-nNPV = - I

n



Business Value: Example

Business Value = Net Present Value (NPV)

Earnings: Year1 Year2 Year3 Year5 Year6240‘000 € 270‘000 € 230‘000 € 280‘000 € 300‘000 €

htt

p:/

/w

ww

.eco-w

ay.c

h/?p=10846

Investment:

- 860‘000.- €

(1+0.8)-1

1.08(1+0.8)-2

1.17(1+0.8)-3

1.26(1+0.8)-4

1.36(1+0.8)-5

1.478 %/year:

NPV = +165‘000 €

+ 222‘000 €+ 230‘000 €+ 182‘000 €+ 205‘000 €+ 186‘000 €+ 1‘025‘000 €



Business Value: Importance

Why is the business value of asoftware development important?

(Most) development activities must have a positive NPV,i.e. the activity should generate more income than cost

The calculated NPV is an important decision metric(GO/NOGO for a project)

The NPVs of projects are key financial planning data

Future-Proof Software-Systems: Agility



Agility



Agility: Definition

Agility =

The capability to develop and introduce

new functionality with:

• short time-to-market

• reasonable development cost

Important note: This capability is a property of an organization,

but is heavily based on a good, evolvable structure of the system

htt

p:/

/gia

on

them

ove.c

om



Agility: Metric

Metric Idea: Agility ~ Size2/(TtM*DevC)

Functionality with:

• short time-to-market

• reasonable development cost

Size

TtM

DevC



Agility: Metric

Project Start Project End

TtM (Time-to-Market)Unit: days (d)

Project Start Project End

DevC (Development Cost)

WarrantyPeriod

Unit: k€

TtMi DevCi

(Sizei)2

Unit: #UCP2/(days*k€)

Amount of functionality:Functional Size

Size Unit: #UCP or #FP



Agility: Example

Project Size(#UCP)

TtMi(days)

DevCi(k€)

End Date

P1 1’200 900 5’600 Jan 2012

P2 650 645 2’566 Jan 2012

P3 4’400 5’280 27’270 March 2012

P4 980 620 5’400 April 2012

P5 11’250 6’600 75’600 April 2012

P6 2’300 1’900 13’900 June 2012

P7 800 390 6’200 August 2012

P8 1’850 1’250 13’200 August 2012

etc. … … … …

AgilityTtMi DevCi

(Sizei)2

Unit: #UCP2/(days*k€)

availability data

measurementperiod

CREDIT SUISSE values:

~ 4.2 k€/UCP

~ 0.8 days/UCP

[Murer/Bonati/Furrer

ISBN 978-3-642-01632-5]



Agility: Importance

Why is agility so important?

time

Time to market

Reqs

Time to market

Time to market

we

Competitor A

Competitor B

time

Development Cost

Reqs

Development Cost

Development Cost

we

Competitor A

Competitor B



Agility: Importance


“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)

Today: «most adaptable to change»applies to software-systems and thecompanies which live from them

Agility impacts every project

Low agility: (all) projects are late and expensive

= high resistance to change bad!

High agility: (all) projects are in time and cost-efficient

= low resistance to change good!

High agility allows to use the company resources moreefficient

Agility is an important competitive market factor



Agility: Importance


Future-Proof Software-Systems: Resilience



Resilience

http

://fc

w.c

om

/artic

les/2013/07/08/execte

ch

-opera

tion

al-re

silie

nce.a

spx



Why resilience as a primary characteristicof future-proof software-systems?

htt

p:/

/bookro

ar.

blo

gspot.

ch

/2012/05/m

ost-

dan

gero

us-s

nakes-i

n-w

orl

d.h

tml

The world has become a dangerous place for software The world has become a dangerous place for software



Resilience: Definition

Resilience is the capability of a system with specific characteristics

before, during and after a disruption

to absorb the disruption, recover to an acceptable level of performance,

and sustain that level for an acceptable period of time

http://www.incose.org/practice/techactivities/wg/rswg/

Incident System& Environment

Before – Allows anticipation and corrective action to be considered During – How the system survives the impact of the disruption After – How the system recovers from the disruption





Impact

http://www.403wg.afrc.af.milDisruption




Example: Nucelar Power Plant

Terrorist

Hacker

Earthquake

Impact: None

Impact: Shutdown

Impact:TemporaryShutdown

http://www.cleanenergyinsight.org/energy-insights

DisruptiveIncident

Result (Impact)



Environment

SoftwareSystem

Error

htt

ps:/

/sou

ndclo

ud.c

om

Crash

t

Degraded operation

t

t

Malfunction

htt

p:/

/kan

to.s

trip

es.c

om





2010 2010

t

Complexity

t

Tractability

System

Safety Case

Disruptive Incidents1. Xxx2. Yyy3. Zzz

predictpredict adjustadjust

System

Incid

ent

?

ResilientSystem




Example: Immune System

http://ageless-society.com

2n

dlin

eofdefe

nse:

Un

specific

defe

nse

3rd

lin

eof

defe

nse:

Specific

defe

nse

4th

lin

eof

defe

nse:

Learn

ing/A

dapta

tion

1stlin

eofdefe

nse:

Ph

ysic

albarr

ier

adjust



Resilience: Definition The four cornerstones of resilience

responding[actual]

knowingwhat to do

Holln

agel,

2011,

ISB

N978-1

-4724-2

074-9

monitoring[critical]

knowingwhat to look

for

learning[factual]

knowingwhat hashappened

anticipating[potential]

knowingwhat toexpect

t

before during after

adjust

adjust



Resilience: Metric


Impact

Damage Potentialof the Incident:

• catastrophic• critical• severe• marginal• negligible

Resulting Impact:

• catastrophic• critical• severe• marginal• negligible

Response ofthe system



Resilience: Metric

Damage Potential:• catastrophic: 5• critical: 4• severe: 3• marginal: 2• negligible: 1

Resulting Impact:

• catastrophic: 5• critical: 4• severe: 3• marginal: 2• negligible: 1

Incid

en

t

Impact

Response ofthe system

Resilience against 1 incident: 1 =ImpactPotential

(e.g. 2/3)

System resilience over a time period : =1n i



Resilience: Metric

1) Incident Damage Potential: 4 (critical)Resulting Impact: 2 (marginal)

Examples:

impact

damage potentiali = = 2/4 = 0.5

impact

damage potentiali = = 4/3 = 1.33

very good resiliencereduction!

2 ) Incident Damage Potential: 3 (severe)Resulting Impact: 4 (critical)

very low resilienceamplification!



Resilience: Metric Example: Banking System Incidents

Date Incident Damage

Potential

Damage Impact Remarks

4.1.13 DB2 Database

Crash

4 Operational blackout for 3

hrs (Recovery time)

2 2/4 = 0.5 Save & recovery procedures

worked well

6.1.13 Semnager Virus

Infection

3 Small number of customers

affected

2 2/3 = 0.67 Payment check procedures

worked well

21.2.13 Crash of

authentication

servers

3 Employees could not access

the IT system for 1 hour

1 1/3 = 0.34 Backup/recovery mechanisms

worked well

4.5.13 Fibre trunk cable

damaged (by

construction work)

4 No external communications

for 5 hours

3 3/4 = 0.75 Emergency repair in time

9.12.13 Illegal financial

transaction

executed (fault in

sanction filter)

3 Legal & compliance

consequences

3 3/3 = 1.0 Sanction filter update process

improved

impact

potential =

System resilience over 5 incidents: 5 =1n i = 0.65



Resilience: Importance

Why is resilience so important?

Software has an enormous impact on people and society:

• Functionality in all areas of life and work

• Tremendous business opportunities

• etc.

Software failures may have grave consequences:• Accidents in safety-critical systems

• Financial or reputation loss

• Legal & regulatory consequences

• Product liability cases

• etc.



Resilience: Importance

Disruptions:rate &severity

time

Dependenceon software

htt

p:/

/blo

g.q

ate

stl

ab.c

om

htt

p:/

/w

ww

.com

pu

terp

erf

orm

an

ce.c

o.u

k

Future-Proof Software-Systems: Summary


Today, software is a major, long-lived industrial asset

with a large financial investment,

a tremendous impact on the business opportunities,

and considerable risk

In order to get the most out of our software,

with acceptable risk and long-term viability,

we need adequate structures, methods and processes

we need future-proof software-systems

Summary (1/2)

Future-Proof Software-Systems: Summary


The characteristics of future-proof software systems are:

Summary (2/2)


Non-functional properties:o Reusability



o etc.




Business Value

Agility

Resilience

Future-Proof Software-Systems: References


References: Business Value

Reference

Theo J.W. Renkema :

The IT Value Quest – How to Capture the Business Value of IT-Based Infrastructure

John Wiley & Sons, Inc., Chichester, UK, 2000. ISBN 978-0-471-98817-0

Roger Gutbrod, Christian Wiele:

The Software Dilemma – Balancing Creativity and Control on the Path to Sustainable Software

Springer-Verlag, Heidelberg, 2012. ISBN 978-3-642-27235-6

Luke Hohmann:

Beyond Software Architecture – Creating and Sustaining Winning Solutions

Pearson Education, Addison-Wesley, Boston, USA, 2003. ISBN 978-0-201-77594-8

Gerrit Muller:

Systems Architecting – A Business Perspective

CRC Press (Taylor & Francis), Boca Raton, FL, USA, 2012. ISBN 978-1-4398-4762-6

Dan Remenyi, Arthur Money, Michael Sherwood-Smith:

The effective measurement and management of IT costs and benefits

Butterworth-Heinemann, Oxford UK, 2nd edition, 2000. ISBN 0-7506-4420-6

Jeanne W. Ross, Peter Weill, David C. Robertson:

Enterprise Architecture as Strategy – Creating a Foundation for Business Execution

Harvard Business Review Press, USA, 2006. ISBN 978-1-5913-9839-4



References: Agility

Reference

Barry Boehm, Richard Turner:

Balancing Agility and Discipline – A Guide for the Perplexed

Pearson Education, Addison-Wesley, Boston, USA, 2004. ISBN 978-0-321-18612-5

Richard de Neufville, Stefan Scholtes:

Flexibility in Engineering Design

MIT Press, Cambridge, USA, 2011. ISBN 978-0-262-01623-0

James Coplien, Gertrud Bjornvig:

Lean Architecture for Agile Software Development

John Wiley & Sons, Inc., Chicester UK, 2010. ISBN 978-0-470-68420-7

Fred A. Cummins:

Building the Agile Enterprise – with SOA, BPM and MBM

Morgan Kaufmann (Elsevier), Amsterdam, 2009. ISBN 978-0-12-374445-6

Jez Humble, David Farley:

Continuous Delivery – Reliable Software Releases through Build, Test, and Deployment Automation

Pearson Education (Addision-Wesley), Boston, USA, 2011. ISBN 978-0-321-60191-9

Bertrand Meyer:

Agile! – The Good, the Hype and the Ugly

Springer Verlag, Berlin und Heidelberg, 2014. ISBN 978-3-3190-5154-3

Dean Leffingwell:

Scaling Software Agility – Best Practices for Large Enterprises

Pearson Education (Addison-Wesley), Boston, USA, 2007. ISBN 978-0-321-45819-3



References: Resilience (1/2)

Reference

Erik Hollnagel, David D. Woods, Nancy Leveson (Editors):

Resilience Engineering – Concepts and Precepts

Ashgate Publishing Ltd., Aldershot, UK, 2006. ISBN 978-0-7546-4904-5

Erik Hollnagel, Jean Pariès, David D. Woods, John Wreathall (Editors):

Resilience Engineering in Practice – A Guidebook

Ashgate Publishing Ltd., Farnham, UK, 2011. ISBN 978-1-4724-2074-9

Erik Hollnagel :

FRAM: The Functional Resonance Analysis Method – Modelling Complex Socio-Technical Systems

Ashgate Publishing Ltd., Farnham, UK, 2012. ISBN 978-1-4094-4551-7

Michael Howard, David LeBlanc:

Writing Secure Code – Practical Strategies and Techniques for Secure Application Coding in a Networked World

Microsoft Press, Redmond, USA, 2003. ISBN 0-7356-1722-8

Clifford J. Berg:

High-Assurance Design – Architecting Secure and Reliable Enterprise Applications

Addison-Wesley, N.J., USA, 2006. ISBN 0-321-37577-7

Scott Jackson:

Architecting Resilient Systems – Accident Avoidance and Survival and Recovery from Disruptions

John Wiley & Sons, Inc., New Jersey, USA, 2010. ISBN 978-0-470-40503-1



References: Resilience (2/2)

Reference

C. Warren Axelrod:

Engineering Safe and Secure Software Systems

Artech House, Norwood, USA, 2013. ISBN 978-1-60807-472-3

Stuart Anderson, Massimo Felice:

Emerging Technological Risk – Underpinning the Risk of Technology Innovation

Springer-Verlag, London, UK, 2012. ISBN 978-1-4471-2142-8

Nancy G. Leveson:

Engineering a Safer World – Systems Thinking applied to Safety

MIT Press, Cambridge MA, USA, 2011. ISBN 978-0-262-01662-9

Mark S. Merkow, Lakshmikanth Raghavan:

Secure and Resilient Software Development

CRC Press, Taylor & Francis Group, Boca Raton, USA, 2010. ISBN 978-1-4398-2696-6

Kim Zetter:

Countdown to Zero Day – Stuxnet and the Launch of the World's First Digital Weapon

Crown Publishing, 2014. ISBN 978-0-7704-3617-9

Drew Chapman:

The Pattern of Fear – Paranoia is all in the Mind

Penguin Books, London, UK, 2013. ISBN 978-1-405-91287-7

Jeffrey Papows:

Glitch – The Hidden Impact of Faulty Software

Prentice Hall Inc., USA, 2010. ISBN 978-0-132-16063-6

Future-Proof Software-Systems: Managed Evolution



Managed Evolution



Future-Proof Software-Systems: Managed Evolution Coordinate System

x: BusinessValue

y: Resilience

z: Agility At any point in time tn

a system has a quantified:

• Business value

• Resilience

• Agility

agilitymetric

resilience

metric



BusinessValue

Resilience

Agility

Every project transforms the

system, i.e. it improves or

deteriorates its:

• Business value

• Resilience

• Agility



gain inbusiness value

gain inresilience

gain inagility

BusinessValue

Resilience

Agility

There are «good»

projects – improving

at the same time:

• Business value

• Agility

• Resilience

of the system



gain inbusiness value

loss inresilience

loss inagility

BusinessValue

Resilience

Agility

There are «bad» projects –

deteriorating at least one of the:

• Business value

• Agility

• Resilience

of the system



BusinessValue

Resilience

Agility

Future-Proof Software-Systems: Evolution Trajectory

A sequence of

projects builds a

transformation

trajectory of the IT

system (= the

evolution trajectory)



BusinessValue

Resilience

Agility

BusinessValue

Resilience

BusinessValue

Agility



BusinessValue

Resilience

BusinessValue

Agility

Future-Proof Software-Systems: 2 Managed Evolution Coordinate System

Agility Evolution Trajectory Resilience Evolution Trajectory

All projects in time All projects in time

Loss ofresilience

Gain ofBusiness value

Gain ofagility

Gain ofBusiness value

PiPj



BusinessValue

Agility

Loss ofAgility

Gain of BusinessValue

Continuous development of

business value while neglecting

improvement of agility leads to a

petrification of the system

(= path to death)

Trajectory Case 1:Opportunistic Evolution

Agility Evolution Trajectory



BusinessValue

Agility


Agility Evolution Trajectory: What does it mean?

4.2 k€/UCP

0.8 days/UCP10.0 k€/UCP

4.0 days/UCP

50.0 k€/UCP

10.0 days/UCP



Resilience

Loss ofResilience



Resilience Evolution Trajectory

BusinessValue

Continuous development of

business value while neglecting

improvement of resilience leads

to an undefendable system

(= path to death)



Resilience


Resilience Evolution Trajectory: What does it mean?

BusinessValue



Which is the right strategy for Future-Proof Software-Systems?

htt

p:/

/w

ww

.forb

es.c

om

/fd

c/w

elc

om

e_m

jx.s

htm

l



BusinessValue

Agility

Gain ofAgility


ManagedEvolutionChannel

Continuous development of both business value

and agility leads to a sustainable system

(= path to future-proof SW-systems)

Trajectory Case 2:Managed Evolution

Agility Evolution Trajectory



BusinessValue

Resi-lience

Gain ofResi-

lience



Continuous development of both business value

and resilience leads to a sustainable system

(= path to future-proof SW-systems)

Trajectory Case 2:Managed Evolution

Resilience Evolution Trajectory

http

://en

.wik

ipedia

.org

/w

iki/

Cze

ch

oslo

vak_b

ord

er_

fortific

atio

ns



Manifesto ofManaged Evolution

1. Each project mustimprove business value,

agility and resilience(average)

2. Each projectimplements only amanageable, risk-

controlled functionality


Business Value

AgilityResilience

First Key Insightfor Future-Proof

Software-Systems



Is there a significant obstacle to managed evolution?

BusinessValue

Agility

Project Pn

Implementing an

amount of functionality

(= business value)

requires:

• Money (€, $)

• Time (TPn)

Resilience





BusinessValue

Agility

Improving agility and

resilience requires

additional:

• Money (€, $)

• Time (TPn)

Resilience

Gain of Business Value

Gain ofagility &

resilience




Improving agility and resilience

requires additional:

• Money (€, $)

• Time (TPn)

Agility Resilience

Gain ofagility &

resilience

http://sgs-uae.com

Are your business people prepared to pay?

For every project?



Is there a significant obstacle to managed evolution?http://wohleranzeiger.ch/seilziehen/index.html

BusinessPeople

CIO &IT-Architects

Business wants:• (Very) short time to market

• Low cost

• Only essential functionality

• Newest technology

CIO & Architecture want:• Improving Agility

• Improving Resilience

• Limit growth in complexity

• No technical debt




http://wohleranzeiger.ch/seilziehen/index.html

BusinessPeople

CIO &IT-Architects

Second Key Insightfor Future-Proof

Software-Systems

Necessary:Good alignment, trustand respect betweenbusiness and IT



http

://articles.econ

om

ictimes.in

diatim

es.com

/20

13

-02

-06

/new

s/36

94

96

15

_1_b

oein

g-s-dream

liner-fligh

ts-nip

po

n-airw

ays

Example: Boeing 787(787 Dreamliner Grounding)

On January 17, the fleet of 50dreamliner 787 aircraft wasgrounded due to problems with itslithium-ion batteries

Reason: The pressure to meet tight deadlines

http://www.nbcnews.com/id/50584174

Highly dangerous:

Business requirementsmassively overruledengineering requirements



Managed Evolution: Importance

Why is managed evolution so important?

• Most of today’s software-systems are so large andcomplex, that they cannot be understood by a singleperson, not even by a group of persons

• Entropy strongly and quickly deteriorates the qualityproperties of software-systems

We need a reliable, measurable strategy to evolve ourlarge and complex software-systems

We need to measure the success of our strategy, i.e. toprove the improvement of our quality criteria

We need a management tool to steer large projects intothe quality-based direction we want



Managed Evolution: Importance

BusinessValue

Agility

Gain ofAgility

htt

p:/

/lu

nat

un

es.d

evia

nta

rt.c

om

/art




References: Managed Evolution

Reference

Stephan Murer, Bruno Bonati, Frank J. Furrer:

Managed Evolution – A Strategy for Very Large Information Systems

Springer-Verlag, Berlin Heidelberg, 2011, ISBN 978-3-642-01632-5

Michael A. Cusumano:

Staying Power – Six Enduring Principles for Managing Strategy & Innovation in an Uncertain World

Oxford University Press, New York, USA, 2010. ISBN 978-0-19-921896-7

Olivier L. de Weck, Daniel Roos, Christopher L. Magee:

Engineering Systems – Meeting Human Needs in a Complex Technological World

MIT Press, Cambridge, USA, 2011. ISBN 978-0-262-01670-4

George Fairbanks:

Just Enough Software Architecture – A Risk-Driven Approach

Marshall & Brainerd, Boulder CO, USA, 2010. ISBN 978-0-9846181-0-1

Mario Godinez, Eberhardt Hechler, Klaus Koening, Steve Lockwood, Martin Oberhofer, Michael Schroeck:

The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight

Addison Wesley Publishing Inc., USA, 2010. ISBN 978-0-13-703571-7

Frederik Ahlemann, Eric Stettiner, Marcus Messerschmidt, Christine Legner (Editors):

Strategic Enterprise Architecture Management – Challenges, Best Practices, and Future Developments

Springer-Verlag, Berlin Heidelberg, 2012. ISBN 978-3-642-24222-9

Scott A. Bernard:

An Introduction to Enterprise Architecture – Linking Strategy, Business, and Technology.

Author House, IN, USA, 2012. ISBN 978-1-4772-5800-2

Future-Proof Software-Systems: Erosion & Technical Debt



Business Value ErosionArchitecture Erosion

Technical Debt



The force of entropy means that disorder is the only thing

that happens automatically and by itself.

If you want to create a completely ad-hoc IT architecture,

you do not have to lift a finger.

It will happen automatically as a result of day-to-day IT

activity.

Richard Hubert: Convergent Architecture, 2002. ISBN 978-0-471-10560-2

http://larvalsubjects.wordpress.com



Business Value Erosion

BusinessValue

AgilityResilience

tn

AgilityResilience

tn+1 tn

BusinessValue

AgilityResilience

tn+2 tn+1 tn

Business Value

Business value erodes,

because:

• Functionality

becomes obsolete

• User behaviour

changes

• Functionality is

replaced (renewed)

• New delivery

channels appear



Business Value

AgilityResilience

Architecture Erosionhttp://thoreau.colonial.net/Students/EricksonHoyt/erosion

The force of erosion

continuously

reduces agility and

resilience (and other

quality properties)



Architecture Erosion

Any IT-architecture is continuously

degenerating due to many factors:

• SW Paradigm changes (e.g. SOA)

• New laws & regulations

• New standards (e.g. interoperability standards)

• New technology platforms (e.g. Web Services)

• Introduction of new architecture principles

• Complexity increase

• New malicious activities

… and some more

http://thoreau.colonial.net/Students/EricksonHoyt/erosion

Architecture Erosion:

Architecture Erosionis generated byexternal factors



Architecture Erosion Examples

In the history of software engineering there were manydisruptive paradigm changes which led to massivearchitecture erosion, e.g.:

Procedural programming Object-Orientation

Local processing distributed processing

Monoliths Client-Server architecture

Remote procedure calls/CORBA Web services

Programming by people Model-based code generation

… and more to come



Business Value

AgilityResilience


You need a

continuous effort

just to maintain

agility and resilience




Business Value

AgilityResilience


You need additional

effort to improve

agility and resilience




Architecture Erosion Example: COBOL Programming

Gartner 1997:

Around 200 billion lines of COBOL code are in live operation

75% of the world’s business data, and 90% of financialtransactions, are processed in COBOLhttp://en.wikipedia.org/wiki/COBOL

htt

p:/

/w

ww

.wew

ere

web.b

e/in

trodu

cti

on

-au

-cobol/

2012/01/22

COBOL (COmmonBusiness-OrientedLanguage, 1959) is acompiled programminglanguage designed forbusiness, finance, andadministrative systemsuse.

Technical Erosion:Replacement?



Technical Debt

Technical Debt

Technical Debt

Definition:

Technical debt in an IT-system is the

result of all those necessary things that

you choose not to do now, but will impede

future evolution if left undone

Ward Cunningham, 2007

Technical Debt:is generated byinternal factors



Technical Debt

Technical Debt:

Causes of Technical Debt:

• Architecture Erosion

• Disruptive technology

• Accumulation of mistakes + shortcuts (e.g. breaking partitions)

• Dead code (missed explementations)

• Bad (or ignored) programming best practices & guidelines

• Violation of Architecture Principles, e.g. unmanaged redundancy

• Deferred refactoring

• Progress in software-engineering (e.g. programming languages)

• Careless or skipped upgrades

… and some more



Technical Debt

Technical debt sneaks in– some time seen, sometime unseen

http

://w

ww

.hdw

allp

apers

cool.c

om

/sn

ake-d

eskto

p-w

allp

apers

/

The continuous accumulation of technical debt

is many times justified by the statement:

«we know we should do it differently – but there is no time

now – we will fix it later» (… and forget about)

is a massive danger for any IT-system



The first kind of technical debt is the kind that is incurred

unintentionally. For example, a design approach just turns out to be

error-prone or a junior programmer just writes bad code. This

technical debt is the result of doing a poor job

Steve McConnell, 2007

The second kind of technical debt is the kind that is incurred

intentionally. This occurs when an organization makes a conscious

decision to optimize for the present rather than for the future. This

inc ludes decisions like "We don't have time to reconcile these two

databases, so we'll write some glue code that keeps them

synchronized for now and reconcile them after we ship“, or "We have

some code written by a contractor that doesn't follow our coding

standards; we'll clean that up later”

Steve McConnell, 2007



Time

QualityProperties

TechnicalDebt Accumulation

Technical Debt

Projects



Technical Debt

http://dandev91.wordpress.com/

Cost of one source line of

embedded systems code:

€ 15.00 … € 40.00

Average Technical Debt

in each source line of

embedded systems code:

€ 2.70

[Deloitte Consulting LLP: Tech Trends 2014]



Example: Database Extension (1/2)Technical Debt

ApplicationApplicationApplicationApplicationApplication

NewApplicationDB

Extensions

Solution 1: Extend DB2 Database

ApplicationApplicationApplicationApplicationApplication

NewApplication

Ext Problem: New database standard = ORACLE



Example: Database Extension (2/2)Technical Debt

Solution 2: Full migration to ORACLE Database

ApplicationApplicationApplicationApplicationApplicationMigration

Ext NewApplication

Solution 3: Bridging

NewApplication

ApplicationApplicationApplicationApplication

Bridging:• Synchronization

• Alignment«We will fix it later»



What can we do against the accumulation of technical debt?

Allow additional:

• Money (€, $)

• Time (TPn)

in each project

BusinessValue

Gain of Business Value

Quality Properties

Project Pn

CombatArchitecture

Erosionand

TechnicalDebt

Accumulation



Summary

Architecture erosion and technical debt accumulationconstitute a heavy risk for software-systems.

Architecture erosion and technical debt sneak into thesystem – often unknown – and massively impede theevolution of the IT system

Management procedures, quality assurance processes,and support from the business people must be present toavoid architecture erosion and technical debtaccumulation.

Each individual project must have funding and time toavoid architecture erosion and technical debtaccumulation



Summary«We will fix it later»

… is the direct way to hell

htt

ps:/

/w

ww

.beh

an

ce.n

et



Deutsch: Kontostand am 31.12.2012Französisch: Solde bancaire le 31.12.2013Italienisch: Saldo il 31.12.2013Englisch: Balance at 31.12.2013

Example: 5th Language Until 1995 Swiss banking IT-systems used 4 languages:

Spanisch: Saldo el 31.12.2013Due to globalization, in Y2000 a newlanguage (Spanish) had to be offered

to the customers

PROGRAMM N…(1;12;Kontostand am x.y.z)(2;12;Solde bancaire le x.y.z)(3;12;Saldo il x.y.z)(4;12;Balance at x.y.z)……

Traditionally, thetexts were part ofthe individualprograms („text-string“),identified bylanguage codeand text code

PROGRAMM N…(1;12;Kontostand am x.y.z)(2;12;Solde bancaire le x.y.z)(3;12;Saldo il x.y.z)(4;12;Balance at x.y.z)(5;12;Saldo x.y.z)……

Individuallymodify all theprograms whichneed Spanishoutput (ca. 5‘000applications)

Solution 1:

PROGRAMM N……

Create a centrallanguage file andexport it to allprograms

Solution 2:

(1;12;Kontostand am x.y.z)(2;12;Solde bancaire le x.y.z)(3;12;Saldo il x.y.z)(4;12;Balance at x.y.z)(5;12;Saldo x.y.z)

PROGRAMM N+1…… PROGRAMM N+2

…… PROGRAMM N+3

……



References: Erosion & Debt

Reference

Chris Sterling:

Managing Software Debt – Building for Inevitable Change

Pearson Education, Addison-Wesley, N.J., USA, 2011. ISBN 978-0-321-55413-0

Deloitte Consulting LLP:

How to Reverse Your Technical Debt

Tech Trends 2014: Inspiring Disruption, June 18, 2014. Downloadable from:http://www.castsoftware.com/castresources/materials/recorded/061814/How_To_Reverse_Your_Technical_Debt.pdf [lastaccessed: 16.8.2014]

Martin Fowler:

Technical Debt

February 2009. Downloadable from: http://martinfowler.com/bliki/TechnicalDebt.html (last accessed 24.6.2013)

Ward Cunningham:

Technical Debt. 2012. Downloadable from: http://c2.com/cgi/wiki?TechnicalDebt [last accessed 9.10.2014]

Steve McConnell:

Technical Debt. 2007. Downloadable from: http://www.construx.com/10x_Software_Development/Technical_Debt/ [lastaccessed 9.10.2014]

Future-Proof Software-Systems: Importance of Architecture



Importance of Architecture



Definition:





Parts of the systemand their relationsships

Architecture



A future-proof software-system is a structure that enables themanagement of complexity, change and uncertainty

with the least effort, with acceptable risk and with specified qualityproperties

http://www.0lll.com/architecture-exhibitions/?gal=24 http://www.asisbiz.com/index.html

Which structure is easier to expand and evolve?Which structure has the better properties, e.g. quality of life?

Which structure is future-proof?



Why is structure important? What determines structure?

htt

p:/

/ww

w.n

ews.

wis

c.ed

u/n

ewsp

ho

tos/

iro

nV

I.h

tml

Structure is the basis forordered, managed evolution

The

tow

ero

fb

abelb

yP

ieterB

ruegelth

eEld

er(1

56

3)

Architecture! Architecture! Architecture!



Example: Access Control(Applications Security)

Impact of a change: 5’000 privacy-critical banking applications

DigitalCertificate

DigitalCertificate

Access Control

Application

Access Control

Application

Access Control

Application

Access Control

Application

Access Control

Application

Access Control

Application

UID,PW

Structure 1: Distributed Access Control

Application

Application

ApplicationApplication


UID,PW

Access Control

Structure 2: Central Access Control



IT Architecture Definition:

“The fundamental organization of a system

embodied in its parts, their relationships to

each other and to the environment, and the

principles guiding its design and evolution”[adapted from IEEE00]



System Boundary

Parts of the System

Internal Dependencies(Relationships)

External Dependencies(Relationships)

Properties

Behaviour

Properties

Behaviour

Properties

Behaviour



BusinessValue

Agility

BusinessValue

Resilience

+ Quality PropertiesPerformance

Energy Consumption…

The structure of the system

– i.e. its architecture –

determines to a large extent

the properties of the system

Architecture

is the most important factor

for

future-proof software-systems



Architecture of the existing system:• Parts• Relationships

Architecture of the new element:• Parts• Relationships



optimumfit into

existingsystem

Design, Implementation,Deployment

ArchitectureDevelopment

adequatearchitectureof new parts

&relationships

Architecture development is a

front activity, i.e. it must be done

before the actual software

development starts

How much shall we invest into

architecture devlopment?

• Money (5%, 12%, 27%, …) ?

• Time (3%, 11%, 21%) ?



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

How much Architecture is enough?

Architecture = Front-end effort (beforethe productive work starts)

Cost, delay, constraints

Architecture work

Project effort (€)

10 %

100 %

??

Answer:

• System creation/extensions with highrisk need much architecture work

• System creation/extensions with lowrisk need little architecture work(George Fairbanks - ISBN 978-0-9846181-0-1, 2010)



How much Architecture is enough?

Architecture work

Project effort (€)

10 %

100 %

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



When have we done enough architecture work?

How do we know that we have a good architecture?

Architecture Principles

Architecture Evaluation



Arc

hite

ctu

reD

evelo

pm

en

t

Architecture options

Existingsystem

architecture

Arc

hite

ctu

reE

valu

atio

n

Target architecture

weightingtrade-offs

Requirements• functional• properties

RequirementsEngineering

stakeholders

ArchitectureTop-LevelProcess

completeness,consistency



Example: Sanction Filter(Financial embargo enforcement)

Application


Application



Application


Application




Application

Application

several 1‘000 applicationsin >40 countries

SIC XYZSWIFT SWIFT SWIFT SWIFT SWIFT SWIFT SIC XYZ

hundreds of clearing hubs worldwide

world

wid

econ

nectiv

ity

several 1‘000connections toclearing hubs

New legal requirement:„Strictly enforce embargo lists

worldwide“

San

cti

on

filt

er




Application


Application



Application


Application




Application

Application




several 1‘000connections toclearing hubs

San

cti

on

filt

er

Architecture option 1:Fully decentralized installation




Application


Application



Application


Application




Application

Application




Architecture option 2:Fully centralized installation

centralized, high-performancesanction filter




Application


Application



Application


Application




Application

Application




Architecture option 3:Sub-clustering

Sanctionlist

centrallymaintained




Arc

hite

ctu

reE

valu

atio

n

Target architecture

weightingtrade-offs

Criteria Option 1: fullydecentralized

Option 2: fullycentralized

Option 3: Sub-clustering

Performance 3 1 2

Security 1 3 2

Maintainability 1 3 3

Dependability 3 1 2

Implementation cost 1 2 3

Operational cost 1 3 2

Match withorganizationalstructure

1 1 3

Governance 1 1 3

Legal & complianceconformance

2 3 3

Archiving 1 3 2

Assessment 15 21 25

1 = low2 = average3 = good




Business Value

Agility

Resilience


Non-functional properties:

o Reusability



o etc.

Characteristics of Future-Proof Software-Systems



whichproperties?



Example: Availability(System Quality Property)

Definition:

Availability = The degree to which a system or component is operational andaccessible when required for use [IEEE Std 610.12-1990]

Simply put, availability is the proportion of time a system is in a functioning condition

S

Metric:E[Uptime]

Availability A =E[Uptime]+E[Downtime]

Example:

Uptime = 23.8 hrs/day

Downtime = 0.2 hrs/day

A = 0.9917



Quality Property Type

Business Value Primary Characteristic

Agility Primary Characteristic

Availability

Security

Safety

Privacy/Confidentiality

Performance

Usability

Robustness

Operating Cost

Reusability

Compliance to laws and regulations

Adherence to industry-standards

Memory Size

Power consumption

Testability

etc.

= Resilience

identical forall systems

Resilience set:dependent onapplication area

Additionalqualityproperties:dependent onapplication area



# System Quality Property Weight

0: irrelevant

10: highest importance

Primary Characteristics

1 Business Value 10

2 Agility 10

Resilience:

3 Safety 9

4 Fault-Tolerance 9

5 Compliance to laws & regulations 9

6 Integrity (Sensor Data) 9

7 Availability 8

8 Security 7

9 Diagnosability 6

Secondary Characteristics

10 Resources (Memory, CPU, …) 8

11 Compliance to industry-standards 7

12 Usability (User Interfaces) 9

etc

Example:Automotive Domain

Quality PropertyScore Card



System Design,Implementation,

Deployment

ArchitectureDevelopment

ArchitectureEvaluation

Fun

ctio

nal

Requ

irem

en

ts

# System Quality Property Weight

0: irrelevant

10: highest importance

Primary Characteristics

1 Business Value 10

2 Agility 10

Resilience:

3 Safety 9

4 Fault-Tolerance 9

5 Compliance to laws & regulations 9

6 Integrity (Sensor Data) 9

7 Availability 8

8 Security 7

9 Diagnosability 6

Secondary Characteristics

10 Resources (Memory, CPU, …) 8

11 Compliance to industry-standards 7

12 Usability (User Interfaces) 9

etc

rev

iew

&a

pp

rov

al



Summary

The most important success factor for a future-proof

software system is its structure: The structure enables

functionality and most of the quality attributes. Therefore

the system structure must very carefully be defined,

implemented and evolved.

Structure of a system is defined by its architecture. The

architecture must be adequate and adhere to proven

architecture principles. Architecture is a continuously

evolving, managed, key artefact!

Future-Proof Software-Systems: Industrial Architecture



Industrial Architecture



Software determines (to a large extent):

Functionality

Quality Properties, such as safety, security, availability, …)

Competitiveness and revenue generation of the company

Innovation and Intellectual Property Rights

Faulty software has an enormous impact:

• Risks in safety- or security-critical systems

• Loss of customers, revenue and reputation

• Legal & regulatory consequences

• Product liability

• etc.

Jeffrey Papows, 2010

ISBN 978-0-132-16063-6



Example: Faulty Automotive Software

Feb 12, 2014 (Reuters): “Toyota Motor Corp on

Wednesday issued a recall covering all 1.9 million of

the third-generation Prius cars sold worldwide, due

to a programming glitch in their hybrid system”

htt

p:/

/arc

hiv

e.w

grz

.com

/n

ew

s/art

icle

/216964/1/Toyota

-Recalls-2

42000-P

riu

s-L

exu

s-H

ybri

d-C

ar



Agility

Business Value

Business Value

Resilience

Business Value

Quality Properties

Future-ProofSoftware Systems

+ Functional correctness

The software doeswhat it should do

The software does notwhat it should not do

Functional Correctness

↑Good Architecture



System/Software Architecture

ArchitectureQuality

bad

low

good

high

Enabler for:

business value, agility,

quality properties, functional correctness

Cause for:

functional errors restricted business

value low agility

bad quality properties



System/Software Architecture

=Central Issue

in Systems- and Software-Engineering

Lecture:

Parts 2 & 3: Principles of good architecture

( Structure of Future-Proof Software-Systems)

Part 4: The Role, Personality and Context

of the „Future-Proof Software-System Architect“



Architecture

=Central Issue

in Systems- and Software-Engineering

Industrial Architecture:

= The result of a principle-based, formalized

process relying on industrial methods and

best practices to assure defined quality goals




«Architecture» of the Industrial Architecture:

Meta-Architecture

[= A Framework to specify Industrial Architecture]



Information (Data)Architecture(Information & Data)

TechnicalArchitecture(TechnicalInfrastructure)

IntegrationArchitecture(CooperationMechanisms)

ApplicationsArchitecture(Functionality)

BusinessArchitecture(Business Processes)

Industrial Architecture Stack:



Example:Automotive Control

htt

p:/

/ww

w.v

eh

icle

-lab

.ne

t

Information (Data) Architecture:• Specification of information used (car & environment) and data structures

Technical Architecture:• Number and location of the ECU‘s, cabling structure• System software (RTOS)

Integration Architecture:• Design of bus-structure(s) and interaction mechanisms & middleware

Applications Architecture:• Assignment of functionality to tasks, definition of interfaces, redundancy

Business Architecture:• Definition of Functionality, User interfaces & Interactions








Str

uctu

ralA

rch

itectu

reLayers

Hori

zonta

lA

rch

itectu

res

SecurityArchitecture

(Defense)

SafetyArchitecture

(Accidents)

PerformanceArchitecture

(Real-Time)

SystemManagementArchitecture

(Control)

etc

.X-Architectures

Vertical Architectures









(Defense)

SafetyArchitecture

(Accidents)


(Real-Time)


(Control)

etc

.

Imp

act

on

all

ho

rizo

nta

lla

ye

rs

Imp

act

on

all

ho

rizo

nta

lla

ye

rs

Imp

act

on

all

ho

rizo

nta

lla

ye

rs

Imp

act

on

all

ho

rizo

nta

lla

ye

rs









(Defense)

SafetyArchitecture

(Accidents)


(Real-Time)


(Control)

etc

.

For each of the horizontal

and vertical architectures there are:

• Architecture Principles

• Architecture Patterns

• Best Practices




ArchitectureGuidelines &

Best Practices

ArchitectureStandards

Architecture Developmenthttp://www.telco2.net/blog/2007/04/telco_20_event_digital_worker.html

Fundamental insights– formulated as rules –how a good IT-systemshould be built

http://www.wyattresources.com/guardrail.htm

Implementation advice– seen as „guardrails“ –to guide the architect

Binding, enforcableregulation for buildingan IT-system



Example: Managed Data Redundancy(Applications Architecture & Information Architecture)

Problem: Different applications work with inconsistent data

Information(Content)

InformationSource

InformationSource

DataSource

DataSource

Snap-shot

ApplicationUserApplication

UserApplicationUser


User

ApplicationUser

Multiple, uncoordinatedacquisition of the sameinformation

Redundant, ofteninconsistent data

Applications or userswork with different,inconsistent data



Example: Managed Data Redundancy(Applications Architecture & Information Architecture)

The data is generatedand propagated in aconsistent way

Applications or userswork with consistent data

Architecture Principle:For each information (content) one andonly one master source is defined. All

managed data redundancy derivessolely from this master source

Information(Content)

InformationSource

InformationSource

Master DataSource

Synchronization/Consistency

Snap-shot

DataSource

DataSource


UserApplicationUser


User

ApplicationUser



Example: Access Control (Security Architecture)

InformationArchitecture

TechnicalArchitecture

IntegrationArchitecture

ApplicationsArchitecture

BusinessArchitecture

Security Safety Perfor-mance

SystemManage-

ment

UserNameIDCredentials

Protection Object

NameIDConfidentiality LevelConstraints

Role

Role NameID

1…*1…*

MemberOf

1…*1…*

isAuthorizedfor

RightAccessTypeCredentials

checkRights

http://www.techwench.com

Rights DB

Access Control

APPLICATION

Rights



EngineeringDiscipline


ArchitectureGuidelines &Best Practices

ArchitectureMetrics

ArchitectureStandards

GovernanceInstrument

IT StandardsEnforcement

TechnologyPortfolio

Management

ApplicationsPortfolio

Management

ServicePortfolio

Management

ArchitectureProcess

IT StandardsDevelopment

ComplexityManagement

Architect‘sTraining

Business – ITAlignment

ArchitectureCommunication


Architecture Development

Architecture Enforcement

Result: Structure („Architecture“)

Structure

BusinessArchitecture

ApplicationsArchitecture

IntegrationArchitecture

InformationArchitecture

TechnicalArchitecture

VerticalArchitectures

…



Use and Importance of Architecture Views

Stakeholders

www.123rf.com

Sys Mgmt

Security

Safety

etc.

Architecture documentation:

Documentation Framework

Views:

Overarching documentation



Architecture View: Security – a selective view

System Boundary

Security Properties:• Protocol: Secure ESB

• Encryption: RSA-1024• Encryption: Link

• Authentication: none

Security Properties:• Protocol: SSL

• # Cert: 2‘048 Bit• Encryption: End-to-End

• Authentication: PKI

Security Properties:• Authentication: # Certificates

• Authorization: Role-Based• Audit Trail: Real-Time

• Monitoring: continuous• Databases: encrypted



Summary

Bad architecture is the cause for:

functional errors

restricted business value

low agility, weak resilience

bad quality properties

Good architecture is the enabler for:

business value,

agility & resilience,

quality properties,

functional correctness



References:ReferencesMurer11 Stephan Murer, Bruno Bonati, Frank J. Furrer:

Managed Evolution – A Strategy for Very Large Information Systems

Springer-Verlag, Berlin Heidelberg, 2011, ISBN 978-3-642-01632-5Fairbanks10 George Fairbanks:


Marshall & Brainerd, Boulder CO, USA, 2010. ISBN 978-0-9846181-0-1DeWeck11 Olivier L. de Weck, Daniel Roos, Christopher L. Magee:

Engineering Systems – Meeting Human Needs in a Complex Technological World

MIT Press, Cambridge, USA, 2011. ISBN 978-0-262-01670-4Bass13 Len Bass, Paul Clements, Rick Kazman:

Software Architecture in Practice

SEI-Series (Pearson Education), Addison-Wesley, N.J., USA, 3rd edition, 2013. ISBN 978-0-321-81573-6Beijer10 Peter Beijer, Theo de Klerk:

IT Architecture – Essential Practice for IT Business Solutions

Lulu Enterprises Inc., USA, 2010 (www.lulu.com). ISBN 978-1-4457-0603-0Clements10 Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord:

Documenting Software Architectures: Views and Beyond

SEI Series in Software Engineering. Addison Wesley, MA, USA, 2nd revised edition, 2010. ISBN 978-0-321-55268-6

Gorton06 Ian Gorton

Essential Software Architecture

Springer-Verlag, Berlin Heidelberg, 2006. ISBN 978-3-540-28713-1Greefhorst11 David Greefhorst, Erik Proper:

Architecture Principles – The Cornerstones of Enterprise Architecture

Springer Verlag, Heidelberg, Berlin, 2011. ISBN 978-3-642-20278-0Lattanze09 Anthony J. Lattanze:

Architecting Software Intensive Systems – A Practicioner’s Guide

Auerbach Publications, Taylor & Francis Group, LLC, 2009. ISBN 978-1-4200-4569-7



References:ReferencesSterling11 Chris Sterling:

Managing Software Debt – Building for Inevitable Change

Pearson Education, Addison-Wesley, N.J., USA, 2011. ISBN 978-0-321-55413-0Gutbrod12 Roger Gutbrod, Christian Wiele:

The Software Dilemma – Balancing Creativity and Control on the Path to Sustainable SoftwareSpringer-Verlag, Heidelberg, 2012. ISBN 978-3-642-27235-6

DeMarco97 Tom DeMarco:

The Deadline – A Novel About Project Management

Dorset House Publishing, N.Y., USA, 1997. ISBN 978-0-932633-39-2

Fowler09 Martin Fowler:

Technical Debt

February 2009, downloadable from: http://martinfowler.com/bliki/TechnicalDebt.html (last accessed 24.6.2013)

Duvall07 Paul Duvall, Steve Matyas, Andrew Glover:

Continuous Integration - Improving Software Quality and Reducing Risk

(Pearson Education) Addison-Wesley, N.J., USA, 2007. ISBN 978-0-321-33638-5

Feathers07 Michael Feathers:

Working Effectively with Legacy Code

Prentice Hall International, USA, 2007. ISBN 978-0-13-117705-5

Barbacci95 Mario Barbacci, Mark H. Klein, Thomas A. Longstaff, Charles B. Weinstock:

Quality Attributes

Software Engineering Institute (SEI), Carnegie Mellon University, Technical Report CMU/SEI-95-TR-021,December 1995. Downloadable from: http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm (lastaccessed 24.6.2013)

Fairbanks10 George Fairbanks:


Marshall & Brainerd, Boulder CO, USA, 2010. ISBN 978-0-9846181-0-1



This is the end of Part 1:

You know now the foundations of future-proof software-systems

Parts 2 + 3:

Explains the important architecture principles

Part 4:

Describes the „future-proof software-systems engineer“ and his workingcontext

FPSS WS1415 Part1 V08 20141112 - TU...

Documents

Transcript of FPSS WS1415 Part1 V08 20141112 - TU...