Appian Delivery Governance Model

The Application Delivery Governance Model enables customers with a lightweight, effective way to govern their Appian delivery teams. By implementing this model, Appian program owners can ensure that applications are 1) built according to best practices and 2) adhere to program-specific requirements and standards. Designed by Appian’s Customer Success Professionals, this model provides delivery teams with the standards, measurements and process alignment needed to develop quality low-code applications, quickly and efficiently.

Roles Involved
While this model can be implemented with slight variations based on organizational requirements and risk appetite, Appian strongly encourages the involvement of at minimum the following three roles in order to implement effective governance.

Program Owner The Program Owner wears a few different hats, but is ultimately the individual responsible for making sure the governance model is followed. They are the ultimate approval authority for governance standards, ensuring that project managers enforce standards, and making the “go forward” decisions at readiness checks. They also provide delivery teams with contextual information and awareness of the program’s direction.

Program Architect The Program Architect’s primary concern is executing the governance program through a series of lightweight reviews and readiness checks. They will ensure the high quality of your application.

TIP: To get the most value out of your Program Architect, Appian encourages this role to be a part of the planning efforts early in the project lifecycle. The visibility will not only help prepare them for readiness checks throughout, but their domain expertise will also help navigate unforeseen obstacles in planning sessions.

Team Lead(s) Team Leads are the day-to-day coordinator for application development ceremonies and serve as the main point of contact for delivery teams. They ensure their teams follow governance guidelines and standards set by the Program Owner and facilitate discussions between teams where needed. They also attend all readiness checks and reviews for their teams.

Readiness Checks and Application Reviews
Application delivery requires different types of governance attention across the application development lifecycle. Appian has condensed this lifecycle into four phases and mapped a series of mandatory, lightweight readiness checks and application reviews to each phase: Prepare, Initiate, Build, and Release (see Figure 1). These readiness checks and application reviews ensure best practices and program standards are implemented consistently and that the application does not create any unnecessary or unforeseen organizational risk. 

Application Reviews
During each phase of the application development lifecycle, delivery teams engage in select reviews where their progress will be checked by an expert against outlined best practices and program-standards. These reviews are designed to be lightweight and favor discussion over documentation; although some reviews do require artifacts for facilitation.

Application reviews will result in a prioritized list of recommended next steps categorized by risk profile (High, Medium, Low). If there are findings in the “High” category, the team should address the recommendation and perform the review again. Teams should still address “Medium” and “Low” findings, but these should be done in parallel as development continues.

Readiness Checks
After a team is ready to advance the next phase of development, delivery teams engage in readiness checks. Here, program management will review the current status of all findings and determine whether the team is ready to advance to the next lifecycle phase. If a team is not deemed ready to proceed, Program Owners will provide teams with the steps needed to advance to the next phase. Delivery teams will continue this process until the application has been released.

Be sure to download the application review and readiness checklists document below.

 PDF

Solution Architecture Review
Goal: Mitigate architectural risk early in the process by modeling and reviewing foundational design decisions.
What to Bring: Completed Appian Architecture Document
When to Review: End of Initiate Phase
Attendees: Team Lead, Project Manager, Program Architect

• Non-functional requirements have been captured including:
  • Total users
  • Peak current users
  • Volume estimates for all key entities
• Platform Team has been notified of any significant changes in usage patterns that may require a resizing of the infrastructure.
• Application design does not contain anti-patterns.
• User provisioning design has been established.
• Application security requirements have been collected, and the design accounts for role-based access to relevant data.
• All external system integrations have been identified and key design decisions determined including: transport mechanism, authentication and logging.
• Reporting requirements have been collected.
• Application design adheres to organizational and platform-specific guidelines.

Development Review
Goal: Ensure the developed features are designed according to standards.
What to Bring: Demonstration of completed features
When to Review: As needed, but at least a few times every iteration
Attendees: Team Lead, Key Developers, Program Architect

• Application objects adhere to Appian Development Standards and any platform-specific guidelines.
• Key interfaces are performant: most interactions should be under 1 second.
• Role-based security has been configured for the developed features.
• Reusable component catalog is being used according to the platform-specific guidelines.
• Team has performed database volume testing
• Indexes have been created for key entities according to the Indexing Guidance.

UX Review
Goal: Ensure interfaces are intuitive, adhere to best practices, and are consistent across the platform.
What to Bring: Mockups or demonstration of developed UX
When to Review: During Initiate Phase or during sprint 1 and again before the end of the Build Phase.
Attendees: Team Lead, Key Developers, Program Architect

• Interfaces are succinct and contain just what’s needed. Any redundant or obvious labels should be removed.
• Key interfaces are performant: common interactions should be imperceptibly fast and most other interactions should be around 1s.
• User experience is intuitive and responses make sense. The outcome of an action should match the expected result.
• User experience is consistent across the application and complies with the Appian UX Guide, organizational and any platform-specific UX guidelines.

Health Check Review
Goal: Ensure developed features adhere to development standards via the Health Check tool.
What to Bring: Health Check results from the development environment
When to Review: Every iteration
Attendees: Team Lead, Program Architect

• Health Check tool has been executed on the development environment for the current iteration.
• All high risk findings are correctly prioritized.

Technical Readiness Check
Goal: Ensure the application is technically ready to release. Though the delivery team will have created a release-able application throughout the Build phase, this is an opportunity for a final check.
What to Bring: Deployment Plan, Defect Log
When to Review: During the Release Phase
Attendees: Team Lead, Key Developers

• End users have performed hands-on testing of the application.
• Addressed any critical feedback from user acceptance testing and that any outstanding application and system defects have been reviewed by the Program Owner.
• Testing included all relevant user groups (personas, geographic regions, etc.).
• Establish a comprehensive plan for the deployment that includes timing, owners, tasks, dependencies, and that all the necessary supporting parties have awareness of their responsibilities (networking, DBAs, third party systems integrations, etc.).
• A complete application package has been created for the release including database scripts.
• Verify that users have been provisioned in the appropriate authentication groups.
• Verify results of performance testing of the system based on the concurrent user activity expected, and that it was conducted with production-like data and data volumes.
  • Ensure that load tests approximate the anticipated load on the entire environment/site across all major applications, and that the tests accounted for peak usage days/weeks/months.
  • Verify that hardware sizing has been adjusted based on real and anticipated production data and usage based on load testing.