/ Stage 12

Application Audit

Key Roles

Responsible: No-code Business Architect

Approve: No-code Stakeholder

Contribute: No-code Creator(s)

Contribute: IT, Security, Data Stewards

Inform: Pro Developers (Fusion Teams)

Introduction

Your no-code app will evolve and change over time. While an app may have perfectly met all of the business and organizational needs initially on Day 1, as the business changes (and you continue to release Everyday Delivery updates), it should be reassessed periodically to understand how well it is still performing. This is critical to ensuring your app continues to drive the optimal levels of productivity, user satisfaction, and ultimately delivering on the expected stakeholder outcomes.

The intent of this stage – Application Audit – is to establish an approach and cadence for measuring the impact and evolution of your No-code app, and provide support and management as needed to optimize it’s health and fitness over time. Performing an Application Audit is a proactive step that can help you identify and address potential issues before they become bigger problems. It can help you ensure the security, compliance, efficiency, and quality of your no-code application, ultimately helping you deliver more value to your users. Refer to the supporting material around both the key Roles and Responsibilities and Application Matrix which will be referenced throughout the guidance.

The outcome of this stage should be identification of an optimized set of possible improvements for your no-code app. These will be evaluated, prioritized and then added into your backlog following the Change Management processes outlined in earlier Stages.

Stage Pre-requisites/Inputs

The current Production release of your no-code app and the feedback collected from stakeholders and feedback channels will form the key inputs into this current effort. Here are a set of key pre-requisites you should make sure are in place before starting this stage.

Application MVP deployed to production.
Feedback collection (user & system) processes in place.
Continuing support from IT/Ops for Governance reviews and updates.
Continuing Change Management and Backlog processes in place.
Continuing Work management processes (e.g. Kanban) in place.

The work in this stage will be mostly focused around a structured review of the no-code application. The No-code architect will have a large role to play in helping enable the activities. If a CoE exists, they will likely also have taken a lead role in establishing the process and tools necessary to enable this Application Audit process.

Audit Checks: DIY Teams

Initially for simple applications, the audit is likely to be performed by the DIY team themselves. The No-code Architect will usually lead this process with the support of the DIY team. The results should be reviewed and approved by the No-code stakeholder to ensure the right level of visibility and oversight. We recommend performing an audit of the application not less than once per quarter.

The following is not a comprehensive list but is representative of the types of checks that the team should review as part of an Application Audit.

Audit check	What and how to check?
Business change	Did actual work content and\or functions of the team change? Were new products or services introduced by the business that require updates to the app? Were there changes to the business process that require more significant rethinking and redesign of the app?
Performance	Are there any performance-related complaints? Do all screens load in a timely manner or require 10+ seconds to wait? What about integration and business processes performance (can be tracked in business process log and integration logs)? Have data volumes increased that may be impacting performance?
Organizational structure changes	Are there any organization changes introduced, such as new roles, new hires, reorganizations, etc? Does the app access rights represent current organizational and functional structure of the team? Were there mergers or acquisitions that may require changes?
Obsolescence	Is there cleanup of unused or unneeded features that will help keep the app ‘fresh’ and usable for the user? What workflows are not used or used rarely? Can they be eliminated to reduce complexity? Are all business use cases and workflows still valid and actual for our business? Has the entire application itself reached end-of-life, and should it be evaluated for replacement / retirement?
Functional / Non-functional Requirements	Do documented functional requirements provided still match with the current app? Do documented non-functional requirements provided still match with the current app?
User feedback and system usage statistics	What are you hearing from users (refer to Stage 9 for Feedback Collection tips)? Have there been any significant changes to the user population? (e.g. increase in users, change in usage times, new locations/geos for users, new languages, etc) What can you state based on history of user sessions and any user-adoption metrics (specific adoption dashboards, process log)?
New No-code platform/Marketplace features	Are there any new features in the No-code platform or product itself that can benefit our use cases? Are there any Marketplace apps or addons that can simplify our work?

Here is an example of a DIY Team Audit findings report:

As you may see from the report, audit findings may result in different actions to be performed:

New requirements to be included in the Incremental Improvements (see Stage 10);
Removal/optimization of existing features to be included in the Incremental Improvements (see Stage 10);
New Governance Check to be included in the checklist (see Stage 7);
New Business Use Case to be processed for more significant scope adds (see Stage 1);
Cancellation of the application (if it becomes obsolete).

Audit Checks: CoE & Fusion Teams

Initially this Application Audit is likely performed by the No-code team themselves 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 or multiple use cases, the audit function generally will become part of a Center of Excellence (CoE) responsibilities. This will help look across the use of No-code across the organization to help measure and improve overall levels of efficiency, effectiveness, and business impact. It will also help identify reusability opportunities (addressed later in this chapter).

The No-code Architect will usually lead this process with the support of the DIY team. The results should be reviewed and approved by the No-code stakeholder to ensure the right level of visibility and oversight. We recommend performing an audit of the application not less than once per quarter.

The checks performed by the CoE will build/include upon the checks from the DIY team, but in addition will start to add more granular checks to enforce proper and consistent design practices across teams. The following is not a comprehensive list, but is representative of the types of checks that the CoE may add as part of an Application Audit.

Audit check	What and how to check?
No-code Process Check	As you begin to see more scale in the number of no-code teams, the no-code CoE should validate that the processes of the no-code lifecycle are being followed consistently and completely. Teams may have gone through initial training on the no-code lifecycle concepts but not yet have full confidence in applying the guidance from this Toolkit. Or they may have applied all of the necessary steps required for a ‘simple complexity’ DIY app (as defined by the Application Matrix), but now be progressing on to more complex no-code application styles. In either case, the Application Audit should identify gaps in their understanding and adoption of the no-code practices and suggest/recommend areas for further development.
Data Model	Data must be stored without duplications (same value stored in 2 or more places is the wrong approach) Data models must represent real-life relations among objects. E.g. one Contact can have multiple phone numbers, one Account can have multiple addresses not only one address Fields with personal or sensitive data must be marked as sensitive data fields If data volume is big and\or volume of data rapidly increases over time - data retention policies must be in place for at least most growing tables (e.g. - archiving, exporting to Data Warehouse, etc.) Database is hosted on a server that is compliant with Data Governance requirements (e.g. EU citizens data has to be stored in EU) Data quality is acceptable for end users. Data quality checks are unique to every use case (e.g. all addresses have to be in same format, postcodes must be from postcodes lookup, not just random numbers, each customer surname must be in place)
UI / UX	UI: All fields are grouped in Tabs and field groups with self-descriptive naming Each section has folder tree and column set up configured to fit end user needs If there are complex UI coded components or business rules – perform code review UX: UX is not too complicated for end users UX of app administration is not too complicated for app admins All sections of the app are designed in a unified way, so users don’t need to learn each section from scratch. Utilizing out of the box features like DCM, next best action panel, notification panel help streamlining UX Modern web-application UX best practices have to be followed (e.g. Google Chrome UX guidelines) Localization Application UI and master data (lookup values, e.g. countries, cities, etc) is localized to all languages end users require
Business Logic	Ensure all business rules are implemented in proper application tier: database or application server or frontend (or combination of those) Ensure business processes run without errors and there are few running business processes simultaneously Ensure everything that can be done with no-code tools is done with no-code (sometimes developers tend to write code instead of using no-code features) If there are custom-coded components or business logic – perform code review to ensure proper structure, security, performance, etc. If business logic is not instantaneous (‘near real-time’) it must run in the background in order not to hinder user experience
Integrations	Review each integration point to ensure it has correctly addressed: Authentication Logging Mapping Performance Integration method (e.g. REST API, integration via message broker or file exchange) Primary system is correctly defined to avoid data discrepancies Availability Error handling and retry policy If there are complex coded integrations – perform code review If integration is not instantaneous (‘near-real-time’) it must run in the background in order not to hinder user experience
Reports	Complex Business Intelligence-level analytics is done in respective BI tools (if this is the case also check all needed data is exported to a Data Warehouse or other data source for these BI tools) Operational level analytics Ensure each user role have reporting they need to plan their day\week\month
External Access (Mobile/Portal)	Mobile App: Ensure only applicable features were added to mobile app (developers didn’t try to recreate all web app features in mobile app) Check that mobile app works properly on devices of actual end users (HW and SW versions have to be same as for majority of end users) Customer\Partner portal: Customers\Partners see only data relevant for them UX is not overly complex for Portal users Sensitive data is not exposed to Portal

Audit Checks: Tips & Best Practices

Usability is an important area to continuously and objectively review. The aggregate impact of adding new CRs may result in additional (and perhaps unnecessary), perceived complexity of the existing UX. The app might have been very simple and intuitive at MVP, but now forms or workflow have evolved and expanded and may have many more fields or steps that need completing. Reviewing the UX and evaluating parts of the user journey that may need optimization or refactoring for simplicity are important. The team can evaluate themselves utilizing industry UX checklists (e.g. Jakob Nielsen’s 10 Usability Heuristics), or leverage experienced internal/external UX resources to provide an independent view.
The addition of new features may also begin to impact responsiveness of the app. It's important to continue closely monitoring performance metrics around the application (e.g. launch times, display times, moving between pages, etc), 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, as it may also be a result of the additional volumes of users or data growth that happens over time. These volumes may put unplanned stress on the database or application services. It may be necessary to look at archiving of older data, or more technical optimization at a database level, to ensure that performance stays ‘fit’ over time as your volumes grow.
In the First Release stage (Stage 8), you established an initial set of environments based upon your app complexity. However, as your application evolves over time, the increased features or technical complexity may also necessitate revisiting the assumptions on environments. This may lead to adding or optimizing environments to support your changed needs.
The no-code platform infrastructure may also require a system-wide performance audit. As you continue to create more and more no-code applications, your infrastructure requirements may evolve and it’s important to identify ‘bottlenecks’ in a proactive way, instead of reacting to raised alarms. This type of audit should be performed collaboratively by IT and the CoE (if one exists).
In case of on-premise deployments, proper hardware has to be sized correctly depending on quantity of simultaneous users, what those users do, quantity of records sent through integration points, overall volume of data in database. (work with your no-code vendor to take advantage of any tools or guidance they have for estimation.) Consider increasing hardware specs if performance issues coincide with peak CPU\RAM load on application and\or Database servers.
Your Operations team should usually be able to help with 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.
Review all internal and external Governance policies (Stage 7), to make sure they are up to date. Consider:
- Have there been changes in regulation or internal policy that need to be reflected in the Governance checks?
- Have you entered or exited from geographies or lines of businesses that may impact the types of applicable governance? Do you need to introduce new checks or discontinue obsolete ones?
- Has your internal Data Governance organization added/updated to the data privacy policy that may require limiting access to data types?
- Has your CISO/Security team added/updated to the security requirements or standards in a way that may require new changes to user access rights?
The audit process can be automated to ensure its completeness and effectiveness. An example of similar automation was discussed in ‘Governance Checks’ (Stage 7), and we suggest following the same approach using capabilities of the No-code platform to automatically audit the app.

Audit Checks: Component Reusability

As discussed earlier, one of the strategic benefits of using No-code platforms is an enabler of a Composable Architecture. As No-code apps are built, there will likely be various components developed in each app that might have some suitability on a broader scale, and is a candidate for reuse. So, during the Application Audit stage you should formalize a process that identifies functional or technical components that might have broader benefit and impact to the organization if reused.

This type of audit can be performed by the No-code team, but as adoption grows across the organization, this will most likely be part of a No-code CoE team. As part of a No-code CoE charter, the following activities are recommended to provide a strategic role in reviewing / curating components:

The CoE should take a leadership role across teams to establish a standard process for assessing 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 component reuse may require introducing new roles/responsibilities (typically within CoE), and training around component design, curation, and reuse. The CoE should help with enablement of teams to assist with 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 performing additional effort needed to create a reusable or generic version of a component.

As you operationalize component reuse, here are some best practices to consider:

Define clear standards and guidelines for component development, naming conventions, and compatibility requirements. This ensures consistency and increases the likelihood of successful reuse across teams.
Encourage individual DIY teams to document their components effectively, including their purpose, functionality, dependencies, and usage examples. Assigning appropriate labels or tags can also aid in the discoverability of reusable components.
Sometimes the components may be reusable ‘as-is’, but the audit can also uncover latent opportunities which require some additional effort to refactor or extract reusable components from existing systems.
The no-code CoE should foster open lines of communication between teams to share knowledge and discuss potential opportunities for component reuse. This can be achieved through regular meetings, documentation, and collaboration tools.
It is important to establish a centralized internal component repository (in addition to the public Marketplace). Set up a repository or library where teams can contribute and discover reusable components. This central location helps teams easily identify existing components and understand their capabilities.
Promote a culture of collaboration where teams actively seek opportunities for component reuse and are encouraged to share their own reusable components. This can be supported through cross-team collaboration events, knowledge-sharing sessions, and recognition for contributions. The no-code CoE is an important champion for these types of initiatives, but can also be supported by having the No-code Architects be part of a ‘community of practice’ who share ideas and initiatives across the broader organization.
Offer training sessions or workshops to help teams identify opportunities for component reuse. Providing technical support and guidance on best practices can empower teams to leverage reusable components effectively.
Establish metrics to measure the success and impact of component reuse efforts. Tracking the number of reused components, time saved, and increased efficiency can help showcase the value of component reuse across teams.

Successful component reuse requires collaboration, communication, and a supportive organizational culture. By implementing these best practices, you can increase the likelihood of identifying and leveraging reusable components effectively across teams.

This is a rather abrupt ending, while the text is very academic/technical and we are not sure who the target audience for this book is, all books should have an ending that at least gives a brief summary of the book, directed to the readers, whether this is a book for in-house use for a company, a general text manual, or whatever, it should end with some kind of communication between the author and the readers, void of the academic/technical text.

Quick navigation