CS 3212

Software Architecture & Design

Dr. Chinthana Wimalasuriya

Lecture 9
People, Role and Teams

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice

The Need

 The greatest architectures are the product of

 A single mind or

 A very small, carefully structured team

Systems Architecting: Creating & Building

 Rechtin,
Complex Systems, 1991, p21
 Every project should have exactly 1 identifiable architect
 For larger projects, principal architect should be
backed up by architect team of modest size
 Booch, Object Solutions, 1996
2
Software Architecture: Foundations, Theory, and Practice

Software Architects
 Architect is “jack of all trades”
 Maintainer of system’s conceptual integrity
 Part of team
 Set of people with complementary skills
 Committed to common
 Purpose
 Performance goals
 Approach
 Hold each other accountable
 Life of architect is long series of locally suboptimal decisions made
partly in the dark
 Sometimes painful

3
Software Architecture: Foundations, Theory, and Practice

Desired Skill Set

 Software development expertise
 Domain expertise
 Communicator
 Strategist
 Consultant
 Leader
 Technologist
 Cost estimator
 Cheerleader
 Politician
 Salesperson 4
Software Architecture: Foundations, Theory, and Practice

Blending the Skill Set

 May need different people & skills based on

 Characteristics of project & domain

 Lifecycle “phase”

 Type of architecture

 Enterprise vs. product-line vs. product

 Distinction between junior & senior architects

 Each architect should possess some subset of above skills

 What architects are usually not in a project
 Developers – though they may prototype their ideas

 Managers – except in small organizations

5
Software Architecture: Foundations, Theory, and Practice

Architects As Software Development

Experts
 Must understand nuances of software development
 Principles
 Methods & techniques
 Methodologies
 Tools
 Need not be world-class software programmers
 Should understand ramifications of architectural choices
 Do not live in ivory tower
 Some architectural choices constrain implementation
options
 Some implementation-level techniques & tools constrain
architectural choices
6
Software Architecture: Foundations, Theory, and Practice

Architects As Domain Experts

 Software engineering expertise is not enough

 Problem domain nuances
 Maturity
 Stability
 System user profile
 May greatly affect selected & developed architectural
solutions
 Distribution
 Scale
 Evolvability
 Requires artifacts that model problem space
 Not solution space 7
Software Architecture: Foundations, Theory, and Practice

Team Needs Balance & Shared

Vocabulary
D

Too little domain

knowledge

8
Software Architecture: Foundations, Theory, and Practice

Team Needs Balance & Shared

Vocabulary
D
D
S
S
Too little domain Too little SWE
knowledge knowledge

9
Software Architecture: Foundations, Theory, and Practice

Team Needs Balance & Shared

Vocabulary
D
D
S
S
Too little domain Too little SWE
knowledge knowledge

No Shared
10
Vocabulary
Software Architecture: Foundations, Theory, and Practice

Team Needs Balance & Shared

Vocabulary
D
D
S
S
Too little domain Too little SWE
knowledge knowledge

D
S
S
No Shared
Vocabulary Good! 11
Software Architecture: Foundations, Theory, and Practice

Architects As Communicators

 At least ½ of the job

 Must
 Listen to stakeholder concerns

 Explain the architecture

 Negotiate compromises

 Need good communication skills

 Writing

 Speaking

 Presenting 12
Software Architecture: Foundations, Theory, and Practice

Architects Communicate With

 Managers
 Must relay key messages
 Architecture is useful & important
 Ensure support throughout project
 Must listen to concerns
 Cost
 Schedule
 Developers
 Convince them that architecture is effective
 Justify local suboptimal choices
 Listen to problems
 Tools
 Methods
 Design choices
 Other software architects
 Ensure conceptual integrity
 Ensure desired system properties & evolution
13
Software Architecture: Foundations, Theory, and Practice

Architects Also Communicate With

 System engineers
 Coordinate requirements & solutions
 Explain how architecture addresses key concerns
 Customers
 Determine needs
 Explain how architecture addresses requirements
 Users
 Determine needs
 Explain how architecture addresses those needs
 Listen to problems
 Marketers
 Get/help set goals & directions
 Explain how architecture addresses marketing objectives

14
Software Architecture: Foundations, Theory, and Practice

Architects As Strategists
 Developing elegant architecture is not enough
 Technology is only part of picture
 Architecture must be right for organization
 Must fit organization’s
 Business strategy
 Rationale behind it
 Business practices
 Planning cycles
 Decision making processes
 Must also be aware of competitors’
 Products
 Strategies
 Processes 15
Software Architecture: Foundations, Theory, and Practice

Architects As Consultants

 Architects must recognize developers are their primary

“customer”
 Developers
 Goals do not match architects’

 Not focused on making architecture successful

 Focused on

 Satisfying functional, quality, and scheduling

requirements
 Subsystems for which they are responsible

16
Software Architecture: Foundations, Theory, and Practice

Architects As Consultants (cont.)

 Developers must be convinced to

 Learn, adhere to, & effectively leverage architecture

 Architects need to make these tasks reasonably

easy
 Document & report architecturally-relevant
modifications
 Architects need to make clear what’s
architecturally-relevant
 “Where are load bearing walls?”

17
Software Architecture: Foundations, Theory, and Practice

Architects As Leaders
 Must be technical leader
 Based on knowledge & achievement
 Command respect by ideas, expertise, words, & actions
 Cannot rely on position in org chart
 Must do so without managerial authority
 Ensures that design decisions, guidelines, and rules are
followed
 To improve productivity & quality, injects
 New ideas, solutions, & techniques
 Mentor newcomers & junior people
 Make decisions & help assure their implementation
 Enlist help of others in doing so
18
Software Architecture: Foundations, Theory, and Practice

Architects As Technologists
 Understand software development approaches
 E.g., object-oriented (OO) & component-based
 Understand fundamental technologies
 Operating system/networking
 Middleware
 Security
 Databases
 Graphical user interface (GUI) toolkits
 Keep on top of trends
 E.g., Cloud Computing, NoSQL Databases, RESTful Web Services
 Demonstrated expertise in
 System modeling
 Architectural trade-off analysis
 Tying architectural solutions to system requirements

19
Software Architecture: Foundations, Theory, and Practice

Architects As Cost Estimators

 Must understand financial ramifications of architectural

choices
 Green-field vs. Brown-field development
 Cost of COTS adoption
 Cost of development for reuse
 Company’s financial stability & position in marketplace
 Technologically superior solution is not always most
appropriate one
 Impact on cost & schedule
 Quick, approximate cost estimations are often sufficient
 Detailed cost estimation techniques can be applied
once set of candidate solutions is narrowed down 20
Software Architecture: Foundations, Theory, and Practice

Architects As Cheerleaders
 Especially needed on long, large, complex projects
 Development teams work in trenches on small subsets of project
 Managers lose sight of overall project goals
 Customers get impatient from long wait
 Must
 Maintain high-level vision with necessary details sprinkled in

 Convince different stakeholders of architecture’s

 Beauty
 Utility
 Adaptability
 Technological impact
 Financial impact
 Keep the troops’ morale high

21
Software Architecture: Foundations, Theory, and Practice

Architects As Politicians
 Must get key organization players committed to
architecture
 Must do a lot of influencing themselves
 Find out who the key players are
 Find out what they want
 Find out the organization behind the organization
 Architects must continuously
 Listen
 Network
 Articulate
 Sell vision
 See problem from multiple viewpoints
22
Software Architecture: Foundations, Theory, and Practice

Architects as Salespeople

 For many of the above reasons, architects must sell

 Overall vision
 Technological solutions
 Key properties of architecture
 Key properties of eventual system that architecture
will directly enable
 Cost/schedule profile
 Importance of sticking to architecture
 Penalties of deviating from it

23
Software Architecture: Foundations, Theory, and Practice

Software Architecture Team

 Collection of software architects

 Typically stratified
 Team size fluctuates during life of project
 1 architect per 10 developers during project inception
 1 architect per 12-15 developers in later stages
 Architects may
 Become subsystem development leads
 Maintainers of grand vision on development team
 Bridges to “central” architecture team for duration
of project
 Be shifted to other projects
 After project’s architecture is sufficiently stable
24
Software Architecture: Foundations, Theory, and Practice

Role of Architecture Team

 Define software architecture

 Maintain architectural integrity of software
 Assess technical risks associated with design
 Propose order & contents of development
iterations
 Coordinate & coexist with other teams
 Assist in project management decisions
 Assist marketing in future product definition
25
Software Architecture: Foundations, Theory, and Practice

Defining Software Architecture

 The architecture team must define

 Major design elements
 System organization/structure
 The way major elements interact

 Works with system engineers & development teams

26
Software Architecture: Foundations, Theory, and Practice

Maintaining Architectural Integrity

 The architecture team develops & maintains guidelines
for
 Design
 Programming
 Helps with reviews
 Approves
 Changes to interfaces of major components
 Departures from guidelines
 Final arbiter on aesthetics
 Assists change control board with resolving software
problems

27
Software Architecture: Foundations, Theory, and Practice

Assessing Technical Risks

 The architecture team maintains lists of perceived risks

 May propose exploratory studies or prototypes

28
Software Architecture: Foundations, Theory, and Practice

Ordering & Content Of Development

Iterations
 The architecture team determines order & contents of
iterations based on
 Selected scenarios

 Services to be studied & implemented

 Helps development teams transition from architectural

design to more detailed design

29
Software Architecture: Foundations, Theory, and Practice

Coordinate & Coexist with Other

Teams
 No structural difference between architecture
team & other teams
 Just focused on higher level issues
Architecture team Software Management

Architecture design, scenarios, & guidelines

Development Team A Development Team B Development Team C

feedback Modules, subsystems, & tests

Integration & Test Team

30
Software Architecture: Foundations, Theory, and Practice

Pitfalls of Software Architect

Teams
 Imbalance of skills
 Lack of software development experience
 Lack of domain expertise
 Lack of authority
 Team acts as committee
 Life in ivory tower
 Confusing tools/techniques/methodologies with
architectures
 Procrastination
31
Software Architecture: Foundations, Theory, and Practice

Pitfall: Lack Of Authority

 Problem
 What incentives are there for group leaders to
 Follow recommendations of architecture team?
 Report progress or problems to architecture team?
 Architect team
 Frequently has no explicit authority
 Architects are not managers
 Just
another team in organization
 Problem compounded when external architect or
architecture team is hired
 Solution:
 Must influence based on skills & experience
 Must communicate 32
Software Architecture: Foundations, Theory, and Practice

Pitfall: Life In Ivory Tower

 Problem
 Developers & managers must be aware of architecture team’s
existence & role
 Solution
 Team must continuously communicate with rest of personnel
 Team must be co-located with rest of project personnel
 Do not use team as retirement home for ageing developers
 Architecture team must recognize & adjust to organizational
realities
 Technological base
 Personnel issues
 Organizational politics
 Market pressures

33
Software Architecture: Foundations, Theory, and Practice

Pitfall: Imbalance Of Skills

 Problem
 Predominant expertise in one area creates imbalance
 Database
 GUI
 Networking
 Systems
 Imbalance may affect how architecture is
 Designed
 Communicated
 Evolved
 Solution
 Balanced architecture team appropriate to
 Project type & size
 Problem domain
34
 Personnel
Software Architecture: Foundations, Theory, and Practice

Pitfall: Confusing Tools With

Architectures
 Problem
 Common pitfall
 Usual culprits
 Databases
 GUI
 Case tools
 More recently, the culprit is middleware
 “Our architecture is CORBA”
 Tools tend to influence architecture
 Solution
 Balanced architecture team

35
Software Architecture: Foundations, Theory, and Practice

Pitfall: Procrastination
 Problem
 Waiting until the team is convinced it is able to make the “right”
decision
 Incomplete & changing information yields indecision
 Architects’ indecision impacts other teams
 Domino effect, may paralyze entire project
 Solution
 Often better to make a decision than suspend the project
 Make educated guesses
 Document rationale for decision
 Document known consequences
 Change decision if/when better alternatives present themselves
 Be decisive
 Being an effective architect demands rapidly making tactical decisions &
living with resulting anxiety
 Suboptimal decisions based on incomplete information
36
Software Architecture: Foundations, Theory, and Practice

Summary

 Designate architect or assemble architecture team to be

creators & proponents of common system goal/vision
 Architects must be experienced at least in problem
domain & software development
 Software architect is a full-time job
 Charter of software architecture team should
 Clearly define its roles & responsibilities
 Clearly specify its authority
 Do not isolate software architecture team from the rest
of project personnel
 Avoid pitfalls
37