This document provides advice to project managers on working with software architects. It defines what software architecture is and discusses different styles such as big design up front, emerging architecture, and good enough architecture. It also covers what architects do including technical oversight, standards enforcement, and long term technical visioning. The document advises involving architects early and regularly throughout the project lifecycle from initiation and planning through execution, monitoring, and closing. Architects are positioned as key partners to project managers.

1. Working with Software Architects
Advice to Project Managers
Yaniv Pessach, PMP, CSM
www.YanivPessach.com

2. About the Presenter
• Yaniv Pessach, PMP, CSM, has served as a Program
Manager, Senior Software Developer, Development
Manager, Software Architect and Principal Engineer for
companies such as Microsoft, Amazon, and Walgreens
eCommerce. He received his graduate degree from Harvard
University in Information Technology - Software
Engineering.
• As both a PMP and a Certified Scrummaster, he believes in
merging aspects from traditional and agile practices to
achieve highly functioning teams and successful projects.
• He currently works as a Principal Software Design Engineer
within Microsoft's Online Services Division.

3. About the Presentation
• A version of this presentation originally
presented to PMI.org ISCoP via the web to
1100 online project managers
• The recording of the full original presentation
should still be available to PMI.org members
on their website

4. What is Software Architecture
• Practices in the 10,000ft design of software
• Define software elements, their relations and
responsibilities
– Team structure often follows component
decomposition
• Somewhere between requirement analysis
and design

5. More about Software Architecture
• Solve for multiple stakeholders
• Tries to simplify each component
• Enforces reuse and standardization
• Conceptual integrity - same ‘feel’ and uses
similar architectural patterns

6. Big Design Up Front
• ‘Waterfall’
• Detailed specifications and SoW prior to work
• Cons: Slow ramp, slow adaptively to change
• Pro: Contracts, weak teams
• Currently out of favor

7. Emerging Architecture
• AKA Emergent Design
• Build, Identify commonalities, Refactor
• Minimal design
• Associated with Agile
• Caveat - If refactoring skipped, quality
degrades quickly

8. Good Enough Architecture
• And other ‘compromise’ architecture styles
• Most common in real-world companies
– Regardless of what architects claim

9. Time Boxed Architecture
• Time boxing is an agile concept
• Architecture can be reiterative
• A alternative to no or too much architecture
• Fits within or between sprints (if agile)
• In planning and replanning (if not)

10. Also Done By Architects
• Technical Oversight
• Second Opinion
• Technical Tie-breaking
• Standardization
• Long Term Technical Vision
• Enforce tech-focus => reduce politics

11. Aspects of Software Architecture
• Deliverables
• Patterns
• Styles
• Not yet a settled field – multiple viewpoints,
art not science

12. Judging Architecture
• business drivers
• high level architecture
• Possible architectural approaches
• Architectural attributes
• Prioritize
• Stakeholder input

13. Timelines - Initiating
• Requirement Analysis
• Project Cost/Estimate
• Charter

14. Timelines - Planning
• Scope
• Team Selection
• Identifying Activities
• Schedule
• Budget
• Risk

15. Timelines - Execution
• Architectural Artifacts
• Technical Oversight
• Team Education
• Enable Technical Collaboration
• Arbitrate Technical Ties

16. Timelines - Monitoring
• “Second Opinion” on project health
• Advise on error/course correction

17. Timelines - Closing
• Evaluate State
• Unique to the software world?
Statement of Technical Debt

18. Volatile Effort Estimates
• We architect best when we finish a project
• Spectrum between undisciplined code and
perfectionism

19. Working with Senior ICs
• Competing Priorities, limited time
• Assigning tasks approach may not work
• Appeal to interest, benefits

20. Architects as PMs
• Coordinate
• Centralize
• Assign

21. Key Take-aways
• The architect(s) are key partners
– Understand their role
– Involve early
– Listen carefully
– Check in regularly until Closing
• Assign technological decisions to
architects, business decisions to business
owners, and project decisions to project
managers

22. Contact
• Let me know if you have any more questions
• My website on www.yanivpessach.com
• Email via pmi@yanivpessach.com