©2012 Improving Enterprises, Inc. Architecture in an Agile World Don linkedin.com/in/donmcgreal

©2012 Improving Enterprises, Inc.

©2012 Improving Enterprises, Inc.

©2012 Improving Enterprises, Inc. Agenda Agile and Architecture Reducing Technical Risks Team Makeup & Roles Architecture Anti-Patterns

©2012 Improving Enterprises, Inc. 5 What is Software Architecture?

©2012 Improving Enterprises, Inc. 6 Business Goals What business goals could affect our Architectural decisions?

©2012 Improving Enterprises, Inc. 7 Non-Functional Requirements Usability Scalability Portability Maintainability Availability Accessibility Supportability Security Performance Cost Legal Cultural...

©2012 Improving Enterprises, Inc. Does it compare to building this? House

©2012 Improving Enterprises, Inc. … or this? ???

©2012 Improving Enterprises, Inc. Level of Complexity Simple Everything is known Complicated More is known than unknown Complex More is unknown than known Chaotic Very little is know Source: Ralph Stacey, University of Hertfordshire

©2012 Improving Enterprises, Inc. Empirical vs Defined Processes DefinedEmpirical Predict the Future Initial information and assumptions are valid throughout the planning horizon. Adapt to the Future Frequent inspection/adaptation rather than predictive planning Examples: assembly line, construction, accounting, orchestra Examples: sales, marketing, creative writing, band PlanDo PDPDPDPD

©2012 Improving Enterprises, Inc. Business Case Financing Scope & Approach Contracts Initial Release Plan Assemble Team Sprint Planning 1 day Acceptance Defined Team commits Tasks created Product Owner establishes vision and prioritizes Product Backlog Sprint 1 to 4 weeks Team (BA, QA, Dev, etc.) creates and estimates Sprint Backlog (tasks) Releasable Increment Daily Scrum < 15 minutes Burn down Sprint Review 1/2 day Sprint Retrospective 1/2 day Burn up velocity Scrum

©2012 Improving Enterprises, Inc. BigDUF or LittleDUF? MondayTuesdayWednesdayThursdayFriday Sprint 1 Sprint 2 Sprint Planning LDUF PB Grooming PB Creation PB Sizing Release Planning PB Grooming Retrospective Sprint Review Retrospective Sprint Review

©2012 Improving Enterprises, Inc Non-Functional Requirements Usability Scalability Portability Maintainability Availability Accessibility Supportability Security Performance Cost Legal Cultural...

©2012 Improving Enterprises, Inc Non-Functional Requirements Usability Scalability Portability Maintainability Availability Accessibility Supportability Security Performance Cost Legal Cultural... Captured as: Acceptance Criteria Definition of Done Stories

©2012 Improving Enterprises, Inc. Sprint Capacity over Time

©2012 Improving Enterprises, Inc. … but one is different Usability Scalability Portability Maintainability Availability Accessibility Supportability Security Performance Cost Legal Cultural...

©2012 Improving Enterprises, Inc. Most Important Architecture Goal? Maintainability

©2012 Improving Enterprises, Inc. Agenda Agile and Architecture Reducing Technical Risks Team Makeup & Roles Architecture Anti-Patterns

©2012 Improving Enterprises, Inc. Technical Debt in an Unhealthy Team Time available for new feature development Time struggling with complexity and debt *From Scrum.org’s Professional Scrum Master certification course

©2012 Improving Enterprises, Inc. Yuck. *From Scrum.org’s Professional Scrum Master certification course

©2012 Improving Enterprises, Inc. Stabilization: Plan vs. Reality Plan 9 Sprints, 3 RCs and then release. 800-person development organization. RC PPPDDD PPPDDD PPPDDD Release Actual 5+ month stabilization was required to release. Mostly due to performance defects. RC PPPDDD PPPDDD PPPDDD Release Stabilization *From Scrum.org’s Professional Scrum Master certification course

©2012 Improving Enterprises, Inc. How do you get out of debt? *From Scrum.org’s Professional Scrum Master certification course 1.Stop creating debt 2.Make a small payment each Sprint 3.Repeat from 2

©2012 Improving Enterprises, Inc. Sprint Planning 1 day Acceptance Defined Team commits Tasks created Product Owner establishes vision and prioritizes Product Backlog Sprint 1 to 4 weeks Team (BA, QA, Dev, etc.) creates and estimates Sprint Backlog (tasks) Releasable Increment Daily Scrum < 15 minutes Sprint Retrospective 1/2 day Sprint Review 1/2 day Done Task? Unit Tested Code Reviewed Checked-in others? Done Task? Unit Tested Code Reviewed Checked-in others? Done Feature? Acceptance Tested On Test Server Performance Tested others? Done Feature? Acceptance Tested On Test Server Performance Tested others? Sprint Review 1/2 day Done Sprint? Versioned In UAT Integrated others? Done Sprint? Versioned In UAT Integrated others? Releasable Increment Done Release? Compliance Labeled Training others? Done Release? Compliance Labeled Training others? Definition of Done

©2012 Improving Enterprises, Inc. Paying off Debt Feature Name ScheduledActiveBlockedClosed Feature 1 Task1.4Task1.2Task1.3Task1.1 Feature 2Task2.3Task2.1 Task2.2 Feature 3Task3.3Task3.1 Task3.2 Task3.4

©2012 Improving Enterprises, Inc. Paying off Debt Feature Name ScheduledActiveBlockedClosed Feature 1 Task1.4Task1.2Task1.3Task1.1 Design Task Feature 2Task2.3 Upgrade Task Task2.1 Task2.2 ENGINEERING & MAINTENANCE Eng. Task 1 Bug Eng. Task 2Upgrade Task

©2012 Improving Enterprises, Inc. Design Patterns != Good Design

©2012 Improving Enterprises, Inc. What is a Pattern?

©2012 Improving Enterprises, Inc. Design Pattern Structure Pattern Name: A descriptive and unique name that helps in identifying and referring to the pattern. Intent: A description of the goal behind the pattern and the reason for using it. Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used. Structure: A graphical representation of the pattern, such as Class diagrams and Interaction diagrams. Consequences: A description of the results, side effects, and trade offs caused by using the pattern. Implementation: A description of an implementation of the pattern; the solution part of the pattern. Sample Code: An illustration of how the pattern can be used in a programming language Known Uses: Examples of real usages of the pattern. Related Patterns: Other patterns that have some relationship with the pattern. Pattern Name: A descriptive and unique name that helps in identifying and referring to the pattern. Intent: A description of the goal behind the pattern and the reason for using it. Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used. Structure: A graphical representation of the pattern, such as Class diagrams and Interaction diagrams. Consequences: A description of the results, side effects, and trade offs caused by using the pattern. Implementation: A description of an implementation of the pattern; the solution part of the pattern. Sample Code: An illustration of how the pattern can be used in a programming language Known Uses: Examples of real usages of the pattern. Related Patterns: Other patterns that have some relationship with the pattern.

©2012 Improving Enterprises, Inc. Core Aspects of Good Design ✓ GoodDesign ✓ L✓ Low Coupling ✓ H✓ High Cohesion

©2012 Improving Enterprises, Inc. Coupling vs. Cohesion

©2012 Improving Enterprises, Inc. Core Aspects of Bad Design. X BadDesign Duplication Ambiguity. Complexity

©2012 Improving Enterprises, Inc. Bad Smells The Bloaters The OO Abusers The Change Preventers The Dispensables The Couplers Long Method, Large Class, Data Clumps Type Attribute, State Attribute, Indecent Exposure Lazy Class, Dead Code, Data Class Feature Envy, Message Chains, Middleman Divergent Change, Shotgun Surgery, Non-localized Logic

©2012 Improving Enterprises, Inc. How do we get there? ✓ GoodDesign ➔ X BadDesign

©2012 Improving Enterprises, Inc. Refactoring ✓ GoodDesign ➔ X BadDesign Refactoring to / towards / away from DesignPatternsBadSmells

©2012 Improving Enterprises, Inc. Refactoring ✓ GoodDesign ➔ X BadDesign Refactoring to / towards / away from DesignPatternsBadSmells Encapsulate Field Extract Method Generalize Type Pull Up Push Down Rename Method...

©2012 Improving Enterprises, Inc. Agenda Agile and Architecture Reducing Technical Risks Team Makeup & Roles Architecture Anti-Patterns

©2012 Improving Enterprises, Inc. Vertical Teams Business Presentation DB Persistence TEAM 1 TEAM 2TEAM 3TEAM 4

©2012 Improving Enterprises, Inc. Vertical Features Business Presentation DB Persistence TEAM 1 TEAM 2TEAM 3TEAM 4 Features

©2012 Improving Enterprises, Inc. Ideal Team Composition VP QA Manager QA Product Manager Dev Architecture Manager Architect DBA Manager DBA Team A Team B

©2012 Improving Enterprises, Inc. Realistic Team Composition VP QA Manager QA Product Manager Dev Architecture Manager Architect DBA Manager DBA Team A Team B What now?

©2012 Improving Enterprises, Inc. Specialists 1. IDEAL: Specialists are dedicated to a team and participate throughout the sprint. 2. REALISTIC: Specialists service multiple teams and participate as needed. 3. WORST CASE: Specialists do not participate in a sprint, but someone on the team takes responsibility for working with them.

©2012 Improving Enterprises, Inc. Architect Roles Enterprise Architect (policies & standards) Infrastructure Architect (systems & network design) Solution Architect (advisory & governance) Application Architect (on teams)

©2012 Improving Enterprises, Inc. Where to Plug In? MondayTuesdayWednesdayThursdayFriday Sprint 1 Sprint 2 Sprint Planning LDUF PB Grooming PB Creation PB Sizing Release Planning PB Grooming Retrospective Sprint Review Retrospective Sprint Review

©2012 Improving Enterprises, Inc. Agenda Agile and Architecture Reducing Technical Risks Team Makeup & Roles Architecture Anti-Patterns

©2012 Improving Enterprises, Inc. Logic in Wrong Layer Think about what would need to change in other layers if one was swapped out or modified. Business Presentation Persistence Controller Façade Integration SharedShared

©2012 Improving Enterprises, Inc. No Architectural Vision A single architecture vision should be well defined and communicated across the team and organization. The vision should map to business goals and objectives. All decisions should be made with this vision in mind.

©2012 Improving Enterprises, Inc. Swiss Army Knife Do not try to anticipate every possible use of the system and over-design the interfaces - this will lead to needless complexity. Do the simplest thing that works, within the Architectural Vision.

©2012 Improving Enterprises, Inc. Threading Do your homework! ✓ Typically not necessary ✓ Adds massive complexity ✓ Hard to maintain, test, and debug ✓ Rely on the application frameworks threads

©2012 Improving Enterprises, Inc. Caching Do your homework! ✓ Do you even need a cache? ✓ Can you keep everything in memory? ✓ Rely on persistence framework’s caching

©2012 Improving Enterprises, Inc. Ivory Tower Architect It is very hard to truly know the best solutions for design problems if you are not working (coding) on the project. It takes many iterations of a solution before it finally works - so you can’t suggest a solution then leave.

©2012 Improving Enterprises, Inc. Custom Frameworks May seem like a good idea at first. But... Who will maintain it? Who will upgrade it when it’s depended upon libraries are upgraded? Java version? How long will your new hires need to learn it? Who will teach them? Look for an off-the-shelf solution first. You can hire/train people on it easier. It will be upgraded for you.

©2012 Improving Enterprises, Inc. So, to sum up…

©2012 Improving Enterprises, Inc. Emergent Architecture Agile architects build plans and foundations that embrace change Today’s technologies and enterprise frameworks give us this flexibility We just need to take advantage of them.

©2012 Improving Enterprises, Inc. Questions? Don linkedin.com/in/donmcgreal

©2012 Improving Enterprises, Inc. Thank You! Don linkedin.com/in/donmcgreal

©2012 Improving Enterprises, Inc. Questions? Hemant Elhence

©2012 Improving Enterprises, Inc. Confidential Synerzip in a Nut-shell 1. Software product development partner for small/mid- sized technology companies Exclusive focus on small/mid-sized technology companies, typically venture-backed companies in growth phase By definition, all Synerzip work is the IP of its respective clients Deep experience in full SDLC – design, dev, QA/testing, deployment 2. Dedicated team of high caliber software professionals for each client Seamlessly extends client’s local team, offering full transparency Stable teams with very low turn-over NOT just “staff augmentation”, but provide full mgmt support 3. Actually reduces risk of development/delivery Experienced team - uses appropriate level of engineering discipline Practices Agile development – responsive, yet disciplined 4. Reduces cost – dual-shore team, 50% cost advantage 5. Offers long term flexibility – allows (facilitates) taking offshore team captive – aka “BOT” option

©2012 Improving Enterprises, Inc. Our Clients

©2012 Improving Enterprises, Inc Call Us for a Free Consultation! Hemant Elhence Thanks!