Downloaded 310 times
![IBM Software Group | Rational software
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]
9](https://image.slidesharecdn.com/theprocessofsoftwarearchitecting-120628082454-phpapp01/75/The-process-of-software-architecting-9-2048.jpg)
![IBM Software Group | Rational software
Architecture Stability
%Resources derived from information in “Software Project Management – A Unified Framework” [Royce]
10](https://image.slidesharecdn.com/theprocessofsoftwarearchitecting-120628082454-phpapp01/75/The-process-of-software-architecting-10-2048.jpg)
Uploaded byRoger Snook
The process of software architecting
The document outlines the top ten success secrets for software architects, emphasizing the importance of understanding end-to-end development, managing risk, and communicating effectively with stakeholders. It provides insights on how architects can influence requirements, derive solutions from business needs, and appreciate the broader context of their work. Each success factor is presented as essential to creating effective software architectures.
More Related Content
Similar to The process of software architecting
The process of software architecting
- 1. ® IBM Software Group The Process of Software Architecting (Top 10 Success Secrets for Software Architects) Speaker: Peter Eeles Chief Architect, IBM Rational Software Delivery Executive IT Architect IBM UK peter.eeles@uk.ibm.com Good Design is Good Business Series (developerWorks) Roger Snook IBM Software, Rational WorldWide Enablement Leader, Offering, Strategy, Delivery (OSD) Team, +1.703.943.1170 RCSnook@us.ibm.com © 2012 IBM Corporation 1
- 2. IBM Software Group| Rational software 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 2
- 3. IBM Software Group| Rational software For More Info … www.processofsoftwarearchitecting.com 3
- 4. IBM Software Group| Rational software 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” 4
- 5. IBM Software Group| Rational software 1. Architects Understand End-to-End Development OpenUP disciplines shown 5
- 6. IBM Software Group| Rational software 1. Architects Understand End-to-End Development OpenUP disciplines shown 6
- 7. IBM Software Group| Rational software 1. Architects Understand End-to-End Development OpenUP disciplines shown 7
- 8. IBM Software Group| Rational software 2. Architects Understand their Role 8
- 9. IBM Software Group| Rational software 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] 9
- 10. IBM Software Group| Rational software Architecture Stability %Resources derived from information in “Software Project Management – A Unified Framework” [Royce] 10
- 11. IBM Software Group| Rational software 4. Architects Communicate with Stakeholders 11
- 12. IBM Software Group| Rational software 5. Architects Reuse Assets 12
- 13. IBM Software Group| Rational software 6. Architects Right-Size their Involvement 13
- 14. IBM Software Group| Rational software 6. Architects Right-Size their Involvement Small Project Large Project Role • A single person is assigned to • Different individuals are assigned to play the roles of Lead Architect, each of the architecture roles of Lead Application Architect, Architect, Application Architect, Infrastructure Architect and Data Infrastructure Architect and Data Architect. Architect. In addition, the team also includes a Security Architect. Task • An Architecture Overview is • An Architecture Overview is created created as a sketch on a as a formal work product that is whiteboard and then maintained. photographed (it is not kept up to date). Work • Requirements, Functional, • Requirements, Functional, Deployment and Performance Deployment, Validation, Performance product viewpoints are used to and Security viewpoints are used to document the architecture. document the architecture. An Information Viewpoint is added to emphasize this particular aspect of the architecture. 14
- 15. IBM Software Group| Rational software 15
- 16. IBM Software Group| Rational software 7. Architects Influence the Requirements Stakeholder input Scalability Schedule Performance Resources Maintainability Distribution Portability Platforms 16
- 17. IBM Software Group| Rational software 8. Architects Derive Solutions from Business Needs Attribute Developed at the Software Engineering Driven Institute Design Quality attributes drive the architecture (ADD) Method Underpinned by architectural tactics and patterns Siemens’ Developed at Siemens Corporate 4 Views Research (S4V) An analysis of global factors drives the method architecture Iteratively addresses challenges across four views (conceptual, execution, module and code architecture) The Developed at Rational Software (now IBM Rational Rational) Unified Architecturally-significant requirements Process drive the architecture (RUP) Each iteration considers the key architectural elements of the solution, before realizing the requirements across them 17
- 18. IBM Software Group| Rational software 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 18
- 19. IBM Software Group| Rational software Task: Outline Functional Elements Book Tour use case realization 19
- 20. IBM Software Group| Rational software Task: Outline Functional Elements Book Tour use case realization 20
- 21. IBM Software Group| Rational software Task: Outline Deployment Elements 21
- 22. IBM Software Group| Rational software Task: Detail Deployment Elements 22
- 23. IBM Software Group| Rational software 9. Architects Refine Solutions Based on Technology 23
- 24. IBM Software Group| Rational software 10. Architects Appreciate the Broader Context 24
- 25. IBM Software Group| Rational software 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 25
- 26. IBM Software Group| Rational software 26
- 27. IBM Software Group| Rational software Good Design is Good Business Series (developerWorks) Roger Snook IBM Software, Rational WorldWide Enablement Leader, Offering, Strategy, Delivery (OSD) Team, +1.703.943.1170 RCSnook@us.ibm.com 27
Editor's Notes
- #2 Peter Eeles is an Executive IT Architect and Chief Architect for IT in IBM Rational's worldwide solution delivery organization, where he helps organizations improve their software development capability. This is often in conjunction with an architecture-centric initiative such as SOA or strategic reuse, where Peter has particular in-depth knowledge. Peter is co-author of "The Process of Software Architecting" (2009), "Building J2EE Applications with the Rational Unified Process" (2002), and "Building Business Objects" (1998).
- #6 An architect should have an appreciation of the software development process, since it is this process that ensures that all of the members of the team work in a coordinated manner. This coordination is achieved by defining the roles involved, the tasks undertaken, the work products created, and the handoff points between the different roles. It is important for the architect to understand the roles and responsibilities of the team members so that the architect can communicate more effectively with them. In essence, team members will look to the architect for guidance on how to fulfill their responsibilities and the architect must be able to respond in a manner that is consistent with the development process being followed.
- #7 An architect should have an appreciation of the software development process, since it is this process that ensures that all of the members of the team work in a coordinated manner. This coordination is achieved by defining the roles involved, the tasks undertaken, the work products created, and the handoff points between the different roles. It is important for the architect to understand the roles and responsibilities of the team members so that the architect can communicate more effectively with them. In essence, team members will look to the architect for guidance on how to fulfill their responsibilities and the architect must be able to respond in a manner that is consistent with the development process being followed.
- #8 An architect should have an appreciation of the software development process, since it is this process that ensures that all of the members of the team work in a coordinated manner. This coordination is achieved by defining the roles involved, the tasks undertaken, the work products created, and the handoff points between the different roles. It is important for the architect to understand the roles and responsibilities of the team members so that the architect can communicate more effectively with them. In essence, team members will look to the architect for guidance on how to fulfill their responsibilities and the architect must be able to respond in a manner that is consistent with the development process being followed.
- #9 Many individuals have the word “architect” in their job title without really understanding what this means – whether this be the definition of architecture, the tasks performed by an architect, the skills required of an architect, or the benefits that result from architecting. Clearly, all of these elements are important. A particularly important aspect, however, is for the architect to be very clear about the scope of their work as part of the “bigger picture”. Even though a software architect may work on a software-intensive system, the system as a whole is more than the software. For example, qualities such as performance and reliability cannot be achieved in software alone and, in this case, are achieved through the combination of software and hardware.
- #10 It is very tempting to show project progress by focusing on the “easy things”; those elements that have very little risk associated with them and that are unlikely to change. However, taking such an approach simply delays the inevitable, when technical challenges and changed requirements can no longer be avoided. Successful architects tackle risk and changes head on and will adopt, when needed, appropriate project lifecycles (such as an iterative approach) to ensure that technical risks are addressed up front, and that changes are considered a normal part of project execution.
- #12 Successful architects will document their architectures to allow them to be effectively communicated. This communication is essential in ensuring that all stakeholders understand the architecture and can provide their input accordingly. This communication is critical in ensuring that certain stakeholders are comfortable with the proposed solution, and that the project team has a consistent view of the system to be built.
- #13 Inspiration for deriving an architecture comes from many places, and will vary depending on many factors, including the novelty of the system, the method being followed, and the skills of the architect. One of the main sources of inspiration is reusable assets and, not surprisingly, successful architects tend to be those that are conscious of the assets available. Consideration of reusable assets can significantly help the architect in their work since it reduces the number of things that the architect needs to be concerned with – there is no need to “reinvent the wheel”. From a project perspective, the reuse of assets within the project can have a significant bearing on the project schedule, cost and quality of the delivered system.
- #15 Building a dog house is very different from building a skyscraper and the various process elements (roles, tasks and work products) need to be right-sized for the development project at hand. Put another way, we need to consider the “level of ceremony” that needs to be applied, as Grady Booch calls it.