Stage 2
Options Analysis

The quest to meet and hopefully exceed stakeholders’ expectations when developing a new application can be like the quest for true beauty — it’s always seen in the eye of the beholder. And in most cases, there will be plenty of beholders. Ask 10 different people within your organization what they expect from the app, and you’ll likely hear 12 different opinions! With all the possible different ideas and perspectives on what constitutes “success,” it’s easy to get caught up in seeking to please all stakeholders. If you do this, you risk losing focus on the high-priority requirements that must be met for your app to be successful.

Therefore, it’s critical to begin with a clear and focused understanding of the essential business requirements before you dive into designing and building your app. This is the intent of the first stage of the no-code methodology — the Business Use Case, which will define the intended business requirements and outcomes. The business use case should be in clear and simple language and defined by the designated business sponsor of the application.

It may be tempting to rush through this stage in the excitement of building apps. This can be especially true for no-code apps, given how easy and simple no-code tools are. It can seem easy to start defining the application by diving straight into the rapid construction of forms and workflows. Yet, even with no-code, you will still fail to deliver on expectations if you haven’t thought through the business requirements upfront. So, it’s important not to skip this stage. Make sure you have captured the essential business vision. Most applications that fail to meet business needs fail at this stage in the process, so pay careful attention to the business use cases.

First, let’s start by reviewing the traditional development options available to most enterprises: typically, it is a choice between “buy” vs. “build.” In most enterprises, there is a mix of both as each option helps optimize for slightly different outcomes. Packaged applications (“buy”) help you accelerate your time to market but may constrain you to fit within a defined process or UX provided by the application vendor. Custom development (“build”) will help you meet even the most demanding customer requirements, but the process will take you longer as it comes with the inherent risks of building from scratch.

You can think of no-code as the third alternative — the one that offers the best of both worlds in many cases. This can be visualized with the following diagram:

When you use no-code development for building software, you can accelerate your time to market by using configuration tools, prebuilt components, and templates. In the meantime, you can meet and exceed even demanding enterprise-grade requirements by leveraging the extensibility of the platform.

The addition of no-code enables a powerful new approach to a style of architecture typically referred to as “composability.” Gartner uses the term “composable enterprise”11. The Future of Business Is Composable, Gartner Keynote when referring to this approach of architecting modern systems built for adaptability. 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. Usually, prebuilt components are provided by the no-code vendor or its community. Composable architectures use no-code as the “glue” to assemble components and provide an overall architecture that is highly resilient and adaptable to change.

Prebuilt components allow for a tremendous amount of reuse across the platform. Such components are usually available through marketplaces maintained by prominent no-code vendors. The marketplaces allow specialized developers to build connectors, extensions, and even complete applications that the platform community can use (for example, see Creatio’s marketplace: marketplace.creatio.com). This allows specialized knowledge to be packaged for quick reuse by a nontechnical audience, and it offers greater speed of delivery and agility of the no-code solution. Does your application need to obtain data from your accounting system, but you don’t have the needed skills? Don’t worry, someone has likely built a connector that will allow you access through the no-code platform.

For enterprises used to simple “buy” vs. “build” choices, the introduction of a composable architecture approach provides more flexibility and more options to choose from — but, understandably, more options can also seem overwhelming. How do you choose the best path when there are many possible ways to build a solution to a problem? To address this dilemma, we present a simple decision framework for Options Analysis to help guide the selection process.

First, we generally suggest embracing a philosophy of simplicity. Try meeting your business requirements using the fewest different component technologies needed. While it’s good to have choices, including 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. A simple, consistent, and coherent architecture will generally lead to lower support and maintenance costs in the long run. Having a simpler architecture will also typically be easier to change and more resilient to the future evolutions that will occur.

Next, use the following questions to begin identifying the major elements of your solution: