the past, present and future of software architecture · topics introducing software architecture...

The Past, Present and Future of Software Architecture

Eoin WoodsUBS Investment Bank

[email protected]

About meI’m a working software architectAlways worked as a software engineer

8 years of products, 7 of applicationsRecently moved to end-user company

Lead a central architecture groupCo-author of software architecture book

With Nick Rozanski, Addison-Wesley, 2005Participant in IFIP 2.10 WG

TopicsIntroducing Software ArchitectureThe Past and PresentExploring the FundamentalsAn Example of Architecture in PracticeThe Future

What Is Software ArchitectureThe software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible qualities of those elements, and the relationshipsamong them

Bass, Clements, Kazman (SEI)

What is Software ArchitectureThe set of design decisions which, if made incorrectly, will cause your project to be cancelled

Eoin Woods (heads the SEI definitions list)

The SEI definitions list:www.sei.cmu.edu/architecture/definitions.html

Just Design, Surely?All architecture is design, not all design is architecture [Paul Clements]

Not all design decisions are equalSome have “architectural significance”

Architectural design is outward lookingFocus on stakeholders, not technology

Architecture more fluid than designContext, scope, success criteria all unclear

The EssenceSoftware architecture is concerned with:

StakeholdersSystem-Level StructuresSystem qualities

Software architecture involves:Understanding domains, problems and solutionsMaking design decisions & tradeoffsDelivering working systems

Architecture in Context

Requirements Design

The crucial bridge between requirements and design

Architecture

Architecture in Context

Requirements

Architecture

This interplay is core to the architectural process

Desires

Possibilities

The Role of the ArchitectCentral technical communicatorKey decision makerResponsible for delivery

Architect as Communicator

Tester

ArchitectAcquirer

User

ProjectManager Developer

Supplier

Analyst

Why Architecture is ImportantStakeholder focusEnsuring that the right system is builtSystem-wide (or cross-system) consistency

Types of IT ArchitectSoftware architect

Focus of this talkResponsible for a system’s structures

Enterprise architectResponsible for cross-system structures

Infrastructure architectResponsible for technology-specific structures

Operations architectResponsible for operational structures

Types of IT Architect

InfrastructureArchitect



SoftwareArchitect

SoftwareArchitect

SoftwareArchitect

Enterprise Architects

Ope

ratio

ns A

rchi

tect

s

Where Did it Come From?Ideas from David Parnas (1985)

also Zachman Framework (1987)Perry and Wolf paper (1992)Began largely as an academic interestEnthusiastically transferred into industry

little interchange between the two since!Mirrors the rise in importance and status of the technical IT professional

Some Milestones (i)1995:

IEEE Software special issue on Software ArchitecturePhilippe Kruchten’s “4+1” viewpoint set published

1996: Shaw and Garlan’s book “Software Architecture: Perspectives on an Emerging Discipline”

1998:Bass, Clements and Kazman publish “Software Architecture in Practice”, 1st edition

Some Milestones (ii)2000:

Views and Viewpoints standardised via IEEE-1471SEI’s “ATAM” analysis method publishedRUP becomes “architecture centric”J2EE 1.0 specification released

2001:WICSA conference series starts

2002:.NET 1.0 released

Some Milestones (iii)2003:

Bass, Clements and Kazman, 2nd EditionMartin Fowler admits software architecture exists!

2005:IASA is founded and starts growingNew “Perspectives” concept identified

Nick Rozanski and Eoin WoodsPart of a new practitioner-oriented book

WICSA 5 runs in Pittsburgh10th anniversary of the IEEE Software issueSignificant practitioner focus and attendance

As an Aside – My Parallels

WICSA 5 runsIASA foundedFowler’s P of EAA (94)

My bookCurrent role

2005

Book explosionIEEE 1471J2EE and .NET

Systems architect role2000-02

1st book (Witt, Baker, Merritt, 1994)IEEE Software issue & “4+1”Shaw and Garlan book (96)

First architecture role1995

Perry and Wolf paper (92)Trainee s/w architect1993

Little s/w architecture discussionTrainee s/w engineer1990The FieldMe

The PresentThe language of SWA is widely used

Even if rarely defined or understoodReasonably large set of (basic) booksOrganisations & certification emerging

IASA, MicrosoftOrganisations are seeing value

Supply: IBM, Microsoft, Evolution-Detica,…Demand: Hartford Financial, UBS, BP, …

Architecture FundamentalsStakeholders

Who cares what we build?Why do they care?

System structuresWhat do we build?

System qualitiesWhy do we build it that way?

System-Level StructuresThe traditional deliverable of the software architectNote that there are many structures

Functional, Deployment, Information, …Represented as a set of views

Separate concernsCommunicate effectivelyOrganise deliverables and activities

StakeholdersThose who care if the system gets built

Can be a positive or negative interestIncludes people, groups and entities

The reason we build systemsSystems are built for stakeholdersDesign decisions must reflect their needsA wide community often increases the chances of success

StakeholdersAcquirers pay for the systemAssessors check for complianceCommunicators create documents and trainingDevelopers create itMaintainers evolve/fix itSuppliers provide pieces

Support Staff help people to use the systemSystem Admins, keep it runningTesters verify that it worksUsers use the system directly

StakeholdersAttributes of a good stakeholder include:

Informed, to allow them to make good decisionsCommitted, to the process and willing to make themselves available in a constructive mannerAuthorised, to make decisionsRepresentative, of their stakeholder group so that they present its views validly

System QualitiesNon-functional characteristics (“-illities”)

Performance, Security, Availability, …Often crucial to stakeholders

Slow functions don’t get usedUnavailable systems stop the businessSecurity problems cause headlines

Yet often an after-thought

System QualitiesAchieving system qualities is a key task

Understanding real stakeholder needsUnderstanding what is possibleMaking the key trade-offs to allow deliveryAvoiding expensive “retro-fit”

Architect’s ResponsibilitiesUnderstand requirements

Identify architectural impactLead development

Help, don’t hinderAnalyse architecturesMake design decisions and tradeoffsCommunicateEnsure delivery!

Typical Architect’s ActivitiesCreate models (UML, ADL, B+L, …)Build skeleton systemsWrite PoCs and prototypesWrite documentsGive presentationsUndertake “rescue missions”

Attributes of a Good ArchitectTechnology knowledgeDesign abilityCommunication skillsPragmatismPolitical sensitivityTact… and a good sense of humour doesn’t hurt!

Architectural SignificanceA concern, problem, or system element is architecturally significant if it has a wide impact on the structure of the system, or on its important quality properties such as performance, scalability, security, reliability or evolvability- Philippe Kruchten

Externally visibleHas a real affect on stakeholder utilityDifficult to change laterAffects many parts of the system

Simple ExampleA statistics management system

Data bulk-loaded into the databaseDerived measures calculated automaticallyStatisticians view and report on the dataDeductions recorded and reviewed manually

Simple ArchitectureDescribed through 5 views

FunctionalInformationConcurrencyDevelopmentDeployment(Operational view omitted)

Functional View

Information View

created published

approved challenged

obsolete

Deduction

Concurrency View

Development ViewDomain

StatDate LibraryJava Numerical

Toolkit

Utility

Apache Axis Hibernate 2.1

Servlet 2.2 API

Platform

Java 1.4 LibraryOracle JDBC

Driver 9.0

Deployment View

{model=StorEdge3510FC, capacity=500GB}

Disk Array

{model=SunFIreV440, memory=16GB, CPU=2x1.6GHz, IO=FiberChannel}

Database Server

{memory>=500MB, CPU>=1.8GHz}

Client PC

<<process>>Stats_Client

{model=DellSC430, memory=8GB, CPU=2x3GHz}

Primary Server

<<process>>Stats_Server

<<process>>Calculator

<<processgroup>>DBMS_Process_Grp

<<process>>Loader

{type=FC}

Data Centre Resident

Architectural ImpactThe architecture we’ve described is credibleWhat would happen if the system needed to protect the system’s information?

Justice community system for criminal intelligence

Considering SecuritySensitive Resources

The data in the databaseSecurity Threats

Operators stealing backupsAdministrators querying data, seeing namesBribing investigating officersInternal attack on the database via network

Considering SecuritySecurity Countermeasures

Backups: encrypt data in the databaseHow about performance?Does this make availability (DR) harder?

Seeing names: use codes instead of names, protect codes at higher security level

More development complexityPossible performance impact

Considering SecuritySecurity Countermeasures

Network Attacks: firewalls, IDSMore costMore deployment / administration complexityOperational impact if IDS trips

Bribery: add audit trail for data accessPossible performance impactMore complexityProtecting / using the audit trail

Considering SecurityInformation View Impact

StatsSet Variable

Observation

Deduction

DerivedMeasure

Identifier Code

Isolate names

Considering SecurityDevelopment View Impact

Domain

StatDate LibraryJava Numerical

Toolkit

Utility

Apache Axis Hibernate 2.1

Controlled StatAccess

Library

Add audit whenaccessing data

Considering SecurityDeployment View Impact

Added network model making network security clear

Considering SecurityOther Impact

Need IDS added to Development viewNeed to capture impact on Operational viewNeed to consider impact on availabilityNeed to re-work performance models to allow for database encryption, audit, …

Note the need to change many viewsThis is “architecturally significant”

The Future (i)Career track recognition

Architect vs. developer, tester or PMPossibly certification (e.g. IASA)

Better description languages & toolsExecutable and queryable architecturesArchitecture in the running system

Architect-specific tool supportLattix and Sotograph are early examples

The Future (ii)Fundamental agreed definitions

Necessary or even desirable?Teaching

MSc in software architecture perhaps?Further styles codified as technologies

Grid, tuple-space, P2P, …

Summary (i)Software architecture is still young

Really a product of 1995 – 2005Mainstream since about 2002Good core of knowledge emerging

Approaches and techniquesSome agreement on fundamentals

Stakeholders, structures, qualitiesUnderstanding, designing, trading-off, delivering

Summary (ii)Finally research & practice meeting

WICSA 5, IASA, Microsoft, …The future is architecture in the systems

Too much is lost today

To Learn More

Software Systems Architecture:Working With Stakeholders Using Viewpoints and Perspectives

Nick Rozanski & Eoin WoodsAddison Wesley, 2005

http://www.viewpoints-and-perspectives.info

Eoin [email protected]

Comments and Questions?

the past, present and future of software architecture · topics introducing software architecture...

Documents