Evolutionary Architecture And Design

Pragati Software Pvt. Ltd., 312, Lok Center, Marol-Maroshi Road, Marol, Andheri (East), Mumbai 400 059. www.pragatisoftware.com 1

Evolutionary Architecture and Design

Pradyumn SharmaPragati Software Pvt. Ltd.

[email protected]


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.


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.


About Pragati Software

Bangalore Chennai

Hyderabad

Mumbai

Pune

Ahmedabad

Vadodara

New Delhi

Shimla

Bhopal Kolkata

Thiruvananthapuram


Our Story…

• Home-grown, ERP application.• CIS = Corporate Information System.• Key modules:

CRM and sales: ClientsLocationsPersons InquiriesProposals Visitsetc

Training operations: Work ordersTraining planningTraining executionFeedback analysisetc

Financial accounting:

Billing CollectionsPaymentsTDSMIS reportsetc.


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.


Disclaimer

• No single right way of doing things.

• Each project is different, following agile practices based on heresay / a book is not being agile.


Architecture

• What is architecture?• Do we need an architecture for a system?• When? How?


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.


The Other Extreme…

• No architecture?• Just start coding and refactor?


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.


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).


Cross-Cutting Requirement: Change History




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


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.


First Sprint: Execution

• Acceptance tests• UI design, approval from

end-users.• Started with a typical form-

centric implementation, no architecture.


Form-Centric Design

Form_load: fetch data from Cities table populate the gridNew_click: display blank entry form //…on return from the entry form re-populate the grid from Cities tableetc.

OK_click: validate data INSERT into Cities values … exit formetc.



• Acceptance tests• Started with a typical form-centric implementation, no

architecture. • Refactored into a layered architecture.


Layered Architecture

CityUIManager

CityBrowseForm

CityEntryForm

CityController

City

CityDataStore

DDAATTAABBAASSEE




architecture. • Refactored into a layered architecture.• Refactored into a distributed architecture.


Distributed Architecture

CityUIManager

CityBrowseForm

CityEntryForm

CityController

City

CityDataStore

DDAATTAABBAASSEE




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.


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.


Second Story: Companies


Framework Evolution

CityUIManager CityController City

UIManager

CompanyUIManager

Controller

CompanyController

Entity

Company


Framework Evolution

CityUIManager

UIManager

CompanyUIManager

Common behavior in the framework’s classes (such as UIManager), with hook methods for story-specific implementation.



• Implemented in one story.• Took up a second story to implement.• Refactored the first story to move the related code to the

application framework.


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.


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.


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.


Incremental Architecture and Design

• Evolution across iterations, through implementation-refactoring.

• More architecture work in earlier iterations.


Example: Incremental Design and Implementation

• Complex stories with complex functionality / innovative UI are split, designed and implemented across Sprints. Example: Trainers’ tracking chart.


Architecture and Design Evolution


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.


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.


Points to Ponder

• Is UML evil?• Is documenting architecture evil?• Have a separate architect role?


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.


Thank You

Evolutionary Architecture And Design

Technology

appropriate architecture

evolutionary architecture

architecture stability

detailed architecture

layered architecture

distributed architecture

formcentric design form

application framework