Introduction
This Toolkit for Options Analysis provides example checklists and questions to help you make key choices that will guide later no-code development activities. In this chapter, we will explore some of the specific questions, considerations, and guidance as you complete this stage. Refer to supporting material around both the key Roles and Responsibilities (Chapter 4), and Application Matrix (Chapter 5) which will be referenced throughout the guidance.
The outcome of this stage should be a clear identification of the overall solution architecture and approach for delivering each of the major components of the application. The solution architecture defined by this stage may evolve over time, but it should at least be the right target options that will be used for the first release.
Stage Pre-requisites/Inputs
The primary inputs to this stage are as follows:
Business Use Case Definition: The inputs you have collected and produced during the Business Use Case stage are the primary input to prepare for the Options Analysis activities.
Identified Pre-Built App Templates and AI Skills: You may have already identified possible pre-built components that may be applicable to your project. This list of components will be reviewed and expanded upon as part of this formal stage.
Third-party Packaged Applications: You may also have already identified possible packaged applications that may deliver some of the needed functionality. These packaged apps will be reviewed more formally to assess the pros and cons of integrating into the overall no-code architecture.
Technical Expertise: You may have already identified the need for additional technical expertise to support your project. It’s not uncommon to have brought in additional resources already in some capacity to help with the initial, earliest stages of planning; you should, however, review to ensure they also provide the sufficient level of technical or implementation skill sets needed for your implementation.
Much of the work in this stage will be driven by the No-code Business Architect, who will play a key role in helping to map between the business requirements (outlined by the Business Use Case) and identification and selection of different solution component options. In addition to reviewing and synthesizing existing materials, the No-code Business Architect will likely be performing some additional discovery and research (such as investigating the availability or fit of pre-built components). S/he may also need more involvement from IT stakeholders to begin assessing the ability and readiness to integrate third-party applications or components. The following are questions that can be used as part of these activities.
Key Questions: DIY Delivery Model
If you have already determined (using the Application Matrix) this project will likely be delivered using a DIY delivery model, then it is recommended to keep things simple. Try to meet your business requirements primarily through the use of a No-code platform, plus using the fewest different component technologies needed. While it’s good to have choices, including too many types of differently built components can often raise the complexity of maintenance and evolution (which will be harder to support by the DIY team). A simple, consistent, coherent architecture will generally lead to lower support and maintenance costs in the long run. Here are questions to focus on answering as part of these activities; these answers should be documented as part of the final Options Analysis deliverable produced.
Step #1: |
|
Step #2: |
|
Step #3: |
|
Step #4: |
|
Note that it’s quite possible during Options Analysis that you may discover you need to revisit your early assumptions around the Delivery Model if you uncover additional Business or Technical complexity. The iterative discovery and analysis oftentimes may create new insights that may require the use of more sophisticated Delivery models in the next section.
Key Questions: No-code or CoE or Fusion Delivery Models
In more advanced delivery scenarios, you should begin to think about composable architecture patterns. A composable architecture is typically built around a standard foundation — based upon a no-code platform — that allows you to add/change components both easily and quickly over time. It may include prebuilt components from the Marketplace. It also may integrate specific custom-developed components built by Fusion Teams to meet more complex technical requirements (e.g., integration with legacy data or highly custom user interface needs).
Finally, it will also include more significant integration with different packaged applications, legacy systems, or databases. Composable architectures use no-code as the ‘glue’ to assemble components and provide an overall architecture that is highly resilient and adaptable to change. This style of architecture can address more complex business and technical requirements but does introduce more alternative options into the solution architecture. Each of the in-scope business processes may, in fact, have different characteristics. It is still recommended that you try to limit complexity to where you can by minimizing the use of too many options.
Here are the questions to focus on answering as part of these activities; these answers should be documented as part of the final Options Analysis deliverable produced.
Step #1: |
|
Step #2: |
|
Step #3: |
|
Step #4: |
|
Step #5: |
|
Step #6: |
|
Step #7: |
|
Key Questions: Vendor Evaluation
Regardless of the complexity of the delivery model, you may be evaluating third-party vendors (to supply pre-built app templates, packaged apps, etc.) in addition to the no-code platform itself. The use of vendor-supplied components helps accelerate time to market but does require taking dependencies on an external entity as part of the solution. You will want to collect information to support/validate the successful outcome of selecting the vendor by evaluating both their solution (in meeting functional and technical requirements), and vendor viability concerns.
Here are some examples of questions to answer:
Step #8: |
|
You should be prepared to not just take vendor claims at face value but perform your own assessment and diligence to ensure the viability of the vendor’s role in your future solution architecture. Depending upon the size or complexity of the overall assessment, you may want to plan for conducting an RFI/RFP process.
Key Questions: Determine Implementation Assistance Needs
For small projects involving a DIY Delivery Model, you may be able to handle this on your own with the training of the No-code delivery team. However, for more complex solutions involving a composable architecture and Fusion delivery that will increase the complexity of the overall project, you should consider if you need additional technical expertise to assist the project team. Having the right specialized knowledge and skills to assist you can be vital to the success of the project in meeting your business goals. You should consider tapping into the expertise of internal or external technical resources skilled on the No-code platform to augment your team with breadth and depth of knowledge to support more specialized needs.
Here are some examples of questions to answer:
Step #9: |
|
By answering these questions, you can weigh the pros and cons of doing the project yourself versus securing additional technical expertise and make an informed decision that meets your needs and budget. While the final decision on whether to use supplemental technical experts does not have to be made in this stage, answering these questions could influence the overall viability of some of the choices (or, at the very least, rule out some options that may be too expensive or require assistance that does not exist to you).
Credit Union Lending Workflow
To close off this stage, we’ll continue to reference the example presented in the previous stage, which is focused on a Credit Union lending workflow. Here’s a completed checklist:
Options Analysis Checklist: Credit Union Lending Workflow |
|
Step #1: |
|
Step #2: |
|
Step #3: |
|
Step #4: |
|
This is a short example, but illustrates how a number of areas of development can be accelerated through reuse of pre-built components, and how the remainder can be added or extended using no-code development.