Evolutionary Architecture And Design

  • 2,517 views
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

Views

Total Views
2,517
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
65
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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