PART2 B-WS13-14 V08 20131124 - TU Dresdenst.inf.tu-dresden.de/files/teaching/ws13/fps13/... ·...

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

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

TU Dresden WS 2013/2014

Part 2 - BPart 2 - B

V0.81 / 26. 11.2013

Future-Proof Software-Systems:

A6: Reference Architectures,Frameworks and Patterns

Industrial Architecture

Copyright Frank J. Furrer 2013 2

EngineeringDiscipline

ArchitectureProcess

GovernanceInstrument

Structure

ArchitecturePrinciples

ArchitectureGuidelines &Best Practices

ArchitectureMetrics

ArchitectureStandards

BusinessArchitecture

ApplicationsArchitecture

Safety &Security

Architecture

IntegrationArchitecture

TechnicalArchitecture

StandardsEnforcement

TechnologyPortfolio

Management

ApplicationsPortfolio

Management

ServicePortfolio

Management

IT StandardsDevelopment

ComplexityManagement

Architect‘sTraining

Business-to-ITAlignment

ArchitectureCommunication

Future-Proof Software-Systems: Ref Archs & Patterns

Reference Architecture:

A reference architectureprovides a template solutionfor an architecture for aparticular application domain

- such as financial systems,automotive, aerospace etc.

Architecture Pattern:

An architectural pattern isa concept that solves anddelineates some essentialcohesive elements of asoftware architecture

http://en.wikipedia.org/wiki/Architectural_pattern

Reference Architectures, Architecture Frameworks, Architecture Patterns:

highly valuablesoftware/system architectureknowledge in proven & easilyaccessible form


automotive, aerospace etc.

Architecture Framework:

An architecture frameworkestablishes a common practicefor creating, interpreting,analyzing and usingarchitecture descriptions withina particular application domain

[ISO/IEC/IEEE 42010]

Architectural_pattern


Patterns

Architecture Pattern:

An architectural pattern is a concept that solves and delineates some essentialcohesive elements of a software architecturehttp://en.wikipedia.org/wiki/Architectural_pattern

Origin of Patterns:Christopher Alexander, 1977

Application to Software Architecture:Erich Gamma, Richard Helm,Ralph Johnson, John Vlissides, 1995(„Gang of Four“)


http

://m

ihpatte

.com

/desig

n-p

atte

rns-b

y-g

am

ma

(„Gang of Four“)


Example: Security Pattern „RBAC“ [Role-Based Access Control](Fernandez: Security Patterns in Practice, 2013, ISBN 978-1-119-99894-5)

accessDataUser

idname

ProtectionObject

idname

Role

idname

**

memberOf

Right

* *

isAuthorizedFor


ROLE-BASED ACCESS CONTROL PATTERN:

The User and Role classes describe registered users and their predefined

roles. Users are assigned to roles, roles are given rights according to theirfunctions. The association class Right defines the access types that a

user within a role is authorized to apply to the ProtectionObject.

Right

accessType

checkRights


Example: Broker Pattern(Buschmann et. al.: A System of Patterns, 1996, ISBN 0-471-95869-7)

calls

Client-sideProxy

send_request

*

*

Server-sideProxy

call_servicesend_response

calls*

*

Broker

register_servicefind_serverfind_clientforward_requestforward_response

transfermessage

* *

transfermessage

* *

uses

*usesAPI

usesAPI


Server(Service Provider)

User

call_serverstart_taskuse_Broker_API

Server

run_serviceuse_Broker_API

* *

Bridge

pack/unpack dataforward_messagetransmit_message

uses

*

usesAPI

usesAPI

BROKER PATTERN:

This pattern is used to structure distributed systems with decoupledcomponents that interact by remote service invocations.


Patterns are recorded architecture and design wisdomin „canonical“ form. Patterns help you build on thecollective experience of skilled architects and softwareengineers (Buschmann et. al. ISBN 0-471-95869-7)

Patterns

Patterns are not final, directly applicable solutions!Patterns are intellectual building blocks which mustbe intelligently integrated into your work


Patterns are excellent documentation and communicationsinstruments. They are formal, clear and focussed

www.123rf.com

There is a rich literature about patterns.The future-proof software-system engineerneeds to continuously familiarize himselfwith this trove of architecture knowledge!


Architecture Frameworks

Architecture Framework:

An architecture framework establishes a common practice for creating, interpreting,analyzing and using architecture descriptions within a particular application domain

[ISO/IEC/IEEE 42010]

Meta-Model

TemplatesTemplates

TemplatesPrinciples


Architecture Methodology/Process Information Architecture

Technical Architecture

Integration Architecture

Applications Architecture

Business Architecture

ModelingNotation

ReferenceArchitectures

Architecture Organization Blueprint


Example: TOGAF (1/2)[The Open Group Architecture Framework] http://www.togaf.org/

Process,Methodology

Deliverables,Artefacts

ReferenceModels


ArchitectureOrganization

Repositoryetc.

Principles


Example: TOGAF (2/2)[The Open Group Architecture Framework] http://www.togaf.org/

htt

p:/

/pu

bs.o

pen

gro

up.o

rg/arc

hit

ectu

re/to

gaf8

-doc/arc

h/ch

ap22.h

tml

TOGAFIII-RM


htt

p:/

/pu

bs.o

pen

gro

up.o

rg/arc

hit

ectu

re/to

gaf8

III-RMReferenceArchitecture(High level)


Reference Architecture:

A reference architecture provides a template solution for a generic architecture for aparticular application domain

- such as financial systems, automotive, aerospace etc.

Reference Architecture

A reference architecture may recommend: FundamentalStructure

ComponentModel

etc.


ServiceStandardizationTechnology

Choices

Model

SafetyMechanisms

Component ContractModel


Example: AUTOSAR (1/2)[AUTomotive Open System ARchitecture] http://www.autosar.org

htt

p:/

/w

ww

.au

tosar.

org

/dow

nlo

ad/papers

an

dpre

sen

tati

on

s/A

UTO

SA

R_B

roch

ure

_EN

.pdf


htt

p:/

/w

ww

.au

tosar.

org

/dow

nlo

ad/papers

an

dpre

sen

tati

on

s/A

UTO

SA

R_B

roch

ure

_EN

.pdf


Example: AUTOSAR (2/2)http://www.autosar.org

AUTOSAR is well documented in a number ofinteresting documents (some only for members)

AUTOSAR:

„Cooperate on


Standards –

Compete on

Implementations“


Example: BIAN (1/2)Banking Industry Architecture Network: http://www.bian.org

BIAN standardizes the full functionallandscape of a financial institution



Example: A (2/2)http://www.bian.org

Financial Markets

InvestmentManagement

Investment PortfolioPlanning IT Service

Investment

FinancialMarkets

InvestmentManagement

Investment PortfolioPlanning

Internal IT SystemOutsourced or3rd party SW


Investment PortfolioAnalysis

Investment PortfolioManagement

eTrading

Bu

siness

Pro

cess

IT Service

IT Service

IT Service

InvestmentPortfolioAnalysis

Bu

siness

Pro

cess

eTrading

Investment PortfolioManagement

Industry-wide,exchangeable,standardizedservices


Architecture Principle A5:

Reference Architectures, Frameworks and Patterns

1. Always consider applicable reference architectures, frameworksand patterns. Whenever possible adhere to proven patterns asfoundations of architecture and design

2. Manage and cultivate a set of patterns (in a repository) in yourcompany for easy reference. Annotate these with your own

A5


company for easy reference. Annotate these with your ownexperience

3. For 3rd party software insist (as much as possible) on industry-standardized interfaces, services and managed redundancy

Justification: Reference architectures, frameworks and patterns arehighly valuable architecture and design knowledge in condensedform. Using suitable, proven reference architectures, frameworks andpatterns leads to good, safe and often optimum solutions


Reference Architectures

Architecture Frameworks

Architecture Patterns

arc

hit

ectu

re.h

tml


Future-Proof Software-Systems Engineer

Apply & enforce

htt

p:/

/bis

cic

ol.blo

gspot.

ch

/2011/06/bis

cic

ol-

core

-soft

ware

-arc

hit

ectu

re.h

tml

Future-Proof Software-Systems: Lessons learned for FPSS

Lessons learned for future-proof software-systems:

Reference architectures, architecture frameworks and architecturepatterns are highly valuable containers of proven architecturalknowledge

The future-proof software-systems engineer needs a large knowledge


The future-proof software-systems engineer needs a large knowledgeof these architectural artefacts

Established, accepted and enforced reference architectures,architecture frameworks and architecture patterns are of great value toan organization and should be carefully managed

Future-Proof Software-Systems: Research Topics

Research Questions Master Thesis Level:• Apply the TOGAF architecture framework step by step to a ( simple) system ofyour choice


Research Questions Ph.D. Thesis Level:• Develop an architecture framework for the architecting of CPS (Cyber-PhysicalSystems)

• Develop an architecture framework for the architecting of Robotics Systems (seealso the program „MORSE“ of the University of Dresden)

Future-Proof Software-Systems: References

References:ReferencesFowler03 Martin Fowler:

Patterns of Enterprise Application Architecture

Addison Wesley, Boston, USA, 2003. ISBN 978-0-321-12742-0Vlissides98 John Vlissides:

Pattern Hatching – Design Patterns Applied

Addison Wesley Longman Inc., Reading MA, USA, 1998. ISBN 978-0-201-43293-5Buschmann96 Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal:

Pattern-Oriented Software Architecture - Volume 1

John Wiley & Sons, Chicester, UK, 1996. ISBN 978-0-471-95869-7Fernandez13 Eduardo B. Fernandez:

Security Patterns in Practice – Designing Secure Architectures using Software Patterns

John Wiley & Sons, Ltd., Chichester UK, 2013. ISBN 978-1-119-99894-5


John Wiley & Sons, Ltd., Chichester UK, 2013. ISBN 978-1-119-99894-5Hanmer07 Robert Hanmer:

Patterns for Fault-Tolerant Software

John Wiley & Sons, Chicester, UK, 2007. ISBN 978-0-470-31979-6Duffy04 Daniel J. Duffy:

Domain Architectures – Models and Architectures for UML Applications

John Wiley & Sons, Ltd., Chichester, UK, 2004. ISBN 978-0-470-84833-2Kindel09 Olaf Kindel, Mario Friedrich:

Softwareentwicklung mit AUTOSAR – Grundlagen, Engineering, Management in der Praxis

dpunkt.verlag GmvH, Heidelberg, 2009. ISBN 978-3-89864-563-8

See also: www.autosar.org [last accessed 29.8.2013]TOGAF11 The Open Group:

TOGAF Version 9.1 Enterprise Edition – An Introduction (White Paper)

The Open Group, San Francisco, USA, December 2011. Document Number W118. Downloadable from:

https://www2.opengroup.org/ogsys/jsp/publications/mainPage.jsp [last accessed 16.9.2013]BIAN12 BIAN (Banking Industry Architecture Network):

BIAN Metamodel Specification

Version 1.6, Iteration 13, May 30, 2012. Downloadable from: www.bian.org [last accessed 16.09.2013]


References:

ReferencesBIAN12 BIAN (Banking Industry Architecture Network):

BIAN Metamodel Specification

Version 1.6, Iteration 13, May 30, 2012. Downloadable from: www.bian.org [last accessed 16.09.2013]

Feiler13 Peter H. Feiler, David P. Gluch:

Model-Based Engineering with AADL – An Introduction to the SAE Architecture Analysis and Design Language

Addison-Wesley (SEI Series), N.J., USA, 2013. ISBN 978-0-321-88894-5



A7: Reuse and Parametrization




ArchitectureProcess


Structure



ArchitectureMetrics




Safety &Security

Architecture




TechnologyPortfolio

Management


Management

ServicePortfolio

Management






Future-Proof Software-Systems: Reuse and Parametrization

Definition:Reuse occurs when someone avoidshaving to write software by obtaining andusing software from someplace else[Jeffrey S. Poulin, 1997, ISBN 0-201-64313-9]

Reuse is:

Software Reuse http

://arto

fsoftw

are

reu

se.c

om

/ta

g/sch

em

as/


Reuse is:

• very powerful (strong contribution to agility)

• (very) difficult

• if not done correctly: dangerous for the architecture

Successful Reuse requires:

• a company-wide reuse strategy

• a strong reuse organization

• a dedicated, committed management


Types of Reuse

Black BoxReuseUnmodified (1:1) reuse


Grey BoxReuseLimited modified reuse(Specific changes 25 %)

White BoxReuseSignificantly modified(Specific changes 25 %)


Levels of Reuse

Contracts

Applications:Business Functions

Level 3: Services

Business Process

Workflow

Level 4:

BusinessRules


Functionality:Code

Data:DB-Schema

Level 1:

Encapsulated Functionality & Data:Components

Level 2: Interfaces

Business Functions


Value of Reuse

Contracts


Level 3: Services

Business Process

Workflow

Level 4:

BusinessRules

very high

medium


Functionality:Code

Data:DB-Schema

Level 1:

Encapsulated Functionality & Data:Components

Level 2: Interfaces

Business Functions

medium

local reuse

„global“reuse


Contracts


Services

Business Process

Workflow

BusinessRules

Services arecalled to buildapplications orsystems

Business rulesare reused toimplementbusinessprocess steps


Functionality:Code

Data:DB-Schema

Encapsulated Functionality & Data:ComponentsInterfaces

Business Functions

Codefragments

Fragments ofcode are reusedin programs

Componentsare composedto applications

systems


Business Case of Reuse€

t

ProjectDevelopmentCost

DevelopmentTime

one-timeuse Value

Development


€

t

Project

reuse

Value

DevelopmentCost

DevelopmentTime

Reusable Software


€

t

Project

reuse

Value

DevelopmentCost

Development

Reusable Software


DevelopmentTime

Who is paying?

htt

p:/

/blo

gs.law

yers

.com


The project has additional costand longer time-to-market

Reuse penalty

Pn+21

P

Projectcreating reusable

software Tra

deoff


Same projectcreating one-time software

Pn+5

Pn+1

Pn

All projects reusing the software havelower cost and shorter time-to-market

Reuse benefit

software

Pla

nn

ed

Tra

deoff


One-Time SoftwareDevelopment Process

SpecPhase

BusinessRequirements

ArchitectureRequirements

One-TimeSoftware

Development Process for Reuse

htt

p:/

/w

ww

.ham

mert

ap.c

om


Reusable SoftwareDevelopment Process

SpecPhase

BusinessRequirements

ArchitectureRequirements

ReusableSoftware

SpecPhase

BusinessSzenarios

Reuse ArchRequirements

htt

p:/

/w

ww

.ham

mert

ap.c

om


Elements for successful Reuseh

ttp:/

/w

ww

.am

isin

su

ran

ce.c

om

A dedicated andcommitted management

ReuseStrategy

A company-widereuse strategy


htt

p:/

/w

ww

.glo

baln

psolu

tion

s.c

om

A strongreuse organizationGood software

architects

http://artofsoftwarereuse.com/tag/schemas/



Why should we work with Reuse?


Because of:

• The benefits (in development cost and time-to-market) are considerable

• The quality of the software is higher (mature components, managedevolution and maintenance)

• Use of proven 3rd party components and services

• Optimization: reusable components on-time components



Which are the risks if we work with Reuse?


Risks:

• Quality of reusable software not sufficient

• Reuse-factor too low

• Reuse-strategy not complete or adequate

• Creation of unmanged redundancy (both functional and data)

• Development and maintenance process more complicated

• Management not sufficiently supportive of reuse-strategy


Types of Reuse

Black BoxReuse

Unmodified (1:1) reuse

Parametrization

Business Rules

True, value-generating Reuse


Grey BoxReuseLimited modified reuse(Specific changes 25 %)

White BoxReuseSignificantly modified(Specific changes 25 %)

Not reuse unmanaged redundancy

Not reuse unmanaged redundancy


Grey Box

Grey Box Modification Divergence (Unmanaged Redundancy)

Grey Box

Modification A

GreyBox

Modifi-

catio

nB

Change


Grey Box

B

Grey Box

Modifi-cation C

GreyBox

Modifi-cation

D


Parametrization and Business Rules

Black BoxReuse

Unmodified (1:1) reuse

Parametrization

Business Rules


Parametrization: Selection of a predefined behaviour of the black boxby parameters stored outside of the black box (Not part of the black boxfunctionality or data). The parameters are loaded at run-time. Newversions of the black box interpret the parameters correctly.

Business Rules: Business rules are specified in BR-languages anddefine processing logic – instead of having the processing logicimplemented in code within the black box (Not part of the black boxfunctionality or data). The business rules are loaded at run-time. Newversions of the black box interpret the business rules correctly


Black Box Usage (Managed Redundancy)

Black Box

Black Box

Black Box

Parametrization

Business Rules

Change

Loaded/Initializedat Run-Time


Black Box

Black Box

Black Box

Parametrization

Business Rules

Parametrization

Business Rules

Distributed/Updatedby ConfigurationManagement System


Parametrization Example: Different Account Number Formats

Payment OrderAccount Number Format: Bank Leu

Payment OrderAccount Number Format: CREDIT SUISSE

PaymentApplication

Clearing


Payment OrderAccount Number Format: IBAN

Payment OrderAccount Number Format: Future Format

Application

Accounts DB

System


Business Rules Example

Business Process

Application Software

Verbal Expression:

“A car with accumulatedmileage greater than 5’000since its last service mustbe scheduled for service”


BusinessLogic

SpecificBusiness

RulesInterpreter

Formal Expression:

If Car.miles-current-period > 5000 then

invoke Schedule-service (Car.id)

End if


Measuring the Reuse-Factor:

Contracts

Applications:

Services

Business Process

Workflow

BusinessRules

# ofapplications

using theservice

% of reusedbusiness rulesin a different

context


Functionality:Code

Data:DB-Schema

Encapsulated Functionality & Data:ComponentsInterfaces


Codefragments

service

# of calls/hour

# ofapplications

using thecomponent

# of componentsimplementingthe code/DB

fragment

Future-Proof Software-Systems: Industry Standards


Reuse and Parametrization

1. Use only the black-box concept to build reusable software

2. Whenever possible, configure the reusable modules via parametersor business rules (loaded or initiated at run-time)

3. Install and consequently use a configuration management systemto control the distribution of reusable software modules

A7


4. Provide the 4 elements of successful reuse: Committedmanagement, reuse-strategy, reuse-organization and competent

software architects

5. Adapt your software development process to produce reusablesoftware

Justification: If done correctly, reuseable components have asignificant effect on the agility of the IT-system.



If done correctly, reuseable components have a significant (positive)effect on the agility of the IT-system

Use only the black-box concept (= unmodified reuse) to buildreusable software


Parametrization and business-rules are powerful instruments toadapt reusable software to different contexts

Successful reuse is only possible if 4 prerequisites are met:Committed management, an adequate reuse-strategy, an effectivereuse-organization and competent software architects

The software development process for reusable software is morecomplex than for one-time software


Research Questions Master Thesis Level:• Study the different reuse-concepts in some application areas (banking,automotive, aerospace etc.) from literature and compare them. Describecommonalities and differences. Formulate recommendations for application-independent reuse

Research Questions Ph.D. Thesis Level:• Investigate the different software development processes focused on producing


• Investigate the different software development processes focused on producingreusable software artefacts (from literature). Distill the good points and elaborateon the weak points. Define a strong process for the whole life-cycle of reusablesoftware development, including both local (inside the company) and global (reuseof external services). Put special emphasis on mechanisms to detect, avoid andeliminate unmanaged redundancy


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-5Lim98 Wayne C. Lim:

Managing Software Re-Use

Prentice Hall, USA, 1998. ISBN-13: 978-0-13552-3735-9Coulange98 Bernard Coulange:

Software Reuse

Springer-Verlag, Heidelberg, Berlin, 1998. ISBN 978-3-540-76084-9Leach13 Ronald J. Leach:

Software Reuse – Methods, Models, Costs

Ronald J. Leach Publishing, 2nd edition, 2013. ISBN 978-1-9391-42-35-1


Ronald J. Leach Publishing, 2 edition, 2013. ISBN 978-1-9391-42-35-1Hamlet10 Dick Hamlet:

Composing Software Components – A Software-Testing Perspective

Springer-Verlag, New York, N.Y., USA, 2010. ISBN 978-1-44197147-0Poulin97 Jeffrey S. Poulin:

Measuring Software Reuse – Principles, Practices, and Economic Models

Addison Wesley Longman Inc., Reading MA, USA, 1997. ISBN 0-201-63413-9Grunske10 Lars Grunske, Ralf Reussner, Frantisek Plasil (Editors):

Component-Based Software Engineering

13th International Symposium CBSE 2010 (June 2010). Springer-Verlag, Berlin & Heidelberg, 2010 (LNCS6092). ISBN 978-3-642-13237-7

Arbab12 Farhad Arbab, Peter Csaba Ölveczky (Editors):

Formal Aspects of Component Software

8th International Symposium FACS 2011 (September 2011). Springer-Verlag, Berlin & Heidelberg, 2012 (LNCS7253). ISBN 978-3-642-35742-8

Vliet08 Hans Van Vliet:

Software Engineering – Principles and Practice

John Wiley & Sons, Chichester, UK, 3rd edition 2008. ISBN 978-0-470-03146-9


A8: Industry Standards




ArchitectureProcess


Structure



ArchitectureMetrics




Safety &Security

Architecture




TechnologyPortfolio

Management


Management

ServicePortfolio

Management







A STANDARD is:

• a formal, established norm for (technical) systems

• a document which establishes uniform (engineering or technical) criteria,principles, methods, processes and practices


www.ietf.org www.omg.orgwww.iso.org

International Standards Organizations

CS

BusinessObjectModelV1.1/2009

CompanyStandards


Example:Napoleonic Guns(1/3)

htt

p:/

/civ

ilw

art

alk

.com

/th

reads/la

rgest-

reen

acto

r-can

on

.79423


htt

p:/

/civ

ilw

art

alk

.com

/th

reads/la

rgest

In early pre-Napoleonic times (18xx) the artillery cannons were individuallydifferent and required matched cannon balls difficult logistics

Manufacturing tolerances greatly reduced the accuracy and firing power ofthe artillery cannons reduced military impact


Example: Napoleonic Guns(2/3)

de Gribeauval standard:

• reduced and standardized the calibers

complexity reduction

• introduced normalized parts for the cannons

component technology

• set manufacturing processes & tolerances

reuse


1776: The de Gribeauvalstandard revolutionizedartillery.

1715-1789

Results: Massively improved military impact Mass production of cannons


Example: Napoleonic Guns(3/3)

htt

p:/

/w

ww

.san

dro

caste

lli.com

/w

ork

s_p

agin

as/n

apole

on

sem

pir

e.h

tm


htt

p:/

/w

ww

.san

dro

caste

lli.com

/w

ork

s_p

agin

as/n

apole

on

sem

pir

e.h

tm

NapoleonicEmpire

(ca. 1810)


What is the impact of standards ?

Why are standards important ?

Impact:

• Forcing uniform, interoperable solutions in the industry

• Providing proven, widely accepted and mature solutions

• Enabling exchangeable products (mostly)

• Facilitates reuse


• Foundation for validation & certification

Importance:

• Provides long term stability with managed change

• Forces vendors to comply to interoperable solutions

• Advances industries as a whole

• Provides confidence in technical solutions (e.g. safety or security)

Negative: Standards-setting process is quite slow (Wide consensus required)



Industry Standards

1. Strictly adhere to proven, accepted industry-standards in all 5architecture layers and for all phases of the system lifecycle

2. Never allow any use of vendor-specific standards extensions (evenif they look tempting and useful)

3. Keep the number of standards in use to a minimum

A8


4. Introduce new standards only based on very good reasons

5. If for a certain field of your activity there is no industry standard,formulate and instantiate a company standard

6. Enforce strict adherence to (pure) standards via regular reviews

Justification: A heterogenous industry (such as software-production)requires clearly stated foundations for technologies, products andprocesses – otherwise no interoperability, certification, reuse andvendor-independence is possible


Example:WebStandards(1/3)

Web

Domain-specificStandards

Cry

pto

gra

ph

y

Trust: PKI

Reasoning & Proofs

BusinessRules:

Underlying Logic: DL

Semantics(Ontology):DB Query:

Business Applications

SOA-Infrastructure: Web-Services

How can weestablish trust onthe WWW?


WebStandards

TechnicalInfrastructureStandards

Technical Infrastructure

Addressing: URI Unicode

Secu

rity

:C

rypto

gra

ph

y

Rules:RIF

(Ontology):OWL

DB Query:SPARQL

Vocabulary: RDF-S

Data Model: RDF

Syntax: XML


Example:WebStandards(2/3)

htt

ps:/

/en

cyclo

pedia

dra

mati

ca.s

e/O

n_t

he_I

nte

rnet,

_nobody_kn

ow

s_you

're_a_dog

Example: Authentication:

How can we establish trust in theidentity of an electronic partner ?

Trust: PKI

Answer:

We use aPublic Key Infrastructure (PKI)

Answer:

Use a Public Key Infrastructure(PKI)

PKI assigns Digital Certificates

Answer:



Answer:




htt

ps:/

/en

cyclo

pedia

dra

mati

ca.s

e/O

n_t

he_I

nte

rnet,

_nobody_kn

ow

s_you

're_a_dog

On the Internet, nobody knows you're a dog

PKI assigns Digital Certificatesto entities (Persons, organizations)PKI assigns Digital Certificatesto entities (Persons, organizations)

A digital certificate is anunforgeable electronic proof ofidentity

PKI assigns Digital Certificatesto entities (Persons, organizations)

A digital certificate is anunforgeable electronic proof ofidentity

Digital certificates arestandardized in X.509 and areglobally accepted and used


Example: Web Standards(3/3) CA

Certification Agency[Trusted Entity]

X.509Certificate

_issuer_validity_subject_publicKey

_CA-Signature

X.509

Copyright Frank J. Furrer 2013 55Client

Server

_CA-Signature

X.509

presents



Standards are highly important instruments for a number of ITfunctions, such as interoperability, security, safety, certification, …

A sufficient (but not overlapping) set of standards should be used,managed and enforced in an organization


No vendor-specific standards extensions (even if they look temptingand useful) should be used

The set of standards established in an organization represents aconsiderable business value

As an architect, look at the standards as a help, not a nuisance


Research Questions Master Thesis Level:• Develop a process for a (fictive) organization to evaluate, select, introduce,enforce and manage an optimum set of standards (Industry-standards and –where not available – company standards)

• Select a specific application domain (e.g. automotive, aerospace, medical,industrial, railway, … and examine their standards in use. Demonstrate the valueof the application and enforcement of this set of standards and the risks if failingto do so


Research Questions Ph.D. Thesis Level:• none


References:

ReferencesAkerkar09 Rajendra Akerkar:

Foundations of the Semantic Web – XML, RDF & Ontology

ALPHA Science Intl. Inc., Oxford, UK, 2009. ISBN 978-1-84265-535-1Jakobs00 Kai Jakobs:

Information Technology Standards and Standardization – A Global Perspective

Idea Group Publishing, Hershey, PA, USA, 2000. ISBN 1-878289-70-5Nash01 Andrew Nash, William Duane, Celia Joseph, Derek Brink:

PKI – Implementing and Managing E-Security

Osborne/McGraw Hill, CA, USA, 2001. ISBN 0-07-213123-3Katz08 Jonathan Katz, Yehuda Lindell:

Introduction to Modern Cryptography


Introduction to Modern Cryptography

Chapman & Hall/CRC, FL, USA, 2008. ISBN 978-1-58488-551-1Hafner09 Michael Hafner, Ruth Breu:

Security Engineering for Service-Oriented Architectures

Springer Verlag, Heidelberg, Germany, 2009. ISBN 978-3-540-79538-4Al-Hakeem12 Mazin S. Al-Hakeem:

Fundamentals of Web Engineering – An Engineering Approach to Develop Web Services, Contents &Environment under Standards Specification of Web Design

LAP LAMBERT Academic Publishing, 2012. ISBN 978-3-65912-492-1Sahai05 Akhil Sahai, Sven Graupner:

Web Services in the Enterprise – Concepts, Standards, Solutions, and Management

Springer-Verlag, Heidelberg, Berlin, 2005. ISBN 978-0-387-23374-1Dawson07 Anthony L. Dawson, Paul L. Dawson, Stephen Summerfield:

Napoleonic Artillery

Crowood Press Ltd., Wiltshire, UK, 2007. ISBN 978-1-86126-923-2


A9: Information Architecture




ArchitectureProcess


Structure



ArchitectureMetrics




Safety &Security

Architecture




TechnologyPortfolio

Management


Management

ServicePortfolio

Management






Future-Proof Software-Systems: Information Architecture



IT-System

Data,Information

FunctionalityDocumentation,

Models etc.


InformationFunctionality

Models etc.

Technical Infrastructure

Software Structure,Relationships

Repository

Data/InformationArchitecture


Business Model… how to earn money

Business Processes… how to execute the business

operations

Information Architecture Stack:

Enterprise Model

Business Logic Model

Legal&

Com

plian

ce

Model

Con

tin

uit

y&

Dis

aste

rM

odel

Model

Information Architecture

En

tities

&R

ela

tion

sh

ip


Databases/Tables… persistent storage of business

entities & transactions

operations

Applications/Components… Implementation of business

operations

Domain ModelBusiness Object Model

Database/TableModels

Legal&

Com

plian

ce

Model

Bu

sin

ess

Con

tin

uit

yR

ecovery

Model

Deplo

ym

en

tM

odel

&R

ela

tion

sh

ipD

efin

ition

s






Architecture Principle A?:

X

1. Strictly

Ax


Justification: A





Research Questions Master Thesis Level:•


Research Questions Ph.D. Thesis Level:•


References:References

Lehner13 Wolfgang Lehner, Kai-Uwe Sattler:

Web-Scale Data Management for the Cloud

Springer-Verlag, Heidelberg, 2013. ISBN 978-1-4614-6855-4



A10: Formal Modeling




ArchitectureProcess


Structure



ArchitectureMetrics




Safety &Security

Architecture




TechnologyPortfolio

Management


Management

ServicePortfolio

Management






Future-Proof Software-Systems: Architecture

Business Architecture Layer

architecting

Application (Software) Architecture Layer

Business area:Financial institution

Example:„Customer“

DatabaseSchema

Attributes:Name: …Address: …Date of birth: …etc.

Concept: Account1…*1…*

association

Database Design

BusinessContinuity& DisasterRecoveryPlan



Servicedesign

Access

con

trol

Concept: Customer

„A person or organizationbuying goods or servicesfrom our organization“


Technical Infrastructure Architecture Layer

Infrastructure Services

Deployment Architecture Layer

DR

A DCB

Archive

Disk

Enterprise BusDisk

DiskDisk

Ta-peTa-

peMain-frameMain-

frameMain-frame

ServerServer

Server

Future-Proof Software-Systems: Formal Modeling


Future-Proof Software-Systems: Formal Modelingh

ttp

://w

ww

.nam

e-lis

t.n

et/i

mg/

imag

es.p

hp

/Go

del

_5.jp

g Expressivity

Time

very high

high

medium

DL

DL = Description Logic

un

decid

able


Type

hybrid

discretecontinuous

dynamic

static

low

htt

p:/

/ro

.mat

h.w

ikia

.co

m/w

iki/

Geo

rge_

Bo

ole

0,1,,

decid

able



5: Communications & Collaboration

Business Partner Applications (BPA) Financial Instruments, Research & Market Data (FIN)Enterprise Content Management (ECM)

Client Communication (CHA) Street Side Interfaces (SSI)

,In

vest

me

nt

&Sa

les

Ma

rke

ts

Op

era

tio

ns

Wealth Management &Advisory

(WMA)

an

dR

ep

ort

ing

Regu

lato

ry,

Ris

kan

dLiq

uid

ity

(RR

L)

Trading

(TRA)

Payments

(PAY)

Single Accounts

(SAC)

Copyright Frank J. Furrer 2013/14 74

1:

Pa

rtn

ers

&P

ers

on

s

2:

Fin

an

ce,I

nve

stm

en

t&

Sale

s

3:

Tra

din

ga

nd

4:

Ca

sha

nd

Ass

et

Op

era

tio

ns

Cu

sto

mer

&Part

ner

(CU

S)Credits and Syndication

(CRS)

6:

Acc

ou

nti

ng,

Co

ntr

oll

ing

an

d

Fin

an

cia

lA

ccou

nti

ng

(FA

C)

Regu

lato

ry,

Ris

kan

dLiq

uid

ity

(RR

L)

Accounting Control

(AOC)

Logistics

(LOG)

Basic Facilities

(BAS)

Product Control

(PRC)

Settlement and Clearing

(SCL)

Custody(CDY)

Corporate Actions

(COA)

7: Enterprise Common Services


Domain Model & Business Object Model


DB-People: ERD


Quality of Models (Krogstie)




Formal Modeling

1. Strictly

A10


Justification: A







Research Questions Ph.D. Thesis Level:•



Plösch04 Reinhold Plösch:

Contracts, Scenarios and Prototypes – An Integrated Approach to High Quality Software

Springer-Verlag, Berlin Heidelberg, 2004. ISBN 978-3-540-43486-0



A11: Systems-of-Systems(SoS)




ArchitectureProcess


Structure



ArchitectureMetrics




Safety &Security

Architecture




TechnologyPortfolio

Management


Management

ServicePortfolio

Management






Future-Proof Software-Systems: Systems-of-Systems (SoS)

What is a system-of-systems ?# of stakeholders (users, providers, …)

size (SLOC‘s)

108

106

104

102

1012109106103

System-of-

SystemsMega-System

MonolithicSystem


Monolithic systems Systems-of-systems:

1. Operational Independence of the Elements

2. Managerial Independence of the Elements

3. Evolutionary Development

4. Emergent Behavior

5. Geographic Distribution [5 Maier criteria, 1998]

Managerial Independence of the Elements

Emergent Behaviour

Governance

Total = more thanthe sum of its parts


SoS (Systems-of-systems) Definition:

Definition:

A system-of-systems is a large, complex, enduring collection ofinterdependent systems

under development and operation of independent governance authorities

to provide multiple, interdependent capabilities to support various missions

Adapted from [Kaplan06]


Definition:

System-of-systems engineering is a set of coordinated cross-system andcross-community processes

that ensure the development and evolution of mission-oriented capabilities

to meet multiple stakeholders’ evolving needs across periods of time thatexceed the lifetimes of individual systems

Adapted from [Kaplan06]


SoS Example: AMAZON Businessh

ttp:/

/seekers

port

al.w

ord

pre

ss.c

om

orderbook

Governance Boundary 1GovernanceAuthority

1


htt

p:/

/seekers

port

al.w

ord

pre

ss.c

om

http://blog.winepresspublishing.com

supply bookstransport book

deliver book

GovernanceAuthority

2

GovernanceBoundary 2

GovernanceAuthority

3

Governance Boundary 3


SoS (Systems-of-systems) Terminology

CSA

CSE

CSD CS

G

CSB

CSN

ConstituentSystem (CS)

DependencyMission


CSI

CSH

CSF

CSC

CSMCS

L

CSK

System-of-Systems(SoS)

Stakeholders


Emergence Desirable/positive Undesirable/negative

Expectedemergentbehavior

Reason for building theSoS (SoS objective)

Mitigate by appropriate designmeasures, such as threat/risk analysisand countermeasures

SoS Emergent Behaviour Classification


Unexpectedemergentbehavior

Sometimes (however,quite rarely) an SoSshows unexpected,beneficial behaviour

Unexpected & undesirable negativeemergent behavior is one of the criticalrisks of most SoS


Example 1 for emerging properties: „flying“ (desirable/positive)h

ttp:/

/w

ww

.mskgm

bh

.com

Constituent systems of an aircraft:• engines• body• wings• cockpit• etc.

… none of the constituent systems is able to fly !


http

://en

.wik

ipedia

.org

/w

iki/

Airb

us_A

320_fa

mily

Assemble the essentialconstituent systems:Emerging property: the assembly(= airplane) is able to fly !


Example 2 for emerging properties: landing crash (undesirable/unexpected)h

ttp:/

/avio

ners

.net/

2011/03/air

bu

s-a

319-a

ppro

ach

-to-l

an

din

g.h

tml

Constituent systems:

• Airplane (DC-8)

• Airport (Runway)


htt

p:/

/avio

ners

.net/

2011/03/air

bu

s

October 8, 1979: Swiss Air Flight 316overran the Athens runway – 14 deaths

Cause: „Interface“ between therunway and the airplane

• Landing when braking action isless then good

• Crew mistakes


Managerial Independence: Governance

Definition:

Governance is the exclusive, non-overlapping right of a governance authority

to change any element (such as systems, relationships, operating parameters etc.)

located within the respective governance boundary

„The three devils of systems engineering are:

Complexity,

Change,

en

gin

eeri

ng


In a SoS we have new dimensions of:

• Complexity management

• Change management

• Operational challenges

• Risk assessment and mitigation

Change,

Uncertainty”Anonymous

Syste

ms-o

f-syste

ms

en

gin

eeri

ng


CSA

CSE

CSD CS

G

CSB

CSN

Governance Boundary 1GovernanceAuthority

1

Managerial Independence: Governance


CSI

CSH

CSF

CSC

CSMCS

L

CSK

GovernanceAuthority

2

GovernanceBoundary 2

GovernanceAuthority

3

Governance Boundary 3


CSA

CSE

CSD CS

G

CSB

CSN

GovernanceAuthority

1

Managerial Independence: Governance by Contract

CollaborationContract

• functional• operational• commercial

• legal


• functional


CSI

CSH

CSF

CSC

CSMCS

L

CSK

GovernanceAuthority

2

GovernanceAuthority

3



• legal


• legal


SoS Engineering: Carmaker & System suppliersh

ttp:/

/sdarc

hit

ect.

word

pre

ss.c

om

SoS-Engineering = Cross-

system and cross-community

engineering collaboration

SoS-Engineering =

Intelligent and effective


htt

p:/

/sdarc

hit

ect.

word

pre

ss.c

om



• legal

distribution of governance


… now we understand SoS‘s and their challenges

… what does it mean for our future-proof software-systems?

CSA

CSE

CSD CS

G

CSB

CSN

Mission


CSI

CSH

CSF

CSC

N

CSMCS

L

CSK

1) Transparent architecture

2) Explicit dependencies

3) Complete contracts

4) Risk mitigation

5) Monitoring and earlyresponse


System-of-Systems[SoS]

Mission [M]1 1

is defined by

Governance[Gov]1

1

is delineated by

1..*

ConstituentSystem Domain

[CSD]

CooperationDomain

[CD]

1..* 1..*

1

1..*

interconnects

1..*

Coordinator[CE]

1

Mission Owner[MO]

1 1

implements

ChangeManagement

BudgetAuthority

1

11

1

governs

Environment 1 1..*

interacts

1..*

CooperationStandards

[CS]

1..*1 enforces

Users

1 1..*

benefit


ConstituentSystem

[CS]

Process[Proc]

1..*1..*1..*1..*

CooperationMechanism [CE]

CooperationContract [CC]

ManagementOwnership

Authority[CS]

Global(synchronized)

Time

delivers

Function [F]

utilizes

1..*Function Owner

[FO]

1..* 1

manages

Capability [C]

1..*

builds

1..*

1..*

1

1) Transparent architecture:SoS Structural Model

Furrer/Kopetz 2013


System-of-Systems[SoS]

Mission [M]1 1

is defined by

Governance[Gov]1

1

is delineated by

1..*

ConstituentSystem Domain

[CSD]

CooperationDomain

[CD]

1..* 1..*

1

1..*

interconnects

1..*

Coordinator[CE]

1

Mission Owner[MO]

1 1

implements

ChangeManagement

BudgetAuthority

1

11

1

governs

Environment 1 1..*

interacts

1..*

CooperationStandards

[CS]

1..*1 enforces

Users

1 1..*

benefit


ConstituentSystem

[CS]

Process[Proc]

1..*1..*1..*1..*

CooperationMechanism [CE]

CooperationContract [CC]

ManagementOwnership

Authority[CS]

Global(synchronized)

Time

delivers

Function [F]

utilizes

1..*Function Owner

[FO]

1..* 1

manages

Capability [C]

1..*

builds

1..*

1..*

1

1) Transparent architecture:SoS Structural Model

Furrer/Kopetz 2013





Systems-of-Systems (SoS)

1. Develop and maintain a transparent, complete, up-to-date, welldocumented architecture for the SoS

2. Fully understand and (formally) specify all dependencies

3. Fully understand and (legally) specify the governance of the SoS

4. Define all dependencies by formal contracts

A11


4. Define all dependencies by formal contracts

5. Use effective risk analysis and mitigation for the early detection ofoperational faults, errors or unwanted emergent behaviour

Justification: A



Many of the interesting and useful systems are „Systems-of-systems“

In a system-of-systems the architect and the management of aspecific constituent system loose considerable (direct) governance

The loss of (direct) governance must be compensated by completecontracts (functional, non-functional, legal etc.)


contracts (functional, non-functional, legal etc.)

Emerging properties – especially unknow or unwantednegative/harmful properties – are a considerable risk in many SoS‘s

Risk management & risk mitigation becomes a central issue in thedevelopment, operation and evolution of SoS‘s

Operational monitoring of the SoS‘s operation for the early detectionof faults, failures, emerging properties is important




Research Questions Ph.D. Thesis Level:• Develop a modeling framework for SoS-architecture (based on the many different,but unsatisfactory approaches in the literature

• Develop a modeling framework for SoS-governance, including the necessarycontract syntax and semantics for the implementation and operational monitoring

• Develop a modeling framework for emergent behaviour of an SoS. Include theoperational monitoring and risk mitigation measures


References:ReferencesMaier98 Mark W. Maier:

Architecting principles for systems-of-systems

Systems Engineering, Volume 1, Issue 4, 1998. Pages 267–284

Downloadable from: http://www.infoed.com/Open/PAPERS/systems.htm [last accessed: 26.12.2012]



A12: Complexity andSimplification




ArchitectureProcess


Structure



ArchitectureMetrics




Safety &Security

Architecture




TechnologyPortfolio

Management


Management

ServicePortfolio

Management






Future-Proof Software-Systems: Complexity and Simplification

htt

p:/

/blo

g.d

igit

al.te

lefo

nic

a.c

omComplexity

• Biology• Sociology• Astronomy• Physics• …• Information Technology (IT)


“Complexity is that property of an IT-system which makes it difficult to formulate its overallbehaviour, even when given complete information about its parts and their relationships“

Complexity = (IT-) Risk


Example: FAA Air Traffic Control System

1995: The FAA (US Federal AviationAgency) admits the colossalmodernization failure of the AdvancedAutomation System (AAS). That efforttook 16 years of effort and costtaxpayers $23 billion

htt

p:/

/w

ww

.in

form

ati

on

week.c

om

/664/64iu

faa.h

tmh

ttp:/

/cla

rion

con

ten

tmedia

.com


htt

p:/

/w

ww

.in

form

ati

on

week.c

om

/664/64iu

faa.h

tm

“FAA did not recognize the technical complexity of the effort,realistically estimate the resources required, adequately oversee itscontractors' activities, or effectively control system requirements"


Complexity = (IT-) Risk

good bad

• Complexity makes large,useful systems possible

• It forces us to develop sciencefor dealing with complexity

• it is a highly interesting and

• It is the single most importantreason for disasters in IT

• It makes understanding,explaining and evolving IT-systemsvery hard


Complexity must be managed !

• Identify it• Understand it• Avoid and reduce it as much as possible

fruitful area of research • It may lead to unpredictable(= emergent) behaviour


ComplexityKnown (identified)Complexity

Unknown (hidden)Complexity

Necessary (desired)Complexity[Essential Complexity]

manage it use it carefully

Managing Complexity:


Unnecessary(undesired)Complexity[Accidental Complexity]

avoid iteliminate it

attack it


FF

F

F

F

F

F

FF

F

F

FF

F

F

F

F

FF

F

F

F

F

F

FF

Reminder: „Partitioning & Encapsulation“

IF

IF

IF

IF

IF

IF

IF

IF

IF

IF

IF


FFF

F

FF

FF

F

FF

FFF

F F

FF

FF

F

Partinioning:Encapsulation Unit

IF

IF

IF

IF

IF

IF

IFIFIFIF

IF IF

IF

IF

IF IF

IF

IF

IFIFIF Encapsulation:

Interface


System Complexity System Boundary (Governance !)

Functionalcomplexity ofinternalinterfaces

Functionalcomplexity ofexternalinterfaces


Numberof Parts(EncapsulationUnits)

Numberof internaldependencies

Numberof externaldependencies


Complexity Contributors:

Contributor Metric

Number of Parts (Structural complexity) Integer number (NP)

Number internal dependencies (Structural complexity) Integer number (NiD)

Number external dependencies (Structural complexity) Integer number (NeD)

Functional complexity of internal interfaces # of FP, UCP (FiIj)

Functional complexity of external interfaces # of FP, UCP (FeIk)


Functional complexity of external interfaces # of FP, UCP (FeIk)

A number of complexity metrics exist in the literature.

However, none of them is satisfactory for engineering system complexity

Interesting open research question (PhD-Level) !

Complexity Metric:

SysCompl = f[NP,NiD,NeD,FiIj,FeIk]


Sources of unnessery and unknown complexity:

Specifications: overlaps, duplication

Redundancy: functional, data & interface redundancy

Lack of conceptual integrity: diverging concepts, misunderstandings

Disregard of (industry) standards: technology explosion

3rd party software: forced, incompatible concepts, redundancy


If you don‘t properly manage complexity, it may kill your IT-system

Neglected legacy systems: old technology, out-of-use components

Inconsistent housekeeping: „dead“ code & data

Diversity in vertical architectures: proliferation of solutions


The nasty ways of complexity:

Complexity creeps up, incrementally growing over long time

Complexity occurs locally in many different specifications, programs andinterfaces, but its impact is global

Complexity may grow to such a state, that the IT-system becomesunmanageable or commercially unviable


How can we manage complexity ?

a) Implement a process step „simplification“ in your development process

b) Periodically carry out re-architecture programs „complexity reduction“

Containing complexity growth requires continuous and substantialmanagement intervention and strong management committment


Implement a process step „simplification“ in your development process

Reqs Specs Arch Design Build TestSimplify

Check-list


Periodically carry out re-architecture programs „complexity reduction“

http://blogs.proquest.com

Application Landscape

Technology Portfolio

Re-Architecture Program 2014 Eliminate … Refactor … Replace … Redesign …

etc.

Effort:1‘100 MM

Cost:27 M€


Complexity Reduction Simplification Process Architecture Exploration

NewRequirements

(Functional & Quality)

Business

newchanged

Arc

hite

ctu

reD

evelo

pm

ent

Arc

hite

ctu

reE

valu

atio

n


Arc

hite

ctu

reIm

ple

men

tatio

nA

rch

itectu

reE

valu

atio

n

• Functional Reqs• Quality Properties

• Fit into Legacy• Refactoring

• …



Complexity and Simplification

1. Actively manage the complexity in your system:• Identify it• Understand it• Avoid and reduce it as much as possible

2. Install a formal, controlled process step „simplification“ in your designand evolution procedures

3. For any (substantial) set of requirements develop several possible

A12


3. For any (substantial) set of requirements develop several possiblearchitectures and use an architecture assessment method to select the

most suitable

4. Periodically execute re-architeture programs with the objective to reducethe complexity of the IT-system

Justification: Complexity is the largest single risk in IT-systems. Bymanaging complexity, the unwanted or unnecessary complexity can bereduced – thus making the IT-system more agile, manageable anddependable.

Architecture Topic Map


Functionality

Architecture-Quality:

Requirements• Req A• Req B•…• Req Y

Fu

ture

-Pro

ofS

oftw

are

-Syste

mE

ngin

eer


Architecture-Greatness:• Simplicity• Elegance

Architecture-Quality:• Agility• Availability• Security• Safety• Performance• …

http

://de.1

23rf.c

om

Syste

mE

ngin

eer



System complexity can be classified in a matrix necessary/unecessaryand known/unknown

The unnecessary and the unknown complexity are a high danger forthe IT-systems. They are the single most important source of IT-risk


Consequent active simplification is a measure to reduce and eliminateunwanted complexity

Active simplification consists of a simplification step in thedevelopment process and of periodic re-architecture programs to reducecomplexity in the applications landscape and in the technology portfolio

The highest talent which a good future-proof software-systemsengineer can have is to produce simple and elegant architectures


Research Questions Master Thesis Level:• Compile a comprehensive list of complexity metrics – especially for engineeringsystems – from the literature. Show examples of their use, value and restrictions.

Research Questions Ph.D. Thesis Level:


Research Questions Ph.D. Thesis Level:• Investigate and assess all existing system complexity measures in literature.Develop a suitable engineering system complexity metric which can be used in thesimplification of architecture design (architecture exploration) for future-proofsoftware-systems. Define the process for measurement, interpretation and use ofthe complexity metric.


References:

ReferencesSessions09 Roger Sessions:

The IT Complexity Crisis – Danger and Opportunity. White Paper,

November 2009. Downlodadable from:

http://www.objectwatch.com/whitepapers/ITComplexityWhitePaper.pdf (last accessed: 8.2.2013)Sessions08 Roger Sessions:

Simple Architectures for Complex Enterprises

Microsoft Press, Redmond, USA, 2008. ISBN 978-0-7356-2578-5Kopetz11 Hermann Kopetz:

Real-Time Systems – Design Principles for Distributed Embedded Applications

Springer-Verlag, New York, USA. 2nd edition 2011. ISBN 978-1-4419-8236-0Rajan13 Ajitha Rajan, Thomas Wahl:


Rajan13 Ajitha Rajan, Thomas Wahl:

CESAR - Cost-efficient Methods and Processes for Safety-Relevant Embedded Systems

Springer Verlag, Berlin, Heidelberg, 2013. ISBN 978-3-709-11386-8Spinellis09 Diomidis Spinellis, Georgios Gousios (Editors):

Beautiful Architecture – Leading Thinkers Reveal the Hidden Beauty in Software Design

O’Reilly Media, USA, 2009. ISBN 978-0-596-51798-4Clements02 Paul Clements, Rick Kazman, Mark Klein:

Evaluating Software Architectures – Methods and Case Studies

Addison-Wesley, Boston, USA, 2002. ISBN 0-201-70482-XGell-Mann94 Murray Gell-Mann:

The Quark and the Jaguar – Adventures in the Simple and the Complex

Abacus (Hachette UK), London UK, 1994. ISBN 978-0-349-10649-6Leukert11a Peter Leukert, Andreas Vollmer, Bart Alliet, Mark Reeves:

IT Complexity metrics – How do you measure up?

CAPCO Inc., Washington DC, USA, White Paper 2011. Downloadable from; www.capco.com [last accessed29.9.2013]


Appendix: Additional Topics




ArchitectureProcess


Structure



ArchitectureMetrics




Safety &Security

Architecture




TechnologyPortfolio

Management


Management

ServicePortfolio

Management






Future-Proof Software-Systems: Additional Topics

Software Product Lines


Future-Proof Software-Systems: Software Product Lines









Resilient Software Systems


http://fcw.com/articles/2013/07/08/exectech-operational-resilience.aspx

Future-Proof Software-Systems: Resilience






References:

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

Resilience Engineering – Concepts and Precepts

Ashgate Publishing Ltd., Aldershot, UK, 2006. ISBN 978-0-7546-4904-5Leveson11 Nancy G. Leveson:

Engineering a Safer World – Systems Thinking applied to Safety

MIT Press, Cambridge MA, USA, 2011. ISBN 978-0-262-01662-9Axelrod13 C. Warren Axelrod:

Engineering Safe and Secure Software Systems

Artech House, Norwood, USA, 2013. ISBN 978-1-60807-472-3Brenner11 Joel Brenner:

America the Vulnerable – Inside the New Threat Matrix of Digital Espikonage, Crime, and Warfare


Penguin Press, New York, USA, 2011. ISBN 978-1-59420-313-8Merkow10 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

Future-Proof Software-Systems: Cloud Computing Architecture

Cloud Computing Architecture


http://ec.europa.eu/commission_2010-2014/kroes/en/tags/cloud-computing


Cloud Definitions:

SaaSSoftware as a Service

PaaSPlatform as a Service

http://www.salesforce.com/eu

Application

End-User

Developper


IaaSInfrastructure as a Servicehttp://www.rackspace.com

http://www.windowsazure.com/en-us

System Manager


Cloud Definitions:



Application

End-User

Developper


Cloud =Execution andDeliveryStructure

IaaSInfrastructure as a Service

System Manager

Cloudservice

consumer

Cloudserviceprovider

„pay as you go“

Cloud Definitions:



Application

End-User

Developper



System Manager


Cloud Benefits:

SaaS

PaaS

Benefits for the Cloud Service Consumers:

• Minimal investment

• Low running/operational cost

• Technology-independent

• No vendor lock-in

• Short time-to-market („assemble“ instead of „build“)

• Choose „best of breed“

• Simple up-/downscaling


IaaS

Cloud = Executionand Delivery Structure

Cloud Usage =Commercial decision(Business model)

Benefits for the Cloud Service Providers:

• Large market

• No copying, no IPR disclosure

• Economy of scale

• Interesting new business models

• Specialization


Cloud Risks:

SaaS

PaaS

Company& Personal

Data

Unauthorized access,hacking

PrivacyData Loss

Availability


IaaS

LargeScale

Disaster

LocalDisaster

IndustrialEspionage


Cloud Risks:

SaaS

PaaS

Lossofdirectcontrol

compensate by:


IaaS Contract

SLA: ServiceLevel Agreement


• legal

Cloud Service Level Agreements (Cloud-SLA)


Contract

SLA: ServiceLevel Agreement


• legal

Cloud Service Level Agreements (SLAs) :

automatic service discoverySLA negotiationQoS-based SLA search


Cloud-SLATemplate

Cloud-SLAModeling &DescriptionLanguage

Machine-readable

SLA


Cloud Definitions:

Application

End-User

Developper

Software as a Service SaaS

BaaSBusiness as a Service

Business Process


System Manager

Software as a Service



SaaS


Architecture Recommendation for Cloud Service Providers:

1. Implement the architecture principles as presented in this lecture

2. Deliver the cloud-services via established, accepted industry-standards

3. Provide transparency on your architecture, implementation and evolution

4. Give factual & contractual assurance for the quality properties(dependability, availability, privacy, disaster-recovery, performance etc.)

RCloud


Architecture Recommendation for Cloud Service Consumers:

1. Compensate the loss of transparence by requiring sufficient informationabout cloud service provider architecture, quality properties etc.

2. Compensate the lack of control by clear, explicit, legally binding Cloud-SLAs (Cloud service level agreements)

3. Insist on established, accepted industry-standards for the delivery of allcloud-services



The cloud paradigm offers very interesting commercial benefits

When using IaaS, PaaS, SaaS or BaaS („cloudification“) aloss of direct control results

Many of the quality properties (Security, availability, privacy etc.) are


Many of the quality properties (Security, availability, privacy etc.) areunder the control of the cloud service provider

The loss of direct control must be compensated by clear, explicit,and legally binding contracts (Cloud service level agreements)

„Cloudification“ offers new ways of systems engineering, e.g.identify and use cloud services instead of building the functionality.

Focus shifts from „building“ to „assembling“ – and needs new,different engineering processes


References:

ReferencesMahmood13 Zaigham Mahmood, Saqib Saeed (Editors):

Software Engineering Frameworks for the Cloud Computing ParadigmSpringer-Verlag, London, 2013. ISBN 978-1-4471-5030-5

Ackermann13 Tobias Ackermann:

IT Security Risk Management – Perceived IT Security Risks in the Context of Cloud Computing

Springer Gabler Verlag, Springer Fachmedien Wiesbaden, 2013. ISBN 978-3-658-01114-7Pearson13 Siani Pearson, George Yee (Editors):

Privacy and Security for Cloud Computing

Springer-Verlag, London, 2013. ISBN 978-1-447-14188-4Lehner13 Wolfgang Lehner, Kai-Uwe Sattler:

Web-Scale Data Management for the Cloud

Springer-Verlag, New York & Heidelberg, 2013. ISBN 978-1-4614-6855-4


Springer-Verlag, New York & Heidelberg, 2013. ISBN 978-1-4614-6855-4Mahmood11 Zaigham Mahmood, Richard Hill (Editors):

Cloud Computing for Enterprise ArchitecturesSpringer-Verlag, London, 2011. ISBN 978-1-4471-2235-7

Reese09 George Reese:

Cloud Application Architecture – Building Applications and Infrastructure in the Cloud

O‘Reilly Media Inc., Sebastopol, CA, USA, 2011. ISBN 978-0-596-15636-7Munz11 Frank Munz:

Middleware and Cloud Computing

Munz & More Publishing, 2011. ISBN 978-0-9807980-0-5Wieder11 Philipp Wieder, Joe M. Butler, Wolfgang Theilmann, Ramin Yahyapour (Editors):

Service Level Agreements for Cloud Computing

Springer New York, N.Y., 2011. ISBN 978-1-4614-1613-5EMA10 ENTERPRISE MANAGEMENT ASSOCIATES® (EMA™):

Designing a Responsible Cloud Infrastructure

White Paper, July 2011. Downloadable from:http://www.informationweek.com/whitepaper/Infrastructure/Network-Systems-Management/designing-a-responsible-cloud-infrastructure-wp1311970476 [last accessed: 30.10.2013]


Legacy System Migration/Modernizationh

ttp:/

/w

ww

.mid

con

tin

en

t.org

/pre

ss/pre

ss_r

ivets

.htm

l


htt

p:/

/w

ww

.mid

con

tin

en

t.org

/pre

ss/pre

ss_r

ivets

.htm

l

Future-Proof Software-Systems: Legacy Systems

What is a legacy system ? http://www.midcontinent.org/press/press_rivets.html

… a system built yesterday

Characteristics of a legacy system:

• Outdated technology (Hardware & Software)


• Outdated technology (Hardware & Software)

• Bad architecture

• Lack of documentation

• High resistance to change (= low agility)

• Large technical debt

Future-Proof Software-Systems: Legacy Systems



Architecture Recommendation for etc.)

RLegacy



References:

References


Future-Proof Software-Systems: Context & Definitions

BusinessCase

justifies

Future-ProofSoftware-System

QualityProperties

definedby

Structure

enables

Architectureforms

guide

control

DevelopmentProcess

builds


enforce


Future-ProofSoftware-Systems

Engineer

leads

appliesMetrics

quantify

uses

WorkingEnvironment

is embedded in

Part 3

Future-Proof Software-Systems


This is the end of Part 2:

you know now the foundations of future-proof software-systems andyou possess the toolbox to engineer them (Architecture Principles

and Patterns)

Part 3:

describes the „future-proof software-systems engineer“ and his working context

Date post:	19-Jun-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

PART2 B-WS13-14 V08 20131124 - TU Dresdenst.inf.tu-dresden.de/files/teaching/ws13/fps13/... ·...

Documents