18
Supportability Dashboard with Technical Debt Reduction Gamification Intermountain Healthcare’s Source for Internal Application Development Data Integrity and Technical Debt Reduction Gamification Tool

Supportability Dashboard with Technical Debt Reduction Gamification Intermountain Healthcare’s Source for Internal Application Development Data Integrity

Embed Size (px)

Citation preview

  • Slide 1
  • Slide 2
  • Supportability Dashboard with Technical Debt Reduction Gamification Intermountain Healthcares Source for Internal Application Development Data Integrity and Technical Debt Reduction Gamification Tool
  • Slide 3
  • Developer Debt Utility & Gamification Research Dominic Furano Research, API & JavaScript Services Kaeden Kulow Data Forensics & Integrity, DB Admin & UI Alysha Kester Data Extraction, SPRING Services & Unit Testing Sai Kiran Reka THE WHO
  • Slide 4
  • THE WHY Intermountain Healthcares efficiency with integrity of care can be, in part, attributed to the wealth of its distinct & pertinent applications. Critical analysis of our development products is necessary to understand where our weaknesses and strengths reside. The performance and sustainability of our applications are directly related to cost. We must lift the road blocks standing in the way of excellent, cost and code efficient, critically analyzed development and its support.
  • Slide 5
  • THE WHY Complex ownership & structures lack standardized documentation & information resources The front line support to developer pipeline is obstructed by unavailable ownership Developers want direction & motivation to reduce technical debt & free up resources Intermountain Healthcare possesses impactful internally developed applications, but Misses a comprehensive archive for developers & application information we dont even know how many applications we own Abandoned or Canceled yet still deployed applications consume valuable resources Orphaned/lost ownership applications lack documentation or knowledge repositories for how/when/if they are still used
  • Slide 6
  • THE HOW Identify Tools & Methods to Manage Data Identified tools to extract & store data such as APIs, plug-ins, Database options Tools & Research 2025 20302035 Code Services & Develop a UX/UI for Users Identify a user interface to display and categorize information in an easily usable way Services & UI Development Review & Stabilize the Environments, Data & Services Considerations, changes and implementations developed to provide stable usability across the entire Intermountain Healthcare organization Stability & Refinement Catalog & Categorize Applications Researched and identified existing resources & interviewed developers Data Discovery Updating & Maintaining projects data with developers and business owners Data Audit & Maintenance
  • Slide 7
  • Data Resources were in most cases plentiful, but varied and spread out across the organization- from Confluence wiki pages to interview-intensive 1 st -person knowledge. We identified several pertinent sources of already documented and available information, including: Confluence JIRA Sonar Subversion & Git Bamboo Jenkins WADI WASP HelpDesk Oracle DB THE HOW
  • Slide 8
  • The business logic of the Supportability Dashboard relies heavily on the data resource types available for each application, so it was very important to identify and document available resources for each project. Weve documented as much source information as possible on each projects Confluence page, where the information is then extracted into a relational database or displayed outright on the project details page of the dashboard. Business Logic includes tools such as: Developer Technical Debt Utility Influx DB Java SPRING framework Bamboo for continuous integration Sonar for technical debt analysis
  • Slide 9
  • THE HOW Usability drove the layout of the Project Details page which houses the most information on the dashboard. Presentation included collaboration with the UX team for visual mockups which we then created the custom CSS to match. Data audits and formatting were particularly important in the presentation piece of the dashboard. Tools used were: Java JavaScript CSS Bootstrap Components HTML Angular.js Launchpad
  • Slide 10
  • THE WHAT The Supportability Dashboard: Intermountain Healthcares Comprehensive Internally Developed Application Library & Technical Debt Reduction Stimulus Preserve comprehensive cataloging of Intermountain Health application information for developers, managers, front line support and users. View usage, resources, references and ownership of applications. Analyze the stability, quality, complexity and efficiency of an application. Through collaboration of resources, references, data collection and categorization:
  • Slide 11
  • THE SCOPE 438 Total Applications Identified 326 Internally Developed Applications Identified 175 Within Scope & displayed on the Supportability Dashboard
  • Slide 12
  • THE SCOPE Lines Of Code 5,946 Technical Debt 4d Java Files/Classes 117 Functions 392 Unit Tests 39
  • Slide 13
  • THE BLUEPRINT
  • Slide 14
  • THE FEATURES
  • Slide 15
  • Slide 16
  • THE MAIN BOARD Listing 175 currently included deployable projects. At-a-glance view of a deployable name, deployable file name, classification based on usage, maturity matrix score, SQALE rating from Sonar, Technical debt calculation and technical owner group. Each column is sortable and there is a search functionality. Listing 175 currently included deployable projects. At-a-glance view of a deployable name, deployable file name, classification based on usage, maturity matrix score, SQALE rating from Sonar, Technical debt calculation and technical owner group. Each column is sortable and there is a search functionality.
  • Slide 17
  • THE DETAILS PAGE Classification is based on how high the usage is for a deployable and is used to determine how important an application may be in prioritization: High: 1000+ users/requests Medium: 500+ users/requests Low: under 500 users/requests Bamboo Build Information is extracted from Bamboo for each project and includes Current state : Successful or Failed build Latest build number: the last version or build completed Last build date: last date and time the build completed WADI Information is extracted from WADI and includes Application ID (if deployed on WADI) Last Deploy Date Last person to deploy Maturity Matrix Score is extracted from the confluence page if the project has completed a Maturity Matrix Figures here are currently determined or estimated by the application owner in order for us to classify applications.. Concurrent Sessions is how many people at one time are using the application Logins is how many people logged in to the system over the past 30 days Unique Users is how many individuals used the application in the last 30 days Service Requests is how many POSTS/GETS there were in the last 30 days for the application Compliance Scoring is based on how many pertinent resources an application has currently cataloged and used. Pertinent resources include the 6 following assets: 1.A Confluence Page Link with proper "projects" labeled template 2.A WASP Listing 3.A JIRA project URL 4.A Build Server URL (preferably Bamboo) 5.A Source code repo URL (preferably Subversion trunk) 6.A Sonar account Source Links are pertinent resources cataloged for the application and include a link to the resource source. Sonar Information displays iframe content from Sonar including a historic technical debt, complexity and unit test line graph and the technical debt pyramid. If an application does not have a sonar analysis, a message with more information will display in this area. Incomplete Metadata Items displays missing information for the application. There are 18 metadata items cataloged for all applications which are automatically audited for null information: Confluence Sourced alternate names, Classification, maturity matrix score WADI Sourced application id, last deployed date, last deployed person, last deployed version, business owner Bamboo Sourced build completed date, build number, build started date, build state Sonar Sourced sqale rating, technical debt Not dynamically sourced concurrent_45, logins_30, requests_30, unique_30
  • Slide 18
  • THE LEADERBOARD User & Week are the default filters. You can also choose to see debt by Project and other various timeframes.
  • Slide 19
  • THE FUTURE Extensible Framework Quick and easy integration; ability to extend to MyHealth or other application organization cataloging and analysis Expand Gamification Develop Leaderboard to expand gamification in reducing technical debt to include earning achievements Automatic Usage Statistics Automatically updated usage statistics for all applications by event services & log monitoring Dependency Analysis Future dependency analysis tool to dynamically construct dependency tree able to alert message when theres an issue
  • Slide 20
  • Q&AQ&A