software architecture masterclass -

IBM Rational Software Conference 2009Software Architecture Masterclass

© 2009 IBM Corporation

Software Architecture Masterclass


Peter EelesExecutive IT Architect, [email protected]

Contributions from Grady Booch, Dave Brown, Peter Cripps, Jim Densmore, Celso Gonzalez


© 2009 IBM Corporation

IBM Rational Software Conference 2009

Introductions

� Name, organization, role?

� What are you looking for from the masterclass?

Software Architecture Masterclass 2


Terminology



Software-Intensive Systems

� A system in which software is the dominant, essential, and indispensable element

�E-commerce system

� IT (business) system

�Telephone switch

�Flight control system

�Real-time control system (e.g. industrial robot)


robot)

�Sophisticated weapons system

�Software development tools

�System software (e.g. operating systems or compilers)

4


10 Keys to Success

Successful Architects … For example, they …

1 Understand end-to-end development Follow a repeatable process

2 Understand their role Understand what an architecture is

Understand what an architect does

Understand the benefits of architecting

3 Manage risk and manage change Derive their architectures iteratively

4 Communicate with stakeholders Document their architectures


4 Communicate with stakeholders Document their architectures

5 Reuse assets Embrace different types of assets

6 Right-size their involvement Select relevant viewpoints

7 Influence the requirements Ensure tradeoffs are negotiated

8 Derive solutions from business needs Produce business-driven architectures

9 Refine solutions based on technology Realize architectures in available technology

10 Appreciate the broader context Align their work with the “bigger picture”


Agenda

� Architects understand end-to-end development

� Architects understand their role

� Architects manage risk and manage change

� Architects communicate with stakeholders

� Architects reuse assets

� Architects right-size their involvement


� Architects influence the requirements

� Architects derive solutions from business needs

� Architects refine solutions based on technology

� Architects appreciate the broader context


Where does architecting fit in a software


fit in a software development process?


OpenUP Disciplines

Requirements

Requirements Solution

Architecture Development Test


Design

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

- Grady Booch

[A discipline is a] primary categorization mechanism for organizing tasks that define a major 'area of concern' and/or cooperation of work effort. [OpenUP]


Agenda













What are the characteristics of a


characteristics of a software architecture?


Software Architecture Defined

� Architecture is the fundamental organization of a system embodied in its

components, their relationships to each other, and to the environment, and

the principles guiding its design and evolution. [IEEE 1471]

� The software architecture of a program or computing system is the structure

or structures of the system, which comprise software elements, the externally

visible properties of those elements, and the relationships among them.

[Bass]

� The software architecture of a system or a collection of systems consists of all


� The software architecture of a system or a collection of systems consists of all

the important design decisions about the software structures and the

interactions between those structures that comprise the systems. The design

decisions support a desired set of qualities that the system should support to

be successful. The design decisions provide a conceptual basis for system

development, support, and maintenance. (McGovern 2004)


Characteristics of a Software Architecture

� An architecture defines structure

� An architecture defines behaviour

� An architecture meets stakeholder needs

� An architecture is influenced by its environment

� An architecture is concerned with significant elements

� An architecture conforms to an architectural style

Structure


� An architecture influences organizational structure

� An architecture is present in every system

� An architecture embodies decisions based on rationale

The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark.

- Philippe Kruchten

Behavior


An Architecture has a Particular Scope


[A system is] a set of resources that provide services that are used by an enterprise to carry out a business purpose or mission. System components typically consist of hardware, software, data, and workers. [Cantor]


What are the characteristics of a


characteristics of a software architect?


Characteristics of an Architect

� The architect is a technical leader

� The architect understands the software development process

� The architect has knowledge of the business domain

� The architect has technology knowledge

� The architect has design skills

� The architect has programming skills


� The architect is a good communicator

� The architect makes decisions

� The architect is aware of organizational politics

� The architect is a negotiator

� The architect role may be fulfilled by a team


What are the benefits of architecting?


architecting?


Benefits of Architecting

� Architecting reduces unnecessary creativity

� Architecting helps manage complexity

� Architecting ensures architectural integrity

� Architecting addresses system qualities

� Architecting reduces maintenance costs

� Architecting drives consensus


� Architecting provides a basis for reuse

� Architecting supports impact analysis

� Architecting supports the planning process


Agenda













Waterfall and Iterative Lifecycles



Iteration Focus Changes over Time

Discovery Invention Implementation


Drawn on a napkin by Bran Selic for Philippe Kruchten


Formalizing the Change in Focus


OpenUP disciplines shown


Architecture Stability


%Resources derived from information in “Software Project Management – A Unified Framework” [Royce]


What about Agile?

� Agile Manifesto

� Individuals and interactions over processes and tools.

�Working software over comprehensive documentation.

�Customer collaboration over contract negotiation.

�Responding to change over following a plan.

� Scrum is a management and control process that cuts through complexity to

focus on building software to meet business needs. Scrum is superimposed on

top of and wraps existing engineering practices, development methodologies and


top of and wraps existing engineering practices, development methodologies and

standards. [Schwaber]

There seems to be a fear in the agile community that if we use terms such as “model” or “document” that suddenly the “evil bureaucrats” will dig their claws into our projects and force us to write detailed, big requirements specifications or to take a big-design-up-front approach ... the strange thing is that agilists are, in fact, modeling on a regular basis, even though they're not directly talking about it. [Ambler]


Agenda













Who are the stakeholders in your architecture?


in your architecture?

What are their concerns?


Documenting a Software Architecture

� Core concepts

�Stakeholder - Who is the description for?

�Viewpoint - Defines stakeholder concerns, notations and techniques

�Model - Created to populate the various views

�View - Conforms to a viewpoint, a particular perspective on the architecture


Concepts defined in “The IEEE Recommended Practice for Architectural Description of Software-Intensive Systems” [IEEE 1471]


Views, Diagrams and Models



What viewpoints might you use to document your


you use to document your architecture?


Architecture Description Frameworks

� Software Architecture

�The 4 + 1 View Model of Software Architecture [Kruchten]

�Rozanski and Woods [Rozanski]

�Siemens

�RM-ODP

� Systems Engineering

�Model-Driven Systems Development (MDSD) [MDSD]. Formerly RUP for Systems


�Model-Driven Systems Development (MDSD) [MDSD]. Formerly RUP for Systems

Engineering (RUP-SE)

� Enterprise Architecture

�The Open Group Architecture Framework (ToGAF)

�The Zachman Framework [Zachman]

� Domain-Specific

�Department of Defense Architecture Framework (DoDAF)

�Ministry of Defence Architecture Framework (MoDAF)


Examples of Architecture Description Frameworks4 + 1 View Model of Software Architecture [Kruchten]

Rozanski and Woods [Rozanski]


The Zachman Framework [Zachman]


Basic and Cross-Cutting Viewpoints



Agenda













What types of assets might you apply in your


might you apply in your architecture?


A Metamodel of Architecture Assets


One thing expert designers know not to do is to solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Such experience is part of what makes them experts. [Gamma]


Observer Pattern



IBM Patterns for e-business

Examplesuser-to-businessuser-to-useruser-to-data

ExampleDirectly Integrated Single Channel


ExampleDirectly Integrated Single Channel

www.ibm.com/developerworks/patterns/

Also see extensive patterns catalog at:

http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Patterns


Agenda













A Classic Analogy



Architects Right-Size their Involvement

Small Project Large Project

Role • A single person is assigned to play

the roles of Lead Architect,

Application Architect, Infrastructure

Architect and Data Architect.

• Different individuals are assigned to each

of the architecture roles of Lead Architect,

Application Architect, Infrastructure

Architect and Data Architect. In addition,

the team also includes a Security Architect.

Task • An Architecture Overview is created

as a sketch on a whiteboard and then

photographed (it is not kept up to

date).

• An Architecture Overview is created as a

formal work product that is maintained.


date).

Work product • An Architecture Proof-of-Concept is

created on paper only (no executable

software needs to be built).

• Requirements, Functional,

Deployment and Performance

viewpoints are used to document the

architecture.

• An Architecture Proof-of-Concept is

created as executable software.

• Requirements, Functional, Deployment,

Validation, Performance and Security

viewpoints are used to document the

architecture. An Information Viewpoint is

added to emphasize this particular aspect

of the architecture.


Agenda













The “YourTour” Case Study



What forces influence the architect’s work?


architect’s work?


Making Tradeoffs addresses Opposing Forces

ScheduleResources

Stakeholder input

ScalabilityPerformance


DistributionPlatforms

MaintainabilityPortability


What is the architect’s role with respect to


role with respect to requirements?


Requirements Discipline



Task: Define System Context



Task: Outline Functional Requirements



Task: Outline Non-Functional Requirements

� Usability Requirements

� Reliability Requirements

� Performance Requirements

� Supportability Requirements

� Constraints

�Business Constraints

�Architecture Constraints


�Architecture Constraints

�Development Constraints

�Physical Constraints

“Brownfield sites are those in which redevelopment or reuse of the site is complicated by existing contaminants. Greenfield sites are clean, previously undeveloped land”. [Hopkins]


Task: Prioritize Requirements

� Which use cases should drive the remainder of the iteration?



Task: Prioritize Requirements

� We may select particular flows through the use case



Agenda













Architecture Discipline



How much logical architecting should be


architecting should be performed?

* “Logical” = Technology-independent


How Much Logical Architecture?

� Minimizing Logical Architecture

� None. The requirements for the system are similar

to those of an existing system and moving from

requirements to physical architecture is trivial.

� Just Enough. We can demonstrate that we

understand the current set of requirements and that

those requirements have been appropriately

allocated to parts of the solution.

� Logical Architecture as an Investment


� Logical Architecture as an Investment

� Some. A technology change is anticipated and the

logical architecture provides a good starting point

when we make that change.

� Comprehensive. The system is large and complex

and its development will run over a long period of

time and over several releases. We therefore

expect to maintain / enhance the system and want

to evolve the architecture rather than reinventing (or

ignoring) it.


Terminology

� Component

�A component represents a modular part of a system that encapsulates its contents and

whose manifestation is replaceable within its environment. A component defines its

behavior in terms of provided and required interfaces. As such, a component serves as a

type whose conformance is defined by these provided and required interfaces

(encompassing both their static as well as dynamic semantics). One component may

therefore be substituted by another only if the two are type conformant. [UML 2.2]

� Subsystem


�A set of related components.


Task: Define Architecture Overview



Task: Outline Functional Elements



From Requirements to Solution

Attribute Driven

Design (ADD)

Method

�Developed at the Software Engineering Institute

�Quality attributes drive the architecture

�Underpinned by architectural tactics and patterns

Siemens’ 4 Views

(S4V) method

�Developed at Siemens Corporate Research

�An analysis of global factors drive the architecture

�Iteratively addresses challenges across four views (conceptual,


�Iteratively addresses challenges across four views (conceptual,

execution, module and code architecture)

The Rational Unified

Process (RUP)

�Developed at Rational Software (now IBM Rational)

�Architecturally-significant requirements drive the architecture

�Each iteration considers the key architectural elements of the

solution, before realizing the requirements across them



� Boundary (or presentation) components

�Support the boundary between the system and items outside the system with which the

system interacts, such as end users or external systems

� Control (or execution) components

�Support the control logic of the system as well as the business rules and other logic

required to satisfy the functional requirements

� Entity (or data) components


�These components support the representation of persistent information




Book Tour use case realization


Assigning NFRs to Components

Requirement Component Operation Budgeted

Requirement

Booking a tour must take less

than 10 seconds, from the time

the request is submitted, to the

Tour Booking Manager provide payment details() 1 second

Payment Engine Boundary process payment() 3 seconds


confirmation of the booking

being presented to the user Reservation System Boundary make reservations() 6 seconds


Task: Detail Functional Elements



Task: Outline Deployment Elements



Task: Detail Deployment Elements



Agenda













Technology-Specifics



Agenda













External Influences



You’ve been assigned as the architect of a new

system.


system.

What’s your worst nightmare? ☺


Challenges of Complex Systems



A “System of Systems”



Summary













Primary References


www.handbookofsoftwarearchitecture.com

www2.computer.org/portal/web/computingnow/onarchitecture

www.processofsoftwarearchitecting.com


Other ReferencesReference Description

Ambler 2008 Agile Model-Driven Development. Scott Ambler and Celso Gonzalez.

www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&ac=367. 2008

Bass 2003 Software Architecture in Practice. Second edition. Len Bass, Paul Clements and Rick Kazman. Addison Wesley. ISBN 0-321-

15495-9. 2003

Cantor 2003 Rational Unified Process for Systems Engineering. Murray Cantor. Article from The Rational Edge. www.therationaledge.com.

August 2003

Hopkins 2008 Eating the IT Elephant - Moving from Greenfield Development to Brownfield. Richard Hopkins and Kevin Jenkins. IBM Press.

ISBN 0-13-713012-0. 2008

IEEE 1471 2000 Recommended practice for architectural description of software-intensive systems. IEEE Std 1471-2000. IEEE Computer

Society. 2000

Kruchten 1995 The “4+1” View Model of Architecture. Philippe Kruchten. Paper published in IEEE Software vol. 12, no. 6. November 1995, pp.


Kruchten 1995 The “4+1” View Model of Architecture. Philippe Kruchten. Paper published in IEEE Software vol. 12, no. 6. November 1995, pp.

42-50

McGovern 2004 A Practical Guide to Enterprise Architecture. James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan

and Elias K. Jo. Prentice Hall. ISBN 0-13-141275-2. 2004

MDSD 2008 Model Driven Systems Development with Rational Products. IBM Redbooks. ISBN 0738485683. 2008.

www.redbooks.ibm.com/abstracts/sg247368.html

OpenUP 2008 Open Unified Process. Version 1.5.0.1. epf.eclipse.org/wikis/openup. 2008

Royce 1998 Software Project Management – A Unified Framework. Walker Royce. Addison Wesley. ISBN 0-201-30958-0. 1998

Rozanski 2005 Software Systems Architecture – Working with Stakeholders using Viewpoints and Perspectives. Nick Rozanski and Eoin

Woods. Addison Wesley. ISBN 0-321-11229-6. 2005

Schwaber 2002 Agile Software Development with Scrum. Ken Schwaber and Mike Beedle. Prentice Hall. ISBN 0-13-067634-9. 2002

UML 2.2 2009 UML 2.2 Superstructure Specification. Object Management. Group, Inc. Document number 09-02-02, February 2009.

www.omg.org/docs/formal/09-02-02.pdf. 2009

Zachman 1987 A Framework for Information Systems Architecture. John Zachman. IBM Systems Journal. Vol.26, No.3. 1987



© Copyright IBM Corporation 2009. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

software architecture masterclass -

Documents