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

2. THE WHO Dominic Furano Alysha Kester Kaeden Kulow Sai Kiran Reka
Kaeden Kudlow
Alysha Kester
Sai Reka
All interns under Jason Jones for Clinical Open System Development; Open Systems Engineering
Dominic Furano
Alysha Kester
Kaeden Kulow
Sai Kiran Reka
Developer Debt Utility & Gamification Research
Data Forensics & Integrity, DB Admin & UI
Research, API & JavaScript Services
Data Extraction, SPRING Services & Unit Testing

3. THE WHY
Intermountain Healthcare’s 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.
Intermountain Healthcare’s efficiency and integrity of care can be, in part, attributed to the wealth of distinct and pertinent applications developed for its clinicians, patients, insurance carriers, researchers, managers, engineers and many more important employees.
Although there are many tools to track development progress and updates, ensure backup, deployment, save documentation and support help desk procedures, there is no trustworthy one-stop source of all pertinent application information. This type of reference is important to the continued efficiency of application sustainability, performance, development and future application standards and development.
Performance and sustainability of an application is directly related to costs.
Through a collaboration of resources, references, data collection and categorization, we inspired the HOW in providing a comprehensive catalog of intermountain health application information for developers, managers, front line support and users.
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.

4. THE WHY
Intermountain Healthcare possesses impactful internally developed applications, but
Misses a comprehensive archive for developers & application information – we don’t 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
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
Don’t even know how many apps we have
Many app types
Comprehensive way to see all applications and classify by usage to focus on pertinent apps
Expected lifecycles/ focus on reducing debt in critical apps
Look at overview of Tech Debt in confluence

5. Catalog & Categorize Applications
THE HOW
Catalog & Categorize Applications
Researched and identified existing resources & interviewed developers
Data Discovery
Identify Tools & Methods to Manage Data
Identified tools to extract & store data such as APIs, plug-ins, Database options
Tools & Research
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
Updating & Maintaining projects’ data with developers and business owners
Data Audit & Maintenance
2025
2030
2035
Starting with a of Data-Business Logic-Presentation, we identified pertinent data requirements and resources.
Data Resources were in most cases plentiful, but varied and spread out across the organization- from Confluence wiki pages to interview-intensive 1st-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 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 and varied resources for each project. We’ve documented as much source information as possible on each project’s 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:
DASA (Dominic’s Awesome Scripting Application)
Influx DB
Java
SPRING framework
Bamboo for continuous integration
Sonar for technical debt analysis
Presentation included collaboration with the UX team for visual mockups which we then created the custom CSS to match. Usability and user priority drove the layout of the Project Details page which houses the most information on the dashboard. Data audits and formatting were particularly important in the presentation piece of the dashboard.
Tools used were:
Javascript
CSS
Bootstrap Components
HTML
Angular.js

6. THE HOW
Data Resources were in most cases plentiful, but varied and spread out across the organization- from Confluence wiki pages to interview-intensive 1st-person knowledge. We identified several pertinent sources of already documented and available information, including:
Data Resources were in most cases plentiful, but varied and spread out across the organization- from Confluence wiki pages to interview-intensive 1st-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
Canceled and Unknown Info apps =65 apps
Confluence
JIRA
Sonar
Subversion & Git
Bamboo
Jenkins
WADI
WASP
HelpDesk
Oracle DB

7. THE HOW
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.
We’ve documented as much source information as possible on each project’s 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:
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 and varied resources for each project. We’ve documented as much source information as possible on each project’s 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:
DASA (Dominic’s Awesome Scripting Application)
Influx DB
Java
SPRING framework
Bamboo for continuous integration
Sonar for technical debt analysis
Influx DB was developed and functional, however, Influx DB’s stability could not match the needs for the overall Intermountain Healthcare organization
Developer Technical Debt Utility
Influx DB
Java
SPRING framework
Bamboo for continuous integration
Sonar for technical debt analysis

8. 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:
Presentation included collaboration with the UX team for visual mockups which we then created the custom CSS to match. Usability and user priority drove the layout of the Project Details page which houses the most information on the dashboard. Data audits and formatting were particularly important in the presentation piece of the dashboard.
Tools used were:
Javascript
CSS
Bootstrap Components
HTML
Angular.js
Java
JavaScript
CSS
Bootstrap Components
HTML
Angular.js
Launchpad

9. THE WHAT The Supportability Dashboard:
Intermountain Healthcare’s Comprehensive Internally Developed Application Library & Technical Debt Reduction Stimulus
Internally developed apps*
Through collaboration of resources, references, data collection and categorization:
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.

10. THE SCOPE 438 Total Applications Identified
Stats surrounding all the data gathering process and outcomes
Of 326 Applications Identified:
13 were out of scope (EDGE, APEX, KR etc.)
23 were identified as HWCIR
50 were identified as MyHealth
65 were identified as Canceled
175 are applicable to the scope
This leaves 151 currently identified applications to be categorized and handled appropriately going forward
Technical perspective
Lines Of Code 5,946 
Technical Debt 4d
Java Files/Classes 117 
Directories 32 
Functions 392 
Unit Tests 39
438 Total Applications Identified
326 Internally Developed Applications Identified
175 Within Scope & displayed on the Supportability Dashboard

11. THE SCOPE Lines Of Code 5,946 Of 326 Applications Identified:
Stats surrounding all the data gathering process and outcomes
Of 326 Applications Identified:
13 were out of scope (EDGE, APEX, KR etc.)
23 were identified as HWCIR
50 were identified as MyHealth
65 were identified as Canceled
175 are applicable to the scope
This leaves 151 currently identified applications to be categorized and handled appropriately going forward
Technical perspective
Lines Of Code 5,946 
Technical Debt 4d
Java Files/Classes 117 
Directories 32 
Functions 392 
Unit Tests 39
Lines Of Code 5,946
Technical Debt 4d
Java Files/Classes 117
Functions 392
Unit Tests 39

12. THE BLUEPRINT Client Services Oracle Developer Debt Utility
In the Future:
Event services for usage – Tactical Apps to services
TBM Common Repo <->

13. THE FEATURES

14. THE FEATURES
If presenting live, slides will be a live demo instead of slides shown.

15. THE MAIN BOARD Listing 175 currently included deployable projects.
The Main page includes a listing of all 175 currently included deployables. This page gives a quick, 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.

16. 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
THE DETAILS PAGE
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.
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
Compliance Scoring is based on how many pertinent resources an application has currently cataloged and used. Pertinent resources include the 6 following assets:
A Confluence Page Link with proper "projects" labeled template
A WASP Listing
A JIRA project URL
A Build Server URL (preferably Bamboo)
A Source code repo URL  (preferably Subversion trunk) 
A Sonar account
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
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
The Details page for each project contains the most cataloged and categorized information on a project deployable.
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
Usage Statistics are currently static numbers stored and extracted from the Oracle DB. The figures here are currently determined or estimated by the application owner in order for us to classify applications. We are working to dynamically capture future figures through a variety of other methods and sources such as Event services, weblogs, etc.
Concurrent Sessions is how many people at one time are using the application; most figures here came from WebHobbit or event services
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
Source Links are pertinent resources cataloged for the application and include a link to the resource source.
Compliance Scoring is based on how many pertinent resources an application has currently cataloged and used. Pertinent resources include the 6 following assets:
A Confluence Page Link with proper "projects" labeled template (see the template FAQ here: How to Build a Project Page & Project Page Template)
A WASP Listing
A JIRA project URL
A Build Server URL (preferably Bamboo)
A Source code repo URL  (preferably Subversion trunk) 
A Sonar account
The info icon displays a message and links to the Compliance Scoring Confluence page
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
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.
Other Information includes the front line support group the application belongs to, the Key used in sonar for the application and the database deployable ID for the project.
WADI Information is extracted from WADI and includes
Application ID (if deployed on WADI)
Last Deploy Date
Last person to deploy
Source Links are pertinent resources cataloged for the application and include a link to the resource source.
Maturity Matrix Score is extracted from the confluence page if the project has completed a Maturity Matrix

17. THE LEADERBOARD
User & Week are the default filters. You can also choose to see debt by Project and other various timeframes.

18. THE FUTURE
Extensible Framework Quick and easy integration; ability to extend to MyHealth or other application organization cataloging and analysis
Dependency Analysis
Future dependency analysis tool to dynamically construct dependency tree able to alert message when there’s an issue
Extensible framework with quick and easy integration; ability to extend to MyHealth application organization cataloging and analysis.
Future dependency analysis tool to dynamically construct dependency tree able to alert message when there’s an issue.
Automatically updated usage statistics for all applications by event services & log monitoring.
Deployable Confluence project page ownership & maintenance handled by Business Owners & Developer teams.
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
Expand Gamification
Develop Leaderboard to expand gamification in reducing technical debt to include earning achievements

19. Q&A
Basic Questions and basic answers we’ve gotten before