Download to read offline
More Related Content
Nimble framework
- 1. 1 Nimble Framework Software architecture& design in agile era http://agileanswer.blogspot.com Tushar Jain CSP, CSM, CSPO, Six Sigma & Lean Black Belt Oct 22, 2015 – Agile Strategic Solutions meetup
- 2.
- 3. 3 Architecture & DesignActivities Contd… 3
- 4. 4 Previous illustration showsvery clear boxes but • Activities are diffused in terms of actions and temporal distance. • Activities provide feedback to each other. The more nuanced illustration might looks like happenings in an exotic liquid river where most of the liquid is flowing in one direction but it has few spirals which keep on sending feedback to previous spirals. To add the complexity this river is flowing on the system context. And since it is a river, it has not very defined banks. Sometime this river is deep and narrow while other time it is shallow and wide. To add one more level of realism, various spirals are not very distinct and keep on changing with change in system context. Since spirals are not very distinct, there is also feed forward. Architecture & Design Activities 4
- 5. 5 • Architecture &design process is diffuses and interacting • Dynamic business and technical environment • New leanings Truth 5
- 6. 6 Visualize architecture consistsof three layers of thoughts: • Process • Technique • Pattern Nimble Framework 6 Contd…
- 7. 7 Visualize architecture consistsof three layers of thoughts: • Process: At this thought layer architects decide which architectural process should be chosen. This choice is driven by • Enterprise policies, • Size of project, • Complexity of business domain, … Few of the Architectural processes: • Zachman, TOGAF, Risk Driven, Emergent, … Lot of people may call these as frameworks or any other name but I chose to call them as processes. • Technique • Pattern Nimble Framework 7 Contd…
- 8. 8 Visualize architecture consistsof three layers of thoughts: • Process • Technique: This is second layer of architectural thought. This layer demands that big technology decisions should be taken like • RDBMS vs NO SQL, • Which AppServer, • Which libraries (Log4j vs Java logging), • Which architectural pattern (IoC, MVC, etc.), • Definition of walking skeleton, • Definition of prototype, etc. How much architecture is sufficient ? Majority of decision makers are from Dev Teams but guidance of out of team architects is available to enforce consistency across teams, enterprise policies, and get benefit of T & I shaped skill sets. • Pattern Nimble Framework 8 Contd…
- 9. 9 Visualize architecture consistsof three layers of thoughts: • Process • Technique • Pattern: In this layer core working frameworks are chosen, so Dev Team can write the code in accordance. Decision like • SEDAhttp://www.eecs.harvard.edu/~mdw/proj/seda) or • MicroService or • SOA or • Event based or some thing else are made. Once this decision is made, next level of frameworks is chosen (if required) like Spring Data or Hibernate. Nimble Framework 9 Contd…
- 10. 10 Design phase • Prototypingand selection of design patterns • Making choices within architectural container (use annotation or properties file) Nimble Framework 10
- 11. 11 Thank You Tushar Jain CSP,CSM, CSPO, Six Sigma & Lean Black Belt http://agileanswer.blogspot.comOct 22, 2015 – Agile Strategic Solutions meetup
Editor's Notes
- #4 Architectural Analysis Architectural analysis activity is one of the first activities in hashing out the architecture of to be product. In this activity functionality of the product, its non-functional requirements, and technology concerns are taken as input and architectural significant requirements are produced. Effectiveness of this activity is affected by organization’s policies (e.g. we are Java shop), skill of architects, time in hand, clarity in product vision, details of functional and non-functional requirements. Architectural Coalescence Architectural Coalescence is the activity where various options of architecture are hashed out. This activity accepts input from analysis activity. This step requires creation on various models which can fit into system context and propose and/or create engineering practices. Architectural Evaluation Architectural evaluation activity evaluates various models and engineering practices which are output of architectural coalescence activity. Prototypes are created and evaluated for current & expected functional & non-functional requirements, technical concerns, and organizational policies. The output of this activity is validated architectural options. Design Analysis, Coalescence, and Evaluation Design analysis, coalescence, and evaluation involves creating sample designs, evaluating and choosing. Although this activity is clearly consists of set of activities but due to locality of design, they are clubbed together. This activity follows the path of creating prototypes and then testing under architectural boundaries, functional & non-functional requirements. This step is highly influenced by design patterns. Coding and QA This is ever going activity. Here working product is created. This activity accepts input from design activity and also provide feedback to same on continuous basis. This feedback results in refined or alternate design patterns. Usage Now users use the product. Usage provides active feedback by uses and passive feedback via monitoring. Observations from this activity is fed into loop for better understand of evolving system context.
- #11 While making decisions about Architectural Techniques and Patterns, one should consider changeability of framework in light of – cost of having changeability vs probability of change. The decisions about architectural process generally taken in sync with elaboration of product vision while architectural technique decisions get affected by how scrum teams are structured and also affect how scrum teams will be structured. The architectural pattern decisions are mostly driven by features, abilities (NFRs) and complexity of business domain. It does not mean these are the only factors but dominant factors. Architectural techniques and pattern decisions both are also influenced by communication pattern with in and across scrum teams, NFRs, business domain complexity, product features, layout of product backlog w.r.t. story mapping technique, etc.