Building your Center of Excellence

The key roles typically found in a foundational CoE are described in Chapter 4. It is worth repeating, however, that the CoE will not own all the roles directly but will typically provide resources in a matrixed organizational model – i.e., most of the key roles will still be driven by the business unit. Still, some specialized no-code roles may sit within the CoE. However, the CoE resources usually have a dotted-line reporting relationship with the overall business unit owner as a part of the development project.

Regardless of where the resources sit, the CoE plays an important role in managing the processes of recruiting, educating, certifying, and developing no-code creators and architects. The CoE should define the target profiles, including the specification of competencies and responsibilities for each role. Cultural fit is critical too: it is important to recruit individuals for the CoE who have the right technical and functional expertise and embrace the right cultural values around innovation.

They must also be comfortable taking risks. The no-code project teams will be moving with speed and focus on Everyday Delivery, which requires an appetite for some calculated risks and a passion for driving innovation in new ways. With no-code, you can experiment and try new ideas. The team must be comfortable with trying new techniques and evolving its practices through continuous improvement.

This CoE team will also commonly emerge after the organization has started building some no-code expertise from multiple projects. Then, it becomes attractive to standardize and centralize some no-code expertise and skills so that they can be leveraged across teams. You should identify some of the individuals from early projects and recruit them into the CoE. Their expertise and learnings as early no-code project adopters will be invaluable to the organization at large.

In Chapter 14, we discussed the importance of implementing governance practices. While the CoE is not required for these activities, it can play an important role in helping the individual no-code delivery teams navigate through these processes confidently, especially for teams that may not have prior experience in these internal and external governance practices. As the volume of no-code projects grows, the CoE will also play an important role in helping these governance activities scale and be performed consistently across the organization.

The goal of the CoE should be to act as an enabler for teams to efficiently and quickly conduct governance reviews. What can they do to help remove friction and uncertainty about the governance process? The No-code CoE should proactively start guiding individual teams early in the governance process starting at the Design Phase. This will help improve quality by ensuring that governance considerations are reviewed and addressed during the design activities, and it prevents the need for extensive (and expensive) rework later in the process.

This CoE governance model should also facilitate the auditing activities outlined in Chapter 20. As the no-code application portfolio grows, the CoE should help provide a consistent mechanism for reviewing the application portfolio for performance and obsolescence as well as updates for process and organization changes.

This No-code Playbook provides a starting point for building no-code apps. However, as you select a specific no-code vendor and gain experience in successfully delivering projects, you will start to develop additional guidelines and templates for how to build solutions. Each team that delivers a no-code project will doubtlessly add some new ideas or variants to the organization’s knowledge base, so it’s an opportunity for the CoE to continue to evolve and improve by harvesting best practices from each project and sharing them across the organization. As a result, you’ll achieve greater impact and efficiencies because you won’t be reinventing the wheel with every project.

It’s important, however, to recognize that practices and templates must still be adapted to the needs of each team or project. Each project will have unique needs and, therefore, will not use the same practices. Common best practices should be adopted and adapted to match the specific complexity of the application (using the Application Matrix) and align with the culture of the team or business group, evolving as the group matures in its use of no-code.

Finally, don’t overlook the importance of evangelism and communication of best practices.

The CoE should create an iterative approach to evolving best practices to ensure everything is completed the right way, at the right time, and with the right roles.

In Capability #1 above, we discussed the importance of fostering a culture of individuals and teams that embrace an innovation mindset and are comfortable taking risks. This “growth mindset” is essential for your ongoing efforts to improve practices. Outside the core CoE team, you should also look for ways to promote and reward this behavior; consider having the CoE give out rewards and recognition for the project teams or individuals who have contributed breakthroughs to core practices. Encourage the project teams that took risks with a new approach, even though it might have been unconventional. Building up a continuous improvement culture takes time, but with proper encouragement and enablement from the CoE, it becomes infectious and will begin to gather its own momentum.

In Chapter 15 (First Release) we described the typical set of no-code environments (e.g., DEV, QA, and PROD), how they are used, and the use of the Application Matrix for sizing according to project requirements. The no-code team itself is often responsible for its release and deployment activities, but it can sometimes run into more complexity, especially as the number of environments expands. This is where the CoE may play an important role in facilitating the underlying no-code platform and environments.

First, the CoE is likely responsible for the centralized monitoring of the no-code platform itself, including coordinating with the vendor if any updates are being applied (e.g., routine security or platform updates or new feature updates as the vendor adds capabilities). While these updates are typically automatic, the CoE may play an important role in scheduling updates (avoiding critical milestones for the business) and may also play a role in ensuring that training or enablement is rolled out to the project teams.

Second, the monitoring of the individual environments may be supported centrally by the CoE for more complex and mission-critical apps. This may help the individual project teams ensure that appropriate levels of high availability, reliability, and performance are achieved by properly tuning or configuring the no-code platform environment.

Finally, if any issues are encountered in production, the CoE may play a centralized role in working with the no-code vendor to create tickets or troubleshoot. Again, this may not be as essential for smaller no-code apps. Still, more mission-critical apps will need to have a clear service-level agreement (SLA) in place for any issue resolution and escalation, including working with the no-code vendor to deliver enterprise-grade support and service.

We’ve previously discussed the benefits of a composable architecture and using the Application Audit stage of the lifecycle to identify components suitable for harvesting and reuse. While reuse can sometimes occur based upon self-organized sharing between projects, the effectiveness of component reuse goes up exponentially if you make this a centralized function.

In Chapter 20, this was reviewed in length, but a few key points bear reinforcement with a focus on the role of the CoE:

• An important element of your component reuse strategy is facilitating collaboration and knowledge sharing across teams about the benefits of reuse and encouraging the exchange of ideas. The benefits and business value of component sharing must be promoted broadly across the organization to help drive the changes in behavior, instead of each team or project continuing to operate independently.

• The CoE should establish a standard set of practices during the Application Audit for assessing the applicability of reuse — this will include evaluating both functional and technical features of possible reusable components. This will help reduce the concerns that individual teams may not have the staff/budget/skills to invest in themselves by providing supplemental help needed to create a reusable or generic version of a component.

• Keep in mind that effectively identifying, curating, and operationalizing component reuse may require the introduction of new roles/responsibilities — typically within the CoE. Usually, this is the responsibility of a no-code business architect. They should help develop internal training around component design, curation, and reuse and communicate it to the rest of the no-code project teams. The CoE business architect should also help enable teams to assist with the initial use of shared or reusable components.

• The CoE should help promote broader visibility/discovery of available components by establishing an internal catalog or marketplace of components. You should also look to the no-code vendor’s marketplace (if one exists) to identify standard templates or components that can be reused from there.

• Don’t forget the feedback and monitoring loop. The CoE should establish standard reporting and metrics to track reuse effectiveness. A data-driven approach is essential in helping identify which components may warrant supplemental investment and where to direct additional assistance or enablement.

Many organizations will also be taking steps to define and operationalize their digital transformation strategy. Don’t think of no-code as a separate or distinct agenda, instead, connect it directly to digital transformation. No-code can operationalize and scale the building of digital applications across your enterprise. While it’s possible to pursue digital transformation with traditional custom development techniques, you will find that no-code can dramatically accelerate your ability to bring new ideas for digital innovation to the market. Explicitly advocating no-code as part of the digital transformation toolkit will help you achieve quick wins. It can also help build momentum and add additional resources to support the adoption of your no-code platform and tools.