The Past, Present and Future of Software Architecture · Topics Introducing Software Architecture...
Transcript of The Past, Present and Future of Software Architecture · Topics Introducing Software Architecture...
The Past, Present and Future of Software Architecture
Eoin WoodsUBS Investment Bank
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
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
InfrastructureArchitect
InfrastructureArchitect
SoftwareArchitect
SoftwareArchitect
SoftwareArchitect
Enterprise Architects
Ope
ratio
ns A
rchi
tect
s
TopicsIntroducing Software ArchitectureThe Past and PresentExploring the FundamentalsAn Example of Architecture in PracticeThe Future
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, …
TopicsIntroducing Software ArchitectureThe Past and PresentExploring the FundamentalsAn Example of Architecture in PracticeThe Future
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
TopicsIntroducing Software ArchitectureThe Past and PresentExploring the FundamentalsAn Example of Architecture in PracticeThe Future
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)
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 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”
TopicsIntroducing Software ArchitectureThe Past and PresentExploring the FundamentalsAn Example of Architecture in PracticeThe Future
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