Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. People, Roles, and Teams Software Architecture Lecture 27.

Similar presentations


Presentation on theme: "Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. People, Roles, and Teams Software Architecture Lecture 27."— Presentation transcript:

1 Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. People, Roles, and Teams Software Architecture Lecture 27

2 Software Architecture: Foundations, Theory, and Practice The Need The greatest architectures are the product of u A single mind or u A very small, carefully structured team Rechtin, Systems Architecting: Creating & Building Complex Systems, 1991, p21 Every project should have exactly 1 identifiable architect u For larger projects, principal architect should be backed up by architect team of modest size Booch, Object Solutions, 1996 2

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

4 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

5 Software Architecture: Foundations, Theory, and Practice Blending the Skill Set May need different people & skills based on u Characteristics of project & domain u Lifecycle “phase” u Type of architecture Enterprise vs. product-line vs. product u Distinction between junior & senior architects Each architect should possess some subset of above skills What architects are usually not in a project u Developers – though they may prototype their ideas u Managers – except in small organizations 5

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

7 Software Architecture: Foundations, Theory, and Practice Architects As Domain Experts Software engineering expertise is not enough Problem domain nuances u Maturity u Stability u System user profile May greatly affect selected & developed architectural solutions u Distribution u Scale u Evolvability Requires artifacts that model problem space u Not solution space 7

8 Software Architecture: Foundations, Theory, and Practice Team Needs Balance & Shared Vocabulary 8 D S Too little domain knowledge

9 Software Architecture: Foundations, Theory, and Practice Team Needs Balance & Shared Vocabulary 9 D D S Too little domain knowledge S Too little SWE knowledge

10 Software Architecture: Foundations, Theory, and Practice Team Needs Balance & Shared Vocabulary 10 D D S Too little domain knowledge S Too little SWE knowledge D S No Shared Vocabulary

11 Software Architecture: Foundations, Theory, and Practice Team Needs Balance & Shared Vocabulary 11 D D S Too little domain knowledge S Too little SWE knowledge D S No Shared Vocabulary D S Good!

12 Software Architecture: Foundations, Theory, and Practice Architects As Communicators At least ½ of the job Must u Listen to stakeholder concerns u Explain the architecture u Negotiate compromises Need good communication skills u Writing u Speaking u Presenting 12

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

14 Software Architecture: Foundations, Theory, and Practice Architects Also Communicate With System engineers u Coordinate requirements & solutions u Explain how architecture addresses key concerns Customers u Determine needs u Explain how architecture addresses requirements Users u Determine needs u Explain how architecture addresses those needs u Listen to problems Marketers u Get/help set goals & directions u Explain how architecture addresses marketing objectives 14

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

16 Software Architecture: Foundations, Theory, and Practice Architects As Consultants Architects must recognize developers are their primary “customer” Developers u Goals do not match architects’ u Not focused on making architecture successful u Focused on Satisfying functional, quality, and scheduling requirements Subsystems for which they are responsible 16

17 Software Architecture: Foundations, Theory, and Practice Architects As Consultants (cont.) Developers must be convinced to u Learn, adhere to, & effectively leverage architecture Architects need to make these tasks reasonably easy u Document & report architecturally-relevant modifications Architects need to make clear what’s architecturally-relevant  “Where are load bearing walls?” 17

18 Software Architecture: Foundations, Theory, and Practice Architects As Leaders Must be technical leader u Based on knowledge & achievement u Command respect by ideas, expertise, words, & actions u 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 u New ideas, solutions, & techniques u Mentor newcomers & junior people Make decisions & help assure their implementation u Enlist help of others in doing so 18

19 Software Architecture: Foundations, Theory, and Practice Architects As Technologists Understand software development approaches u E.g., object-oriented (OO) & component-based Understand fundamental technologies u Operating system/networking u Middleware u Security u Databases u Graphical user interface (GUI) toolkits Keep on top of trends u E.g., CORBA, COM/DCOM, JavaBeans, UML, XML Demonstrated expertise in u System modeling u Architectural trade-off analysis u Tying architectural solutions to system requirements 19

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

21 Software Architecture: Foundations, Theory, and Practice Architects As Cheerleaders Especially needed on long, large, complex projects u Development teams work in trenches on small subsets of project u Managers lose sight of overall project goals u Customers get impatient from long wait Must u Maintain high-level vision with necessary details sprinkled in u Convince different stakeholders of architecture’s Beauty Utility Adaptability Technological impact Financial impact u Keep the troops’ morale high 21

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

23 Software Architecture: Foundations, Theory, and Practice Architects as Salespeople For many of the above reasons, architects must sell u Overall vision u Technological solutions u Key properties of architecture u Key properties of eventual system that architecture will directly enable u Cost/schedule profile u Importance of sticking to architecture u Penalties of deviating from it 23

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

25 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

26 Software Architecture: Foundations, Theory, and Practice Defining Software Architecture The architecture team must define u Major design major elements u System organization/structure u The way major elements interact Works with system engineers & development teams 26

27 Software Architecture: Foundations, Theory, and Practice Maintaining Architectural Integrity The architecture team develops & maintains guidelines for u Design u Programming Helps with reviews Approves u Changes to interfaces of major components u Departures from guidelines Final arbiter on aesthetics Assists change control board with resolving software problems 27

28 Software Architecture: Foundations, Theory, and Practice Assessing Technical Risks The architecture team maintains lists of perceived risks May propose exploratory studies or prototypes 28

29 Software Architecture: Foundations, Theory, and Practice Ordering & Content Of Development Iterations The architecture team determines order & contents of iterations based on u Selected scenarios u Services to be studied & implemented Helps development teams transition from architectural design to more detailed design 29

30 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 30 Architecture team Software Management Development Team A Development Team B Development Team C Integration & Test Team feedback Architecture design, scenarios, & guidelines Modules, subsystems, & tests

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

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

33 Software Architecture: Foundations, Theory, and Practice Pitfall: Life In Ivory Tower Problem u Developers & managers must be aware of architecture team’s existence & role Solution u Team must continuously communicate with rest of personnel u Team must be co-located with rest of project personnel u Do not use team as retirement home for ageing developers u Architecture team must recognize & adjust to organizational realities Technological base Personnel issues Organizational politics Market pressures 33

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

35 Software Architecture: Foundations, Theory, and Practice Pitfall: Confusing Tools With Architectures Problem u Common pitfall u Usual culprits Databases GUI Case tools u More recently, the culprit is middleware “Our architecture is CORBA” u Tools tend to influence architecture Solution u Balanced architecture team 35

36 Software Architecture: Foundations, Theory, and Practice Pitfall: Procrastination Problem u Waiting until the team is convinced it is able to make the “right” decision u Incomplete & changing information yields indecision u Architects’ indecision impacts other teams Domino effect, may paralyze entire project Solution u 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 u Being an effective architect demands rapidly making tactical decisions & living with resulting anxiety Suboptimal decisions based on incomplete information 36

37 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 u Clearly define its roles & responsibilities u Clearly specify its authority Do not isolate software architecture team from the rest of project personnel Avoid pitfalls 37


Download ppt "Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. People, Roles, and Teams Software Architecture Lecture 27."

Similar presentations


Ads by Google