A Top 10 Key to Success for Architects, delivered by author Pete Eeles, IBM, hosted on the "Good Design is Good Business" group on developerWorks: https://www.ibm.com/developerworks/mydeveloperworks/blogs/669242b1-dd91-4d63-a08f-231314c793bb/entry/top_10_success_secrets_for_software_architects_good_design_is_good_business_series?lang=en
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
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
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
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
Notas do Editor
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).
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.
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.
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.
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.
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.
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.
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.
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.