The process of software architecting

®

IBM Software Group

© 2012 IBM Corporation

The Process of Software Architecting(Top 10 Success Secrets for Software Architects)

Speaker: Peter Eeles

Chief Architect, IBM Rational Software DeliveryExecutive IT ArchitectIBM [email protected]

1

Roger Snook IBM Software, RationalWorldWide Enablement Leader, Offering, Strategy, Delivery (OSD) Team, [email protected]

Good Design is Good Business Series (developerWorks)

IBM Software Group | Rational software

2

Inspiration “If I have seen further it is only by

standing on the shoulders of giants”

Sir Isaac Newton, letter to Robert Hooke, 15th February 1676

www.handbookofsoftwarearchitecture.com


3

For More Info …www.processofsoftwarearchitecting.com


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

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”


5

1. Architects Understand End-to-End Development

OpenUP disciplines shown


6




7




8

2. Architects Understand their Role


9

3. Architects Manage Risk and Manage Change

“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 standards”. [Schwaber]


10

Architecture Stability

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


11

4. Architects Communicate with Stakeholders


12

5. Architects Reuse Assets


13

6. Architects Right-Size their Involvement


14

6. 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.

Work product

• Requirements, Functional, Deployment and Performance viewpoints are used to document the architecture.

• 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.


15


16

7. Architects Influence the Requirements

ScheduleResources

Stakeholder input

ScalabilityPerformance

DistributionPlatforms

MaintainabilityPortability


17

8. Architects Derive Solutions from Business Needs

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 drives the architecture

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


18

Task: Outline Functional Elements

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


19


Book Tour use case realization


20


Book Tour use case realization


21

Task: Outline Deployment Elements


22

Task: Detail Deployment Elements


23

9. Architects Refine Solutions Based on Technology


24

10. Architects Appreciate the Broader Context


25

Summary

1. Architects understand end-to-end development

2. Architects understand their role

3. Architects manage risk and manage change

4. Architects communicate with stakeholders

5. Architects reuse assets

6. Architects right-size their involvement

7. Architects influence the requirements

8. Architects derive solutions from business needs

9. Architects refine solutions based on technology

10.Architects appreciate the broader context


26


27

Roger Snook IBM Software, RationalWorldWide Enablement Leader, Offering, Strategy, Delivery (OSD) Team, [email protected]

Good Design is Good Business Series (developerWorks)