Home | Login | Recent Changes | Search | All Pages | Help

SessionTwo018

C18.Building You as an Architect
BobKing and Other Architects

Learning Objectives:

• consider what an 'ideal' system architect might be
• consider how system architects become what they (we) are
• find something that might help us work better with system architects or
• find something that might help us work better as system architects

Wisdom & Experience

• Spend time maintaining legacy code (BobLee)
• Ruthlessly promote and attend retrospectives (BobLee)
• Listen to coders and testers (BobKing)
• Define a team of architects (System, Test, Outbound Marketing, etc...) for a project
• Document clear, verifiable requirements and involve testers early (BeckyWinant)
• Perhaps, instead of requirements (as if this is "it"), we should call the first stage: Expectations. Would this change things? (BeckyWinant)
• Modeling can express something more simply and clearly than words (BeckyWinant)
• One technique doesn't fit all (BobLee)
• Read Jerry's older books (like Quality Before Design) (BobLee)
• design for failure and debuggability (KenEstes)

Current Challenges / Wisdom Growth Opportunities

• Applying Agile methods to larger projects (BobLee)
• How to stay anchored as a project architect (BobKing)
• How to foment a complementary relationship between managers and architects - especially in hiring /interviewing (BobLee)
• How to get all interested and responsible groups involved from the beginning of a project - or how to find the second best alternative (SherryHeinze)
• How to bridge the gap between theory and reality or how to do what I know(BobKing)
• Can one person do a good enough job of being the project manager and the lead technician on a project? (BobKing)
• How to get people to work at the level of requisite detail. (BeckyWinant)
• How to manage trade-off between requisite detail and freedom to change (BobLee)
• How do we make "requirements" a less daunting process and easier to change? (BeckyWinant)
• How to start a discussion group on software design (KeithRay)
• How to describe the roles and responsibilities of a system architect to a business architect (CherDevey)

StartingTheArchitectureSessionEarly

Notes from the session

We started by writing current challenges on note cards and throwing them into the center:

• what role should an architect play?
• How to effectively intervene into a team or organization?
• How to get creative solutions in engineering?
• Vision | Architecture | Design
• Raising skill and knowledge level of fellow employees
• Different rythms of architecture and design
• Communicating vision
• Creating process for design
• Inclusive architecture design process - Dwayne Phillps' Software Project Manger's Handbook
• Top down control; too big of a hurry; no time to think
• Not getting buy in
• Communication - vague requirements
• no process

We attempted clustered the cards based on relationships with one another and began to talk of the architect's role which generated more discussion and cards:

• architect is involved in re-design
• raises issues particularly surrounding larger technical issues with business impact
• visionary and technical leadership
• At beginning, structure work based on structure of solution
• Architects close the gap between what we want and what we're getting
• Design for failure
• Architect's role changes over time and circumstance
• Reliability, usability, elegance, efficiency, maintainability = "good design"
• Find what might be possible: requirements and failures
• Design across teams
• Keep an eye on what might be
• Architect leads strategic decisions based on technology

Which led us into a discussion of the contexts inside of which an architect works:

• Visioning
• Product
• Relationships - particulary with project managers and management
• Project Approach - how to organize to get the work done
• Requirements Gathering
• Design - applying design principles
• Test
• Build - enforcement?
• Implementation - adaptation guidance (with build - determining what short cuts can be made.)
• Coordination
• Process - learning, application of better practices
• Decision Making - support and actual deciding
• More non-waterfall methods require more people acting as architects

A definition (tongue in cheek?):

An architect leads whatever aspect of a project that is most important at that time.

We moved on to another card: How to include people. This list resulted:

• visible paper prototypes (like conference room prototypes or cards on the wall)
• wiki, twiki and other collaboration tools
• invitations for comments, questions and agreements
• all hands meetings to offer up and discuss what is going on
• inclusion should be an option
• figure who responsible and impacted parties are and invite them in
• participative individual processes for project planning, requirements gathering (like KJ - what is KJ again?) and design
• LISTEN and ACKNOWELDGE CONTRIBUTIONS
• Build trust in the organization; engender openness
• Pay attention to the music

BobKing 2002.11.09