/ Stage 2

Options Analysis

Key Roles
Responsible: No-code Business Architect
Approve: No-code Stakeholder
Contribute: No-code Creator(s)
Contribute: IT, Power Users / Subject Matter Experts
Inform: Security, Enablement
Stage 2: Options Analysis

    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:
    Identify Pre-built App Templates

    • Start by identifying the possible fit of Pre-built App Templates as a starting point wherever a fit exists. Are there any existing vertical solutions or applications in the No-code vendor’s Marketplace that could be repurposed or modified to meet the business need?

    • Do you consider the processes in scope for this No-code application to be unique to your organization or to be common to industry standards?

    • What is the cost of modifying or repurposing an existing Marketplace application compared to building a new one?

    • What are the specific features and functionalities required for the business need, and are they different from the application’s capability?

    Step #2:
    Identify AI Skills for integration

    • Increasingly, you may be able to identify the possible fit of Pre-built AI Skills that may be available for integration into your application. These may be available directly from your No-code vendor (via a Marketplace) or may be available externally from third-party providers and integrated through an API.

    • What are the personas using your application (e.g., sales, marketing, support) and are there AI Skills that may help streamline and empower their engagement?

    • What is the cost of integrating a third-party AI Skill versus using one built-in to the No-code platform?

    • What are the specific features and functionalities required for the business need, and does the AI Skill directly support that?

    Step #3:
    No-code Platform Development

    • After you have evaluated the availability of pre-built app templates and AI Skills, what are the remaining key processes that will need to be created from scratch using No-code development?

    • Review the list of processes and sub-processes identified during the Business Use Case. Does the team have sufficient skills (both functional and technical) to support building out the target set of processes from scratch using No-code? What is the learning curve?

    Step #4:
    Validate integration complexity

    • For the systems/integrations that are needed, what is the level of technical complexity needed to support interfacing with their systems?

    • Do pre-built integration connectors exist in the No-code vendor’s Marketplace?

    • Are the integrations exposed using simple and documented REST APIs?

    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:
    Identify Packaged App Feasibility

    • Start by identifying the possible fit of Packaged Applications from the No-code vendor to satisfy each process use-case. Is your process standardized for the domain and does not require much in the way of amendments or customization?

    • Are there any key gaps in the ‘out of the box’ functionality that would require extension or customization? Are there any regulatory requirements that must be met by the solution?

    • What is the cost (software licenses, implementation) of the packaged application, and how does it compare to other options?

    • What is the reputation and reliability of the vendor providing the application? What is their track record of providing regular updates to functionality?

    • How easy is it to integrate the packaged application with existing systems? Do they provide well-defined and open APIs?

    Step #2:
    Identify Pre-built App Templates

    • Also, identify the use of No-code vendor Pre-built App Templates as a starting point wherever a fit exists. Are there any existing vertical solutions or applications in the Marketplace that could be repurposed or modified to meet the business need?

    • Do you consider the processes in scope for this No-code application to be unique to your organization or to be common to industry standards?

    • What is the cost of modifying or repurposing an existing Marketplace application compared to building a new one?

    • What are the specific features and functionalities required for the business need, and are they different from the application’s capabilities?

    Step #3:
    Identify AI Skills for integration

    • Increasingly, you may be able to identify the possible fit of Pre-built AI Skills that may be available for integration into your application. These may be available directly from your No-code vendor (via a Marketplace) or may be available externally from third-party providers and integrated through an API.

    • What are the personas that will be using your application (e.g., sales, marketing, support) and are there AI Skills that may help streamline and empower their engagement?

    • What is the cost of integrating a third-party AI Skill versus using one that is built-in to the No-code platform?

    • What are the specific features and functionalities required for the business need, and does the AI Skill directly support that?

    Step #4:
    No-code Platform Development

    • After you have evaluated the availability of packaged apps or pre-built app templates, what are the remaining key processes that will need to be created from scratch using No-code development?

    • Review the list of processes and sub-processes identified during the Business Use Case. Does the team have sufficient skills (both functional and technical), to support building out the target set of processes from scratch using no-code? What is the learning curve?

    Step #5:
    Identify Composable Services

    • The prior steps should have formed the core of the overall solutions architecture. You should now also revisit the elements of your application to see if there are narrow use cases that can also be covered by third-party services and composed into the core no-code application. (For example, the sales tax calculation use case can be automated by the third-party module or APIs integrated with the no-code solution.)

    • There may be Machine Language or Large Language Model (LLM) services available from third parties or from other internal development teams, which might be accessed as a composable service. These can provide powerful building blocks for intelligent behavior.

    • Just as with packaged apps, you’ll need to evaluate the cost of use of any composed services and how it compares to the cost of initial development and also ongoing maintenance/support costs.

    • How easy is integrating the composed service into the no-code application? Do they provide well-defined and open APIs?

    Step #6:
    Identify Custom Software Components

    • If you need a complex use case (with highly specialized requirements), including the development/changes of a legacy system, then you will need to plan on some custom development using a ‘Fusion’ delivery model.

    • What are the skillsets and experience required for the development team? Are these resources available within the No-code CoE or IT groups? Or will outside consulting or contracting be required?

    • How will the ongoing maintenance and support for the custom solution components be handled? What is the expected frequency of updates?

    • How significant is a development effort expected for these custom components? What is the risk of failure or delays in the development process, and how can it be mitigated?

    Step #7:
    Validate Integration Complexity

    • For composable architectures, the overall level of integration complexity tends to be higher – both due to higher numbers of integrations and diversity of APIs.

    • Plan to thoroughly catalog and validate the list of the systems/ integrations needed and size the level of technical complexity needed to support interfacing with their systems.

    • Do pre-built integration connectors exist in the Marketplace? If not, do the vendors offer simple and documented REST APIs? Will custom development be required to build integrations with SDKs or proprietary APIs?

    • Composable architectures will often build on an enterprise service bus (ESB), or other middleware to orchestrate data exchange. Validate if the ESB or middleware provider has any pre-built integrations that might be leveraged as part of building integrations.

    • It’s also common that these styles of architecture may integrate with existing data warehouses/data lakes. Validate how easily you can integrate with existing data architectures through their APIs.

    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:
    Validate Vendor Solution and Overall Viability

    • Does the Vendor have a proven track record in your domain, and what is the solution you are looking for?

    • How are the Vendor and its solutions rated by industry analysts?

    • What is the Vendor track record for providing regular updates? Do they have a process for giving you feedback on their roadmap and planning?

    • How much of the functionality you requested can the Vendor provide within one platform, or would it be a set of integrated solutions?

    • What level of independence and support do you expect from a Vendor? Are you willing to do a guided implementation using your resources and guided by the Vendor? Or do you expect the Vendor to be a part of the implementation team that implements for you?

    • Does the Vendor offer you flexibility in the deployment model with the ability to migrate from, e.g., on-premise deployment to the cloud and backward?

    • Does the Vendor comply with industry development and security regulations (e.g., ISO 27001, SOC 1/2 certifications, etc.)? This will be critical information to have as you prepare for the Governance stage later in the no-code lifecycle.

    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:
    Determine Implementation Assistance Needs

    • For the component options identified in the prior steps, what is your level of expertise in these areas? Do you have the necessary knowledge and skills to complete the project successfully, or do you need additional technical help (especially around external vendor components)?

    • What are the potential benefits of sourcing additional technical expertise? Will they be able to fill any needed skill sets related to custom-developed components or packaged app implementation?

    • What are the potential risks involved in the project? Will you be able to manage these risks on your own, or do you need someone with more experience to help you?

    • Will they be able to complete the project more quickly and efficiently than you could on your own with internal IT/development resources?

    • What are the potential drawbacks of acquiring additional technical expertise? Will this be possible within your budget, or are the costs too high?

    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:
    Identify Pre-built App Templates

    • Different Credit Unions typically have very common requirements in meeting their member requirements around lending, so for this use-case we will likely be able to find a pre-built app template as a starting point for defining the mortgage origination workflow. This would be available from the no-code vendor’s Marketplace as a starting point.

    • While there will likely be some differences in terms of requirements not met in the app template, the high similarity of business processes across Credit Unions means it will still significantly accelerate development.

    • In this case, the cost of modifying or repurposing an existing Marketplace application was small compared with the effort of building a new one from scratch.

    Step #2:
    Identify AI Skills for integration

    • There is an opportunity to enable mortgage applicants with the ability to directly engage the no-code system as they have questions, need support, or want to understand the status of their application throughout the mortgage workflow.

    • Given the newness of AI Skills, there may not be out-of-the-box Credit Union-specific AI Skills available. However, an alternative is to develop/ Service AI Skill, which can provide mortgage applicants with the ability to answer common questions about the process (drawn from FAQs) and also to get updates on the status of the application in the workflow.

    • In this case, the Service AI Skills were provided by the no-code vendor as built-in to the no-code platform, so there was minimal incremental cost of integrating third-party AI Skills.

    Step #3:
    No-code Platform Development

    • While much of the high-level business process is already defined by the pre-built template, the mortgage application itself will likely require the development of new UI forms to reflect the specific unique requirements. Additionally, specific requirements around disclosures may require additional UI steps to fully comply with business requirements.

    • It will be important to include domain experts directly in the no-code team to ensure the specific functional requirements are being met in terms of building out both extensions and new components in the no-code platform. This will also minimize the learning curve and improve the team’s speed if they have sufficient experts embedded directly in the core team.

    Step #4:
    Validate integration complexity

    • There are several key integrations required for this no-code application. While perhaps not necessarily available as pre-built from a Marketplace, several of them are available through the vendor’s documented interfaces.

      • Loan Origination Systems (LOS): The LOS will be the most critical backend system that must be directly integrated with, in order to support the workflow. (In this example, we will assume the LOS is a more modern cloud-based LOS platform that may be integrated with using RESTful APIs; however, many legacy LOS systems are commonly in use, which could require more complexity of integration and require Fusion development models.)

      • Account Servicing: Once the mortgage is approved, then it must be sent to the Servicing system to handle the ongoing administration of the Loan.

      • Decisioning Systems: There are often real-time rules-based systems to help with categorizing and prioritizing applications based on predefined rules. (This may be out of scope for the initial MVP, but will likely be an important part of streamlining the workflow with intelligent straight-through processing and help with rapidly adjusting to changing market conditions.)

      • Document Storage and Retrieval: Finished documents will need to be sent to a storage system for efficiently managing loan-related documents, contracts, and disclosures. More modern systems will be available with defined RESTful APIs which makes it straightforward to integrate into the workflow.

    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.

    Quick navigation