Evolutionary Architecture And Design

Uploaded on

A story of how Evolutionary Architecture was practiced to build an in-house mini-ERP.

A story of how Evolutionary Architecture was practiced to build an in-house mini-ERP.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Evolutionary Architecture and Design
      • Pradyumn Sharma
      • Pragati Software Pvt. Ltd.
      • www.pragatisoftware.com
      • [email_address]
  • 2. Presenter: Pradyumn Sharma
    • CEO, Pragati Software (www.pragatisoftware.com).
    • 25 years in IT industry.
    • Training and consulting:
      • Agile Methodologies,
      • OOAD, UML,
      • Design Patterns,
      • Programming Logic.
  • 3. About Pragati Software
    • IT training and consulting.
    • About 100 employees. About 30 full-time trainers.
    • Wide range of subjects, clients.
    • In-house software development team.
  • 4. About Pragati Software Bangalore Chennai Hyderabad Mumbai Pune Ahmedabad Vadodara New Delhi Shimla Bhopal Kolkata Thiruvananthapuram
  • 5. Our Story…
    • Home-grown, ERP application.
    • CIS = Corporate Information System.
    • Key modules:
    CRM and sales: Clients Locations Persons Inquiries Proposals Visits etc Training operations: Work orders Training planning Training execution Feedback analysis etc Financial accounting: Billing Collections Payments TDS MIS reports etc.
  • 6. CIS : Corporate Information System
    • Backbone of the organization.
    • From transactional, operational work …
    • … to analysis, forecasting tool, strategic tool for decision-makers.
    • Currently, a team of 8 people, including one tester.
    • Technologies: VB.NET, ASP.NET, Oracle, Crystal Reports.
    • Using a combination of XP and Scrum practices.
  • 7. Disclaimer
    • No single right way of doing things.
    • Each project is different, following agile practices based on heresay / a book is not being agile.
  • 8. Architecture
    • What is architecture?
    • Do we need an architecture for a system?
    • When? How?
  • 9. A Traditional Approach…
    • Create and document a detailed architecture of the system
    • Create an application framework
    • Identify appropriate architecture and design patterns and apply them to the architecture
    • Review the architecture
    • etc.
  • 10. The Other Extreme…
    • No architecture?
    • Just start coding and refactor?
  • 11. Architecture and Design Evolution in CIS
    • Envision the architecture.
    • But, incrementally evolve the architecture and design.
    • Architecture and application framework implemented through implementation of stories, and refactoring.
    • Various architectural and design patterns applied over multiple sprints, through refactoring.
  • 12. Sprint Zero: Kick Start
    • Product vision:
      • Integrated, home-grown mini-ERP application, consisting of CRM, sales, training operations, and financial accounting.
    • Creation of minimal, initial Product Backlog. Examples:
      • Companies, locations.
      • Persons. Also persons within a company. Search, merge options.
      • Company classifications, person classifications.
      • Work orders: General data, venue details, plan dates, execution, participants’ feedback.
      • Cross-cutting requirement: maker-checker cycle.
      • Cross-cutting requirement: audit trail (change history).
  • 13. Cross-Cutting Requirement: Change History
  • 14. Cross-Cutting Requirement: Change History
  • 15. Sprint Zero: Kick Start
    • Product vision
    • Creation of minimal, initial Product Backlog
    • Architecture envisioning. Examples:
      • Layered, Distributed Architecture
      • Model-View Separation
      • Database Platform Independence
      • Creation of an Application Framework to handle common behavior, cross-cutting requirements
      • Concurrency
      • Performance
      • Security
      • User Interface
  • 16. First Sprint: Plan
    • Goals:
      • Establish development environment.
      • Implement one story (Cities master).
      • Using this story, establish a layered and distributed architecture.
      • Also using this story, implement the maker-checker cycle and audit trail.
      • Build a miniscule, but deployable product.
    • No time-boxing. No effort estimation.
    • Only two developers initially.
  • 17. First Sprint: Execution
    • Acceptance tests
    • UI design, approval from end-users.
    • Started with a typical form-centric implementation, no architecture.
  • 18. Form-Centric Design Form_load: fetch data from Cities table populate the grid New_click: display blank entry form //…on return from the entry form re-populate the grid from Cities table etc. OK_click: validate data INSERT into Cities values … exit form etc.
  • 19. First Sprint: Execution
    • Acceptance tests
    • Started with a typical form-centric implementation, no architecture.
    • Refactored into a layered architecture.
  • 20. Layered Architecture D A T A B A S E
  • 21. First Sprint: Execution
    • Acceptance tests
    • Started with a typical form-centric implementation, no architecture.
    • Refactored into a layered architecture.
    • Refactored into a distributed architecture.
  • 22. Distributed Architecture D A T A B A S E
  • 23. First Sprint: Execution
    • Acceptance tests
    • Started with a typical form-centric implementation, no architecture.
    • Refactored into a layered architecture.
    • Refactored into a distributed architecture.
    • Architecture stability and state of completeness: low.
    • Demo to end-users on its functioning. Feedback from them on UI and functionality.
  • 24. Second Sprint: Plan
    • Goal: Establish an application framework through refactoring of the existing story and implementation of two more stories.
    • Stories selected: Users master and Companies master.
    • No time-boxing again. No estimation.
  • 25. Second Story: Companies
  • 26. Framework Evolution
  • 27. Framework Evolution Common behavior in the framework’s classes (such as UIManager), with hook methods for story-specific implementation.
  • 28. Cross-Cutting Requirement: Change History
    • Implemented in one story.
    • Took up a second story to implement.
    • Refactored the first story to move the related code to the application framework.
  • 29. Second Sprint: Execution
    • Refactoring and framework evolution was initially confusing for the inexperienced developer.
    • Took about three weeks to accomplish.
    • Demo to end-users.
    • End-users were curious and excited too. They were seeing early results! They were beginning to see the benefits of iterative development, end-user collaboration.
  • 30. Third Sprint: Plan
    • Goal: Deploy a minimal but genuinely usable product.
    • End-user agreement to start using the system.
    • Two stories selected for implementation:
      • Company-Locations
      • Persons master
    • Estimation attempted for the first time. Value-driven plan. Estimated time: 14 working days.
  • 31. Third Sprint: Execution
    • Using the framework made this iteration’s implementation much easier.
    • Architecture and framework continued to evolve.
    • Actual time: 17 working days.
    • Demo to end-users.
    • Actual deployment for the first time. End-users started using the system.
    • Many suggestions for changes in UI and functionality.
    • Data migration from old system to the new one.
    • Formal retrospective for the first time.
    • Even had a retrospective with the end-users.
    • Fixed sprint duration to three weeks for all subsequent iterations.
  • 32. Incremental Architecture and Design
    • Evolution across iterations, through implementation-refactoring.
    • More architecture work in earlier iterations.
  • 33. Example: Incremental Design and Implementation
    • Complex stories with complex functionality / innovative UI are split, designed and implemented across Sprints. Example: Trainers’ tracking chart.
  • 34. Architecture and Design Evolution
  • 35. Architecture and Design Evolution
    • Static grid with hard-coded data. Simple navigation keys.
    • Dynamic grid, data retrieval from database.
    • Cache table. Auto-refresh. Comments in cells. Navigation across months.
    • Cut, Copy, Paste, Excel export options.
    • Options to add / edit work orders from the grid.
    • Tracking of incremental changes.
  • 36. Was Everything Perfect?
    • Made wrong decisions occasionally.
    • Produced waste also. Example: maker-checker cycle.
    • Lesson learned: Avoid architecture / design decisions that stakeholders don’t expressly see value in.
  • 37. Points to Ponder
    • Is UML evil?
    • Is documenting architecture evil?
    • Have a separate architect role?
  • 38. Summary of Principles Followed
    • Envision architecture requirements early.
    • Evolve architecture through implementation of real stories. Reduces technical risks.
    • Deliver value to the customer early, while also validating the architecture and design.
    • Just-in-time design.
    • Use before reuse.
    • Simple models are often the best models.
    • Apply design patterns / architecture patterns gently.
    • Prefer architecture that is well-understood rather than well-documented. Keep your models publicly visible.
  • 39. Thank You