Whose View is it Anyway: Addressing Multiple Stakeholder Concerns
- 1. Whose view is it anyway? Addressing Multiple Stakeholder Concerns Feroz Sheikh, Nagaraju Pappu
- 2. • High Performance, Transaction Systems • If you have throughput needs of millions of transactions per hour, we are the people to talk to :) • Content Management, Semantic Computing & Cultural Informatics • agropedia.net • EduNxt a large scale virtual learning environment which won Golden Peacock Award for best innovation. • Platform Oriented Architectures, SaaS and Cloud Computing Solutions 2
- 3. An Analogy It takes a lot more to produce the winner than the driver (end user) or the Car (software system) alone. There are many stakeholders and they all have to do their job efficiently. 3
- 4. People behind the success People who People who People who People who Run the Manage the Build the Use the System Business System System Usability Configurability Fault Tolerance Modifiability Performance Feature Scalability Manageability Extensibility Reliability Deployability Testability Security 4
- 5. What are the system features? End User Features Behind the Scenes Features These behind the scenes features for other stakeholders is what enables systems to scale Runs 1800 MySQL Does 10 Bn txns per without escalating Servers with 3 DBAs quarter with a total operational costs engineering staff of 200 5
- 6. Architecture Concerns & Agility “Abilities” are Concern of Quality Attributes Architecture + Converting Architecture Concerns into User Stories Building Highly Scalable, Large Systems Agile Discipline Realizing User Stories 6
- 7. Challenges and takeouts People Who Use People Who Run People Who People Who Build the System the Business Manage the System the System Usability Configurability Fault Tolerance Modifiability Performance Manageability Extensibility Feature Scalability Reliability Testability Security Deployability Challenges Takeouts • These concerns are vague • Converting their concerns into stories • Difficult to test and prove • Converting other stakeholders into active users • Get neglected in prioritization • Left to the developers’ skill and • Individual story boards for all the 4 buckets of stakeholders Guesswork • Concerns are addressed consciously 7
- 8. Case Study - Banking App • Client - India’s largest non-banking finance company, focusing on Gold Loans • Context - Building a centralized core banking system to manage their network of 10000+ branches all over India • Business Scenario • End customers pledge their gold in return for cash loans • Payback the loan over time and take back the gold • Loan offered is against the market value of gold items • Company offers various loan schemes to attract customers 8
- 9. What are the concerns? How easily can we add new Loan Will the new CBS schemes? help increase our bottom line? Performance? What would it take Response time < 2 to manage CBS in sec for new loan remote data center? Privacy? Throughput? How easily can we Busy branches - 100 adapt to fluctuating requests/sec Gold Rates? 9
- 10. Categorizing the concerns Type 1 - Constraints on the system Verifiable and Measurable Performance? Response time < 2 sec for new loan The techniques, design patterns etc needed to deal with these concerns is well understood Throughput? Busy branches - 100 requests/sec 10
- 11. Categorizing the concerns Will the new CBS Type 2 - Effect of the system on help increase our bottom line? the organization, environment & society It is very difficult to measure the impact of the Privacy? system on the organization and environment. Hence this category of concerns is not something we will talk about. 11
- 12. Categorizing the concerns How easily can we add new Loan Type 3 - Productivity of the schemes? stakeholders Relate to quality attributes What would it take to manage CBS in Such as Manageability, Extensibility, remote data center? Modifiability, Testability, Usability This is what this presentation is about - Addressing How easily can we productivity related concerns adapt to fluctuating of stakeholders Gold Rates? 12
- 13. Challenge is... • Such productivity concerns are ambiguous • It means different things to different stakeholders • Difficult to find a start and end • Difficult to measure and quantify • Difficult to test 13
- 14. Lets take an example How easily can we adapt to fluctuating gold rates What are the functions you do? Manage the Gold Rate for all branches by studying the market How frequently do you do it? Market Every few days, and it Product Analyst takes a lot of effort to Owner manually do it for 10000 branches 14
- 15. Lets re-look at the conversation • Organizational Work Market analyst has to setup the Gold Rate for the branches • Productivity Concern Managing it for 10000 branches needs a lot of time/resources • Optimize Effort 15
- 16. The STORY goes on... Manageability => Tools Usability => Bulk UI How can CBS help you? If CBS can automatically aggregate Gold Rate from third-party sources... Market Product Analyst If CBS can provide Bulk Gold Owner Rate management it will save me a lot of effort 16
- 17. The STORY goes on... How easily can we Manageability => Tools adapt to fluctuating Usability => Bulk UI gold rates By Using quality attributes as a guide, the ambiguous concern is converted to concrete stories Market As a market analyst I need Gold As a market analyst I need Gold Rate Groups to manage it in Analyst Rate Aggregation from third- bulk, it will save me X hours of party sources ... effort every week 17
- 18. Sample Stories Actor Feature Value Central Office A screen to send notices and Saves time and effort in sending Manager announcements to nearby branches out the notices by fax Support for running dummy Verify that branch setup is Branch Manager transactions which leave no trace on correct before going live. Saves actual data errors & downtime post go-live Need a screen to manage branch IT/System Saves manual effort every time partitions and allocating a branch to a Support Staff a new branch is created partition Notice how a stakeholder is converted into an active Need statistics on partition usage and IT/System “User” of the system Saves effort in gathering this alert when a partition is reaching its Support Staff data, reduces branch downtime limits They now have a screen/ functionality dedicated to Need a way to simulate operations Reduces time in function testing do their manual Testers happening from different branches for every release 18
- 19. Identifying Features... Some examples of generic features related to quality attributes... Quality Attribute General Productivity Concern General Features Configurability Requires contacting others Config as first-class app screens (End users, product Requires unfamiliar tools Hot reload of the config owners) Requires system downtime Requires development effort Use pluggable design patterns Modifiability Requires a lot of time to make the Automatic code generation (Product sponsors) change and test Ways to simulate, export/import Requires training Provide bulk screens Usability Mundane/repetitive tasks Context sensitive help (End users) Requires effort to do something Guided navigation (e.g. wizards) Takes too long to deploy Auto-update features Deployability Chances of making mistake in Installation wizards (Operational Users) deployment & effort to correct it Data backup and restore 19
- 20. Identifying Features... Quality Attribute General Productivity Concern General Features Requires contacting others Manageability Built in measurements in code Requires effort to collate data (Support staff, Dashboards and reporting Requires continuous CTO/CIO) Push notifications (e.g. alerts) monitoring Logging and built-in diagnostics Maintainability Requires effort to localize bugs Simulation tools to replicate bugs (Developers, Difficult to simulate and test Release automation tools (auto- Testers) Requires effort to push a bug-fix update) Automation of test scenarios Testability Requires effort to simulate Simulation tools (e.g. bulk data load) (Testers, Dev Requires effort to re-run tests Mock components (e.g. payment team) Difficult to isolate components gateways) 20
- 21. The Method of Supportability 1. Identify the stakeholders (across the 3 buckets) 2. Identify stakeholders’ functions that are impacted by the addition of the new system 3. Describe the productivity scenario as a statement of time, resources or money to be optimized 4. Analyze the scenario using quality attributes to identify features required to realize the desired optimization 5. Add the features to the stakeholder’s storyboard 21
- 22. The Essence of Supportability How well does the By building Features SYSTEM support ALL its specifically for them and stakeholders to do their converting them into function more efficiently “Active Users” 22
- 23. Multiple Story Boards - Views A single story board can loose context, especially in large projects. So we create multiple buckets - one for each category of stakeholders. End User Business Operational Development Functionality Stakeholders Stakeholders Stakeholders 20 23
- 24. A look at the view • A view is basically a story map • 2 dimensional layout of the stories against release timeline • Stories are laid out against the Epics/Concerns swim-lanes • Divided into releases - giving us the big picture 24
- 25. Drawing the views • Define the releases • Define release goals & strategy - highest level stakeholder expectations • If it is continuous rollout, plan the strategy over time (e.g. quarterly) 25
- 26. Bring in the stories... Examples shown here are made using a tool called Trello. We use the Trello board as a view, and Lists as releases. Color coded labels are used to identify quality attributes. In the past, we used tools such as Visio or Vue to draw the views. 26
- 27. Bring in the stories... 27
- 28. Prioritize • Build systems that are sound on Common Desirable ALL “abilities” - not just functionality • Addressing these concerns later Other Qualities usually requires additional effort - new development, design refactoring, regression testing • If we postpone it, we are Debugging running with a liability • This is like getting into a debt - Functionality “Technical Debt” 28
- 29. Prioritize • Negotiation guided by the total effort required to build the story • Keep the technical debt in mind while prioritizing • Against the business value (time, resource, cost optimized) 29
- 30. Balance the views • Rearrange the stories based on goals and priorities • Validate the story map with respective stakeholders 30
- 31. Watch out for the ripple effects Gold Rate Feed from Manageability third-party sources like Kitco, MoneyControl Alerts when a daily feed fails Screen and tools to Market Analyst configure and test the third-party interface IT/System Administrator Integrability Integration Kit for web services, RSS feeds Developer 31
- 32. Large Integration Projects • Large integration projects involving third-parties may need additional views • e.g. Interface contracts and integration milestones 32
- 33. The Big Picture - An Example 33
- 34. Basic Principles Do’s • Define the strategic goals and objectives of each release • Identify & articulate the scale of the system • Give adequate attention to all qualities in each release • Discuss with stakeholders and agree to the strategy Don’ts • Don’t worry about accuracy - none of us are Oracles • We can always change it later or adapt to the environment • Don’t worry about the granularity up-front, we can refine it later • Don’t try to get all of it up-front, you can’t 34
- 35. Benefits • Stakeholders are identified and converted into “Users” • Concerns are converted to INVEST’able stories • Their business value can be articulated and triaged • Justify the cost of building a feature to address a concern • Compare and prioritize with other stories • Visually see the evolution of the system • System evolves balanced in all its qualities 35
- 36. appcomu aju Plting. agarconsu N us canop h .cnr@ gp om Sheiksconsultin Feroz canopu @ feroz ption not an o ce * rman perfo www.canopusconsulting.com