Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "©2012 Improving Enterprises, Inc. Architecture in an Agile World Don linkedin.com/in/donmcgreal."— Presentation transcript:

1 ©2012 Improving Enterprises, Inc. www.synerzip.com Architecture in an Agile World don.mcgreal@ImprovingEnterprises.com Don McGreal @donmcgreal linkedin.com/in/donmcgreal

2 ©2012 Improving Enterprises, Inc. www.synerzip.com

3 ©2012 Improving Enterprises, Inc. www.synerzip.com

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

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

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

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

8 ©2012 Improving Enterprises, Inc. www.synerzip.com Does it compare to building this? House

9 ©2012 Improving Enterprises, Inc. www.synerzip.com … or this? ???

10 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

11 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

12 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

13 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

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

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

16 ©2012 Improving Enterprises, Inc. www.synerzip.com Sprint Capacity over Time

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

18 ©2012 Improving Enterprises, Inc. www.synerzip.com Most Important Architecture Goal? Maintainability

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

20 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

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

22 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

23 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

24 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

25 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

26 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

27 ©2012 Improving Enterprises, Inc. www.synerzip.com Design Patterns != Good Design

28 ©2012 Improving Enterprises, Inc. www.synerzip.com What is a Pattern?

29 ©2012 Improving Enterprises, Inc. www.synerzip.com 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.

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

31 ©2012 Improving Enterprises, Inc. www.synerzip.com Coupling vs. Cohesion

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

33 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

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

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

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

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

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

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

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

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

42 ©2012 Improving Enterprises, Inc. www.synerzip.com 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.

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

44 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

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

46 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

47 ©2012 Improving Enterprises, Inc. www.synerzip.com 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.

48 ©2012 Improving Enterprises, Inc. www.synerzip.com 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.

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

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

51 ©2012 Improving Enterprises, Inc. www.synerzip.com 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.

52 ©2012 Improving Enterprises, Inc. www.synerzip.com 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.

53 ©2012 Improving Enterprises, Inc. www.synerzip.com So, to sum up…

54 ©2012 Improving Enterprises, Inc. www.synerzip.com 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.

55 ©2012 Improving Enterprises, Inc. www.synerzip.com Questions? don.mcgreal@ImprovingEnterprises.com Don McGreal @donmcgreal linkedin.com/in/donmcgreal

56 ©2012 Improving Enterprises, Inc. www.synerzip.com Thank You! don.mcgreal@ImprovingEnterprises.com Don McGreal @donmcgreal linkedin.com/in/donmcgreal

57 ©2012 Improving Enterprises, Inc. www.synerzip.com Questions? www.synerzip.com Hemant Elhence hemant@synerzip.com 469.322.0349

58 ©2012 Improving Enterprises, Inc. www.synerzip.com 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

59 ©2012 Improving Enterprises, Inc. www.synerzip.com Our Clients

60 ©2012 Improving Enterprises, Inc. www.synerzip.com 60 Call Us for a Free Consultation! www.synerzip.com Hemant Elhence hemant@synerzip.com 469.322.0349 Thanks!


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

Similar presentations


Ads by Google