Stage 12
Application Audit

Like any living organism, apps will take on a life of their own. They will evolve and change over time. While an app may have perfectly fit all business and organizational needs initially, as the business process changes (and you continue to release daily updates), it should be reassessed periodically to understand whether it is still delivering on the expected outcomes. Therefore, it’s essential to establish an effective approach and cadence for measuring the impact and evolution of your no-code app, as well as provide support and management as needed to optimize its health and fitness over time. We’ll refer to this as the Application Audit stage.

Initially, the Application Audit is likely performed by the no-code team and is reported to the no-code stakeholder. However, as the number of no-code apps increases and as you develop more business-critical apps, the audit function generally will become part of the responsibilities of the Center of Excellence. This will help look across the organization to measure and improve overall levels of efficiency, effectiveness, and business impact. It will also help identify reusability opportunities (a key concept we’ll address shortly). However, regardless of who performs the audit, it’s important not to miss any key steps. So, we will briefly introduce some of the key activities that should be included and some considerations for each.

We probably have seen “bloat” happen in our personal health — maybe you eat too many unhealthy snacks, perhaps some unnecessary desserts, and you start putting on some unplanned (and unwanted) weight! This happens with apps as well — over time, it’s not unusual for applications to experience “feature bloat” as more requirements are slowly added to the application. The impact may not be that unwieldy at first, but after a while, the aggregate impact of adding requests may result in additional (and perhaps unnecessary) complexity.

Complexity due to aggregate features can manifest itself in the app in several ways:

• First, it can increase the perceived complexity of the existing UX. The app might have been very simple and intuitive at MVP, but now forms or workflows have evolved and expanded and may have many more fields or steps than needed. Reviewing the UX and evaluating parts of the user journey that may need optimizing or refactoring for simplicity are important.

• Adding new features may also begin to impact the responsiveness of the app. It’s important to continue closely monitoring performance metrics around the application (e.g., launch times, display times, and moving between pages) and identify areas that may require specialized performance tuning and optimization.

• It may not always be the visible feature complexity that starts to slow an app — it may also be a result of the additional user or data growth that happens over time. These volumes may put unplanned stress on the database or application services. It could be necessary to archive older data or take on more technical optimization at a database level to ensure that performance stays “fit” as your volumes grow.

Your team that manages operations should usually be able to help with the system performance tracking by providing health metrics on performance or downtime as part of their standard reporting. Tracking over time should help identify if there are possible concerns to address. Usability performance problems are sometimes harder to spot. Some of the techniques discussed in the Feedback Collection stage (e.g., user shadowing and UX questionnaire) can be good early warning signs that you may need to refresh or streamline the end-user experience.

Another important consideration is feature obsolescence. Over time, some features in the app may no longer be applicable (given changes in the process or requirements) and may need to be removed or refactored. It’s easy to forget to continue to review the app periodically for these types of outdated features, and it’s also easy to let things go unused for periods. However, the cleanup of unused or unneeded features will help keep the app “fresh” and usable for the user.

The audit team needs to analyze all the redundant features (clutter) that have become irrelevant. The ongoing feature cleansing process should be applied. This is important to reduce the “noise” for end users and keep the user experience efficient and productive.

Obsolescence will ultimately also happen to the no-code app itself. It’s also OK for apps to run their natural course. Eventually, any application will reach “End of Life” (EOL). At this stage, it’s important to retire or decommission the app, which is a natural part of the lifecycle and makes the path clear for new apps and workflows.

The review and decommissioning of obsolescent apps may sometimes be sporadic if left to the no-code team, especially if the original no-code team has moved on to other projects or parts of the company over time. For this reason, the evolution of your apps across the portfolio is often managed/enforced by the CoE. They should be responsible (when existing) for systemic review of the application portfolio to maintain health and relevancy.

Another key type of change that should be anticipated is linked to the environmental factors surrounding the app itself. The business may have changed, the process may have changed, or both, so it’s important for the no-code app features to be reviewed for needed updates or, potentially, for feature removal. While not always easy to spot, the no-code team (or CoE) will need to monitor to see if no-code app changes may be required.

There may be changes in operational processes that are touching automation. The design of the no-code app has made assumptions about what operational workflow occurs. Therefore, as process change occurs, it may fundamentally change the organization of the workflow and UX within the app as well. It may be necessary to make changes to align better with the new operational processes and procedures.

Changes in organizational structures may also have unintended impacts on the no-code app. Changes to reporting or organization boundaries may trigger user workflow or navigation updates. Splitting teams into another organization may require updates to user access permissions. So, while app changes are often not considered when an organizational change is made, they must ultimately be synchronized so that the app supports the team(s) and employees who will be using it.

It’s recommended to review the scheduled proactive audits of the process/organization and not simply rely on reacting to changes as they occur. Depending upon the business complexity (as guided by the Application Matrix), you should schedule more or less frequent reviews to ensure that the app stays aligned with the process and organization. It is advised to schedule most Simple apps for annual reviews, and Medium/Complex apps should likely be checked quarterly depending on the pace of changes they may be facing.

In Chapter 14 (Governance Checks) we discussed identifying and proactively scheduling the appropriate governance reviews as a part of the lifecycle or as part of an annual cadence. However, while this has been planned upfront (in concert with IT or Data Governance teams), don’t overlook the possibility of changes in external or internal requirements that may trigger you to reassess the type and frequency of checks. For example, there may be changes in federal regulations enacted that make it mandatory to comply with a new set of rules. Or perhaps your internal Data Governance organization adds a new data privacy policy that may require limiting access to data types. Regardless of whether this is externally or internally triggered, the no-code development team will need to review the app for possible new checklist reviews.

As with the process/organization changes, it’s advised to collaborate with the Governance or IT teams and have a proactive schedule for routinely assessing which internal or external governance requirements may have changed. Governance checks may need to be done more often considering regulations and legislative requirements changes. The necessary frequency may vary widely depending upon your industry or business environment, as will the cost or impact of accidentally missing new governance requirements. So, you’ll need to determine the right cadence for assessing major new external or internal governance updates. Generally, it’s advised to set the appropriate audit cycles for governance based on the different complexity/criticality levels as per the Application Matrix.

As discussed earlier during the Design Phase, one of the strategic benefits of using no-code platforms is embracing the composable architecture. As no-code apps are built, there will likely be various components developed in each app that fill another need and can be suitable for reuse. So, during the Application Audit stage, you should formalize a process that identifies functional or technical components that might have broader benefits and impact on the organization if reused.

As discussed earlier during the Design Phase, one of the strategic benefits of using no-code platforms is embracing the composable architecture. As no-code apps are built, there will likely be various components developed in each app that fill another need and can be suitable for reuse. So, during the Application Audit stage, you should formalize a process that identifies functional or technical components that might have broader benefits and impact on the organization if reused.

• The CoE should take a leadership role across teams to establish a standard process for assessing the applicability of reuse for functional and technical features.

• The CoE will help promote broader visibility/discovery of available components through establishing an internal catalog or marketplace-type function.

• To effectively identify, curate, and operationalize the component reuse, it may be required to introduce new roles/responsibilities (typically within the CoE) and training around component design, curation, and reuse. The CoE should help with the enablement of teams to assist with the initial use of shared or reusable components.

• The CoE may provide individual application teams additional assistance to harvest/repackage for broader reuse. This can help address concerns that individual teams may not have the staff/budget/skills to invest in the additional effort needed to create a reusable or generic version of a component.

• The CoE should establish standard reporting and metrics to track reuse effectiveness. It’s important to avoid a “Field of Dreams” approach (i.e., “if you build it, they will reuse … ”) — don’t assume it will happen but adopt a data-driven approach to measuring the impact of component sharing and the success of demand generation/reuse activities. This will help target areas where you need to provide additional direct assistance or enablement of no-code teams.