Evolutionary Architecture And Design

3,167 views
2,972 views

Published on

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

Published in: Technology, News & Politics
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,167
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
75
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Evolutionary Architecture And Design

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

×