How To Calculate Value Of An Application Post-Release?
Project-based teams have a plethora of tools to perform the cost-benefit analysis and make build-versus-buy decisions but lack tools to measure value that an application is producing after release.
Product-based companies, on the other hand, have to stay focused even after going live, so project-based teams can learn a few lessons from product-based teams in that regard. I came across this simple tool a while ago.
The three-dimensional chart shown in the figure below uses three simple metrics cost, usage, and adoption to evaluate the value of an application. It helps identify what area a team needs to focus on next in order to improve the value of an application.
Note: You can add more dimensions as well, whatever helps you calculate the value.
For example, if an application launched for a 100 people department is being extensively used but only by 5 people, then usage might be high but adoption is low. So just by doing this simple analysis, you can dig deeper and try to answer the question why adoption is low, it might be because an interface is not very user-friendly or there was not enough marketing done internally and as a result, people were simply unaware of the application etc.
Similarly as shown in the figure below, after spending huge sums of money only a handful of users have adopted the application and use it maybe once a week, then obviously money was spent on unnecessary features that do not really deliver value.
How To Go From A Project To A Successful Program?
The first couple of process automation projects is usually surrounded with excitement and enthusiasm. You have the necessary support from your sponsor and extraordinary help from the vendor as well. There is some leniency in the practices that you follow to deliver these pilot projects (a.k.a. PoC, quick win). Everyone has a vested interest at this point, everyone is trying to prove a point.
Center of Expertise (CoE)
Quite a few initiatives fail right at the beginning, and the remaining fail to grow beyond one or two projects. Over time, the level of enthusiasm will decrease, and you no longer will be able to use lightweight implementation processes. To stay on track and grow you will need to formalize your program. A Center of Expertise (CoE) can be an exceptional tool that helps you expand your program in a managed way.
Figure 1 - Digital Transformation Initiatives Failure Percentage
Unfortunately, the majority of the traditional methods of establishing a CoE, end up producing just one heavyweight body that slows down the progress while becoming a major cost center. A CoE should be a lean organization that works behind the scenes, without becoming a behemoth that simply consumes money.
There are three main components of a successful CoE.
- Strategy
- Delivery
- Infrastructure
We are not going into details of how to create a CoE, but the reason for adding this topic to the book was so that you understand what comes next. Figure 2 below shows major responsibilities of each component. Depending on the size of your program these responsibilities could be performed by three different teams, a single team or even an individual. Make sure to keep your CoE lean, and avoid making it a major cost center that can actually bring down your entire program.
Figure 2 - Center of Expertise Responsibilities
How to pick the right Process for Digitization?
Both value chain and customer journey maps discussed in the previous article will help you identify internal processes and improvement opportunities, but how do you decide which process automation opportunity to focus on first?
Automation Heat Map
An automation heat map can help you prioritize processes and activities that are good potentials for digital automation.
A great example of such an automation map can be found in McKinsey’s report “Where machines could replace humans—and where they can’t (yet)” [1]. The report uses an automation heat map to show the technical potential of automation in different sectors in the US.
Figure 1 shows a slightly modified version of the automation heat map for process automation purposes. It has two dimensions:
- Time Spent (%): This captures how much time is spent on a particular type of activity in a process and is represented by the size of the circle.
- Technical Feasibility (%): The second dimension captures technical feasibility of an activity or process being automated. This is represented by different colors.
Figure 1 – Process Automation Heat map
The table below provides a brief analysis of information presented in Figure 6.
| Process A | The majority of activities require someone to apply their expertise and working with unstructured data. Given current technologies the potential of automation is low. |
| Process B | Most of the work is predictable and a lot of time is spent on processing structured data so the potential for automation is high. |
| Process C | Even though the amount of time spent on predictable work and processing structured data is less in comparison to Process B, but the technical feasibility of automation is high. |
You can always add or change the criteria that are more suitable for your organization.
References
- Where machines could replace humans—and where they can’t (yet) - McKinsey Quarterly
Where To Begin Your Digital Process Automation Journey?
The first step on the path to digital transformation is becoming aware of your organization's current state. Knowing where you are and how things are in comparison to where you want to be and how things should be, is crucial for any planning. Unfortunately, most organizations do not have a good understanding of their current state, they do not have the necessary insights to identify processes that give them a competitive advantage or disadvantage.
Process Inventory
Organizations are made up of processes. A process inventory is a simple yet great tool that provides you with a snapshot of all those processes and activities in your organization. Infographic in Figure 1 summarizes key benefits of creating a process inventory.
You can use different tools to build a process inventory, but we are going to look at the two main ones. Both of these tools can be used independently or in conjunction with each other.
- Customer Journey Maps
- Value Chain
Figure 1 – Advantage of a Process Inventory
Customer Journey Maps
A customer journey map is a very simple idea: a diagram that illustrates the steps your customer(s) go through in engaging with your company, whether it be a product, an online experience, retail experience, or a service, or any combination. [1]
A customer journey map is a simple tool that allows you to visualize touch points between your customer(s) and your organization. It gives you an outside-in view of your organizational processes. This tool puts a customer front and center, which helps you create empathy for your customer. It provides you with insights into all the activities your customers perform, their motivations, questions, and barriers at each stage. In addition, not only does this tool identify all the organizational processes a customer interacts with, but it also captures their positive and negative experiences as they interact with those processes.
Customer journey maps can be end-to-end or focus on a single area. There is no one standard version of the diagram, normally it would be some sort of infographic with a timeline showing user’s experience. Figure 4 below shows a high-level customer journey map for a bank. [2]
Whichever format you choose, the goal, of course, is similar; learn about customer experience and find out what can be done to improve that. Just the act of creating a customer journey map helps in understanding the customer in a better way. Once you have created a customer journey map, identifying and prioritizing processes that can improve customer experience becomes much easier.
Figure 2 – Customer Journey Map for a Bank
Value Chain
Value Chain analysis was first discussed by Michael Porter in his 1985 book “Competitive Advantage”. Value Chain is a strategy tool that helps you visualize the process view of an organization [3]. It identifies all the primary and supporting processes involved in creating value for a customer. This gives you an inside-out view of your processes. The analysis reveals processes and activities where the competitive advantages and disadvantages of an organization are.
As part of the analysis, you look at the organization from the top down, create an inventory and models of all the processes, score them for the value they generate and identify all opportunities for automation. This exercise helps you understand how things are actually being done right now, what is generating value, what processes need improvements and of course what processes or activities can be automated. The value score can also help in prioritizing the work that needs to be done first.
Figure 3 - Value Chain Analysis
References
- Using Customer Journey Maps to Improve Customer Experience - Harvard Business Review
- The Retail Bank’s One-Stop Guide to Journey Mapping - Tara Litchfield
- Value Chain Analysis - Strategic Management Insight
How To Make BPMS And RPA Work Together - Part 2
In my previous post, I explored two different approaches that can be used to make a Business Process Management Software (BPMS) and a Robotic Process Automation (RPA) tool work together. This post expands on the same topic but from a different perspective. It uses process hierarchy as a reference to identify the tool that is better suited for each level.
A Process Hierarchy is a way to structure processes to ensure the value they provide can be measured and the process outputs align to the organizations business goals.
Source: LinkedIn
Process hierarchy is usually represented as a pyramid as shown in Figure 1.
Figure 1: Process Hierarchy Pyramid
Each level in the pyramid defines the granularity of processes in the hierarchy. Normally processes are divided into 5 levels in the hierarchy.
- Level 1: Process categories
- Level 2: Process groups
- Level 3: Processes
- Level 4: Sub-Processes
- Level 5: Standard Operating Procedures (SOPs) / Work Instructions
For simplicity, I have created another version of the process hierarchy as shown in Figure 2. In this simplified version Level 1 and Level 2 have been merged into a single layer, and Level 3 and Level 4 have been merged into a single layer.
Figure 2: Simplified Process Hierarchy Pyramid
Now let’s take a look at tools that you would be suited for each layer.
Level 1 + Level 2 (Value Chain)
Processes at this level are at a very high-level and there is not much automation that happens at this level. They are primarily used in reporting to senior management, so the purpose of this level is mostly for categorization, grouping and/or summarizing metrics of processes at lower levels.
Level 3 + Level 4 (Processes / Sub-Processes)
Processes in these two levels are also referred to as executable processes. These consist of processes and subprocesses that can actually be implemented. An example of this would be the end to end Order Management process. Automation of such end to end processes is best suited for a BPMS because they provide necessary tools to model, build, optimize and monitor long running processes.
Figure 3: Order Management Process
Level 5 (Standard Operating Procedures - SOPs)
This level consists of procedures or, work instructions that are created to help individuals navigate a screen, a system, perform a single activity. These are very detailed instructions and rules that list exact steps that a person needs to perform in order to complete a task.
Referring to the earlier example of order management process, once your process reaches the Ship Order activity, in a manual process a user will need to work on multiple systems to ship an order. Here is a quick list of different tasks that a user might need to perform.
- Login to order management system
- Search and open order details
- Login to the shipping vendor’s system
- Copy and paste all the required data from order management system to shipping system
- Ship the order and copy tracking number from shipping system back into order management system
- Log out and close the shipping system
- Mark order as shipped in order management system
- Log out and close the order management system
Compared to a BPMS, in this case, an RPA tool can be quickly and easily trained to automate these activities. So, instead of a human doing all the tasks, a trained bot can perform all the tasks.
Figure 4: Ship Order Activity
Conclusion
As I concluded in the previous post as well, in my opinion, BPMS and RPA are a great match, but you just have to make sure that you are using them for the right kind of use cases.
Share your thoughts on how you are planning to use BPMS and RPA in your organization. What opportunities or challenges do you see in implementing both together?
Key Components Of A Digital Business Platform
Note: I am not associated with any digital business platform vendor. All information shared in this article is based on my experience and research.
Overview
Customer experience, operational process, and business model are the three key areas of digital transformation 1, 2. Regardless of which areas an organization focuses on, it needs a technology platform that will support its digital transformation goals. The term being used to define such platforms is Digital Business Platform (DBP) 3, 4.
Figure 1: Key Areas of Digital Transformation
According to Jim Sinur, DBP is a convergence of best of breed approaches 5. The list below shows key components that constitute a DBP 6.
- Process Management
- Decision Management
- Integrations
- Data & Analytics
- Internet of Things
- Artificial Intelligence
Figure 2: Key Components of a Digital Business Platform
All these components might not be available as part of a single unified platform. A single unified platform, of course, is preferred, but if your organization is heavily invested in some of these components already then you can always add-on to create a logical DBP of your own.
DBP vendors have taken different approaches as well to create their offerings. SoftwareAG, for example, had an integration platform, and over time acquired other products for their DBP offering 7. While Appian had a business process management software, they built additional features from scratch for their low-code application development platform 8, 9.
Now let’s take a deeper dive into each of these components.
Process Management
If you can't describe what you are doing as a process, you don't know what you are doing. - W. Edwards Deming
Processes are everywhere, they are what make organizations unique, they can make or break an organization. A process management component allows organizations to orchestrate the flow of work between people and systems. It provides tools for automation, execution, monitoring and optimization of processes.
All three key areas of digital transformation i.e. customer experience, operational process, and business model heavily rely on process management. A great looking website, mobile app or a digital product is required, they will (likely) result in great customer conversion rates, but in all cases, they will trigger or interact with some internal process. An organization will be able to acquire new customers of course, but customer retention will heavily depend on the quality of its internal processes 10.
Take for example the most common and relatively simple process of expense claims. It involves at least three sets of people and multiple systems. It can be done on paper or via email, but then you have no insights into the process. By automating this process, you can bring all the data into a single place, reduce data errors, provide visibility, and reduce cycle time.
Figure 3: Expense claims process
Decision Management
Management manages by making decisions and by seeing that those decisions are implemented. - Harold S. Geneen
Business users have traditionally been dependent on technology teams for implementing and maintaining business rules in applications. This dependency can be a cause of incorrect implementations and more importantly slow down any response to changes that are needed. A core component of DBP is decision management. Decision management provides a convenient way for both technology teams and business users to capture, automate, test and govern business rules 11.
Consider a simplified version of account opening process. Once an applicant submits new account application, the very first step is to check their credit score. Keeping this rule in the application will cause issues later on when changes are required. For example, organization policy changes, and now the new credit score requirement for opening an account is 725 instead of 700. If this rule was built into the application, then this update will require changes to the application. What if the same rule is used by multiple applications, then multiple applications will have to go through the same upgrade cycle.
On the other hand, if these rules reside outside of applications and are accessible to business users, then any change in organizational policy can be easily applied without involving the technology teams. Another benefit of keeping rules outside of applications is that you can have a single organization-wide rules repository that all applications can access, this ensures that organization policies take effect across applications without going through a long project of changing rules in each and every application.
Figure 4: Model of an account opening process
Integrations
A process cannot exist in a silo, in order to deliver real value, it has to integrate with other systems.
In most organizations, especially the ones that have legacy systems or have gone through mergers and acquisitions, there are a lot of systems that do not talk to each other. In absence of any system integrations, standard operating procedures are born that require people to do useless repeatable tasks. These tasks do not create any value for the organization but are necessary just to make things work. People end up filling gaps in technology instead of it being the other way around.
Integration component is a must-have for DBP. Two ways a DBP can reduce these useless human tasks and fill gaps in technology are by providing system integration and robotic process automation (RPA) capabilities.
- Integration Platforms: Integration platforms are specifically designed to handle different types of integrations. Not only do they support most protocols and have a large repository of pre-built connectors, they also have powerful mapping, transformation, and routing capabilities. All of these capabilities are necessary to build complex integrations. Another advantage of using an integration platform is that they prevent integrations from becoming point-to-point, so any changes in source system do not have a huge impact on client systems.
- Robotic Process Automation (RPA): RPA is not the traditional type of integration. RPA tools allow you to train software bots to mimic human actions e.g. open browser, log in, copy-paste data etc. So, in cases where integrations might take a while to build or are difficult to build e.g. legacy systems, RPA provides a great alternative 12.
Figure 5: Integrations platform architecture
Data & Analytics
If you cannot measure it, you cannot improve it. - Lord Kelvin
From acquiring new customers to winning elections, data has become the key. Answers to following and many other questions reside in the data.
- Where are different bottlenecks in the process?
- How are different rules performing?
- What are the common integration failure points?
- What is the most popular product?
- What other products did the customer look at?
- Can we recommend any other products to a customer?
- How many complaints have been received for a certain product?
Data and analytics capabilities of DBP should include features such as:
- Sourcing of data from different systems (ETL)
- Creating unified views of entities (DWH)
- Building reports, drill down, slice and dice (BI)
- Identifying key metrics (BI)
- Mining data to find patterns (Data Mining, Process Mining)
Figure 6: Data sourcing flow
Internet of Things
Analysts are forecasting that by the year 2020 there will be more than 20 billion connected things (devices) and the total revenue from the internet of things (IoT) will easily surpass $2 trillion 13.
A DBP needs to include capabilities of an IoT platform. An IoT platform allows developers to build, deploy and manage IoT applications from one central location in a secure manner. It provides necessary infrastructure and development tools so that developers focus on building applications and not waste time on setups 14.
To better understand how IoT can help organizations, consider the example of a Fleet Management company. Here are a few questions that a Fleet Management company might be interested in answering 15.
- Drivers: How are drivers performing? Are they making unnecessary stops? Are they driving over the speed limit and wasting fuel?
- Vehicles: How is a vehicle performing? Are there any issues that might need immediate attention e.g. low battery?
Without a connected fleet, all this data would come from drivers (which cannot be reliable), or by doing inspections only after a vehicle is back or something breaks down. Now, if the entire fleet was connected, then the vehicle would be transmitting this data automatically and using analytics all these questions and more could be easily answered.
Figure 7: Sample Fleet Management Dashboard
Artificial Intelligence
Artificial Intelligence (AI) is usually defined as the science of making computers do things that require intelligence when done by humans 16.
AI is going to have a huge impact on our future, but AI is not just a single technology, it is a combination of different research areas such as machine learning, deep learning, natural language processing etc. To better understand why AI capabilities need to be part of DBP and how it can help organizations, let's take a look at a couple of examples.
Medical Treatments: Daniel Kahneman a famous psychologist did a lot of work on the psychology of judgment and decision-making. In one of the experiments, his team worked with doctors to identify seven factors that they used to diagnose if an ulcer was malignant. Based on these factors, his team developed a model that could render diagnoses. Next, they fed both the doctors and the model same data, 96 different stomach ulcer images and asked for their diagnosis. In some cases, without telling the doctors they showed the same image twice at random to the same doctor. The resulting data was very interesting, not only did different doctors have different opinions but even the same doctor had different opinions for the same image. The model, on the other hand, had a better prediction rate. 17
Machine Learning (ML) does the same thing, it can consume huge volumes of data to create a model. If we look at medical treatments, the model can use all the data to recommend a course of treatment. We do not have to replace a doctor, but it can augment and help make better decisions.
Figure 8: Medical treatment recommendation
Customer Service: To keep existing customers happy and acquire new ones, a good customer service is extremely important for organizations. But depending on an organization's size, customer service department can be a huge cost center. Natural Language Processing (NLP) has improved a lot, now computer programs can not only understand standard sentences, but they can also interpret slang and tone used in the sentence.
As a result, the idea of chatbots is becoming extremely popular in the world of customer service 18. Chatbots can be trained to understand what people are asking and provide relevant responses. For cases where the question is outside of a chatbots training, it can simply redirect them to a specialized human representative. Chatbots can augment customer service representatives, and reduce cost by taking care of the standard queries.
Figure 9: Chatbot sample interaction
Conclusion
It’s so much easier to build code with objects, like Lego blocks, than it is with lines of code. - Matt Calkins
We looked at six key components of a DBP, but before I close this post, I would like to take a quick look at different characteristics of a DBP.
- Unified
- Low-Code
- Cloud-based
Characteristics listed above result in agility, smaller learning curve, reduced support and maintenance costs, reduced time to market and simpler licensing plans.
Organizations need to have Digital Business Platform in their toolbox if they not only want to survive but thrive in this fast-paced and disruptive digital world.
References
- The Nine Elements of Digital Transformation by George Westerman, Didier Bonnet and Andrew McAfee (MIT Sloan Management Review)
- What is Digital Transformation by Adeel Javed
- Is the Digital Business Platform the Future of BPMS?
- Is the Digital Business Platform What BPM Has Been Aiming for All Along?
- Creating a Digital Business Platform by Jim Sinur
- bpmNEXT Keynotes by Keith Swenson
- SoftwareAG Digital Business Platform
- Appian Low-Code Application Development Platform
- Why Use Low-Code Application Development Platforms? by Adeel Javed
- Why Digital Transformation Can't Proceed Without Operational Process Transformation, by Adeel Javed
- A Realistic View of Business Rules Engines
- How To Make BPMS And RPA Work Together
- Gartner Says 8.4 Billion Connected "Things" Will Be in Use in 2017, Up 31 Percent From 2016
- Building Arduino Projects for the Internet of Things: Experiments with Real-World Applications, by Adeel Javed
- 5 Ways The Internet Of Things Revolutionizes Fleet Management, by Jay Krishnan
- What is Artificial Intelligence?, by Jack Copeland
- The Undoing Project, by Michael Lewis
- Ultimate Guide to Leveraging NLP & Machine Learning for your Chatbot, by Stefan Kojouharov
How To Make BPMS And RPA Work Together - Part 1
Robotic Process Automation (RPA) has been gaining traction in recent years. It has moved from being a mere buzzword to being a priority on organization's to-do list.
Being a Business Process Management (BPM) practitioner, I am interested in exploring how a BPM software (BPMS) can work with an RPA tool. If you look at the leading BPMS vendors from different magic quadrants, you will see a trend developing. Pegasystems a BPMS vendor acquired an RPA tool last year. Appian, another BPMS/low-code vendor had RPA front and center at their annual conference.
In my opinion, RPA compliments BPMS very nicely, it can actually increase adoption of BPMS, and vice versa. In rest of this article, I am going to explore two different approaches that can be used to make a BPMS and an RPA tool work together in harmony.
Process-Driven RPA
A process cannot exist in a silo, it has to integrate with other systems in order to deliver real benefits. Unfortunately, in most organizations, a fully integrated process is only part of the vision and not reality.
Unfortunately, in most organizations, a fully integrated process is only part of the vision and not reality.
Various factors such as mergers, acquisitions, legacy software or resource constraints can stop you from building those much-needed integrations. Lack of integrations definitely has a negative impact on adoption and usability of the automated process.
Example
Consider a basic version of the order management process. You have automated the process using a BPMS, but it lacks integration with let's say the shipping vendor's system.
In order to complete the Ship Order activity shown in the process above, you will need to work on multiple systems. Here is a quick list of different tasks that you might need to perform.
- Login to order management system
- Search and open order details
- Login to the shipping vendor’s system
- Copy and paste all the required data from order management system to shipping system
- Ship the order and copy tracking number from shipping system back into order management system
- Log out and close the shipping system
- Mark order as shipped in order management system
- Log out and close the order management system
If you get one or two orders a day, these tasks might not be a big deal, but if this is happening 100 times a day, then you are spending a considerable amount of time on non-value add work.
Approach
If you have similar situations in your organization, where processes have been automated using a BPMS but due to lack of integrations have resulted in swivel chair activities, then RPA tools can help you.
A swivel chair activity means that a user has to perform tasks in multiple systems in order to complete a single activity of a process. In the order management process example, Ship Order was a swivel chair activity.
The idea behind Process-Diven RPA approach is that your process keeps running inside a BPMS without any major modifications. You automate non-value add swivel chair activities by using the digital workforce (bots) provided by the RPA tool. Referring to the earlier example of order management process, once your process reaches the Ship Order activity, instead of a human doing all the tasks, a trained bot can perform all the tasks.
This approach can help you (in a way) integrate with systems that might not have been possible otherwise and more importantly free up your human resources, who can work on value-add work instead.
RPA-Initiated Process
A bot is great when you have well-defined repeatable tasks that it can perform, but what happens when there are data anomalies or errors? It is simply not feasible to train a bot with all possible exception cases (unless it is a self-learning bot, topic for another day).
Example
To further elaborate this approach, let’s take a look at trade reconciliation process. This process usually happens at end of a trading day, and the goal is to make sure that balance is accurate in two or more systems.
The figure above shows two hypothetical systems used for trading. Here is a quick list of different tasks that an agent might need to perform for reconciliation.
- Login to trade management system of the firm
- Search and open the customer in trade management system
- Login to broker system
- Search and open the customer in broker system
- Verify that end of day balance in both systems is same
- Log out and close the trade management system
- Log out and close broker system
Now consider the exception case where at end of the day, the balance was not same in both systems. In this exception case, an agent will need to perform follow-up tasks, which might require a call or email to the client and broker to find out the reason balance is not same.
Approach
In such scenarios, a bot can be trained to perform the daily repeatable tasks of checking balance in both systems, but training it on all exception scenarios, follow-ups, and follow-up actions might not be possible, and this is where BPMS comes to the rescue.
As the name suggests, the idea behind RPA-Initiated Process approach is that when a bot has not been trained to handle exception cases, it requests human intervention. The bot completes its processing, kicks off a human activity inside BPMS and moves on to the next set of work. This approach works great when a majority of the time a bot is able to complete processing without issues, but in those minor instances when they do find anomalies, a process is kicked off in BPMS so that a human can follow-up and resolve the issue.
This approach works great when a majority of the time a bot is able to complete processing without issues, but in those minor instances when they do find anomalies, a process is kicked off in BPMS so that a human can follow-up and resolve the issue. This again lets your resources focus on actual value-add work instead of spending time on mundane tasks.
Conclusion
In my opinion, BPMS and RPA are a great match. The two approaches discussed in this article show that if both technologies are used in harmony they can really complement each other and increase adoption.
Share your thoughts on how you are planning to use BPMS and RPA in your organization. What opportunities or challenges do you see in implementing both together?
Why Use Low-Code Application Development Platforms?
Note: I am not associated with any low-code application development platform vendor. All information shared in this article is based on my experience and research. I have been developing applications professionally since 2005, initially with programming languages such as Java, and later with various process automation and application development platforms (12 so far, but who's counting).
Can I use a low-code application development platform to build applications for my space shuttle? Sure you can, but should you? No, at least not yet.
In this article, I am going to try to sift through all the noise about low-code platforms and show you why I think organizations should consider low-code platforms for their development needs. We are not going to look at any particular platform, instead, we are going to run a simulation of sorts. We are going to take a set of requirements for a simple application, and then find out what type of effort would be required to implement, test and maintain the application using following development methodologies.
- Components Off The Shelf (COTS)
- Custom Application Development
- Low-Code Application Development (a.k.a. Low-Code Platform)
Next section lists down high-level requirements for the application.
Requirements
For the purpose of this article, consider yourself as being responsible for building a new Expense Claims application. It is a simple yet important and relevant application that is commonly used in organizations of all sizes. Here is a list of requirements defined by each role.
The diagram below provides an overview of the process described in requirements.
Once you have an understanding of your requirements, the very next step is to decide if you are going to Build or Buy. Build versus Buy is an age-old discussion, that has been going on for decades. What's important to note here is that most of the available analysis and tools are about COTS versus Custom Application Development and don't necessarily include Low-Code Application Development. So, let's do a comparison of all three options.
Components Off The Shelf (COTS)
Components Off The Shelf (COTS) also know as canned solutions are readily available software components that can be installed as-is or with few customizations instead of building a custom application.
COTS may be a viable solution if a good software component is already available that more or fewer maps to your requirements, your team does not have necessary technical proficiency in building a custom solution or unique technology or solution would not be a competitive advantage [1][2][3].
Take a look at the oil rig transporter shown in the video below, it is designed to transport humungous oil rigs from one part of the world to another. It does what it is designed to do accurately and efficiently, but it cannot be used for many other purposes.
https://youtu.be/xsnW5CHrpQ8
COTS, in my opinion, are similar to the oil rig transporter i.e. they are built to do one thing very effectively, but they won't meet your every need. COTS are difficult to customize and integrate, so you end up changing or giving up on important requirements.
Another important aspect to consider is that for each new application you will either need to add a new module to your existing COTS solution or buy a new COTS solution altogether. A single department may only have one or two COTS solutions, but the organization as a whole will be full of different COTS solutions that may or may not talk to each other. Of course, they solve the problems they were brought in for, but this ends up creating silos that require more work to simply integrate.
Looking at the expense claims application requirements, not all COTS solutions will come with a mobile app and there is a good chance they will not be able to integrate with all your systems. More importantly, an expense claims application cannot be extended to build a leave management system, you cannot reuse any components, you will need a new COTS solution that does leave management.
Now let's move from Buy to Build.
Custom Application Development
Custom application development means building an application from scratch. You can build pretty much anything using custom application development. It allows you to be agile and building a unique solution can give you a competitive advantage.
Unfortunately, after hearing the term custom application development, the very first thought that comes to mind is:
Oh boy, this is going to take a lot of time and huge sums of money to implement!
Let's take a look at requirements for our expense claims application again. A quick review tells us that we will need to develop following components to accomplish all the requirements.
- Design data model, create objects and tables
- Define workflow to assign tasks to appropriate users, either by coding if/else conditions or using a third-party API
- Integrate workflow with an SMTP mail server for sending email notifications and escalations
- Integrate workflow with document management system to upload all attachments
- Integrate workflow with payroll management system to push data
- Create a web portal
- integrate with LDAP for authentication
- define rules for role-based security, i.e. what type of user can see what options (actions, menus, tasks etc.)
- develop web forms for each task
- define rules for validations to ensure data accuracy
- create reports
- Create an iOS mobile app
- integrate with LDAP for authentication
- define rules for role-based security, i.e. what type of user can see what options (actions, menus, tasks etc.)
- develop web forms for each task
- define rules for validations to ensure data accuracy
- create reports
- integrate with the phone camera to capture receipts
- Create an Android mobile app
- integrate with LDAP for authentication
- define rules for role-based security, i.e. what type of user can see what options (actions, menus, tasks etc.)
- develop web forms for each task
- define rules for validations to ensure data accuracy
- create reports
- integrate with the phone camera to capture receipts
A simple and straightforward expense claims application has suddenly gotten out of hand. We are already looking at four different codebases. First the codebase for common components, such as data model, workflow, task management, and integrations. Then three codebases for the web portal, iOS mobile app, and Android mobile app, they do not provide any different functionality as such, but they all require different codebases, expertise, and resources for implementation.
Building all the functionality listed above will result in thousands of lines of code. Not only is that going to take a lot of time and resources to implement, but as per industry average during development, we should expect
15 - 50 errors per 1000 lines of codes. [4]
This, of course, means that in addition to a large development team you will require a good sized quality assurance team as well.
Now, let's ask the same question that we did for COTS, can this application be extended to build a leave management system? Except for the main web portal, not really, everything else will be unique for that application. So, almost an equal amount of effort will be required to build a leave management system.
So yes, you can build almost anything with custom application development, but it seems too slow. What other options do you have? Well, this is where low-code platforms come into the picture.
Low-Code Application Development
Low-code platforms provide you with a comprehensive set of tools to build your own applications. They are not restrictive like COTS and they are definitely faster than custom application development discussed in the previous section.
To better explain this, let's take an example from the construction industry. According to studies, the average time to build an apartment building in 2016 for the US was between 10-14 months [5]. A construction company in China, on the other hand, is building a new 20 story apartment complex from scratch in just 15 days. How do they do this? Well, they use pre-fabricated components that have already been built and tested in their factory. Once these pre-fabricated components arrive on site, they are only required to be assembled. So, not building every wall and ceiling onsite from scratch, allows them to achieve this extremely fast construction cycle.
https://youtu.be/veNf-bz99cI
Low-code platforms use the same concept of pre-fabricated components. Most of the components that organizations require to develop an application come out of the box. They have been carefully designed, developed and thoroughly tested. The figure below shows various tools and out of the box components that a good unified application platform provides you.
Once again, looking at requirements for our expense claims application we can see that most software components that we identified in custom application development actually come out of the box in low-code platforms. Here is a quick summary of what it will need to build the same expense claims application using a low-code platform.
- Use a visual designer to define data model and all objects and tables will be created automatically
- Use drag and drop process designers to define workflow
- Use out of the box task management to configure who gets the task and what form they see
- Configure your SMTP mail server to send notifications
- Use out of the box configurable plugins to integrate with document management system and payroll management system
- Use out of the box web portal that allows you to simply configure authentication policy and role-based security
- use a visual designer to quickly create web forms and reports
- configure rules for validations to ensure data accuracy
- Low-code platforms use the concept of build once deploy anywhere, so no need to create a separate iOS mobile app or Android mobile app, these come out of the box as well
Now as you can see, because you are using out of the box components, not only does your development cycle reduces by many folds, but you end up writing much less code. This translates into less number of development and testing resources. Also, since you are maintaining a single codebase, maintenance cost is reduced significantly as well. So, not only low-code platforms allow you to build unique applications, they do so at a much faster pace.
Conclusion
COTS solutions are viable options in a few scenarios, but they do not give you any competitive advantage, you have to give up requirements and they create more silos in an organization.
Custom application development, allows you to build something unique to your organization that gives you a competitive advantage but requires a lot of time and resources to design, implement, test and maintains.
In this very digital and fast moving world, every organization needs to be extremely agile. A low-code platform allows you to do that. You can still build custom applications, but at lightening speed (maybe not lightning, but pretty fast). You still need developers and testers but instead of a team of 8, you might only need 2.
In my opinion, low-code platforms have improved significantly and now is a good time to start considering them for your development needs. To get started, take a look at The Forrester Wave™: Low-Code Development Platforms report, this will give you an idea about different vendors and how they stack up (you should be able to find a free version of the report from one of the vendor sites).
References
- How to determine when to build or buy enterprise software
- Build vs. Buy: How to Know When You Should Build Custom Software Over Canned Solutions
- Build Vs. Buy: A Dangerous Lie
- Code Complete: A Practical Handbook of Software Construction, Second Edition
- Time to Build an Apartment Building in 2015
eBook Overview: UX Patterns for Enterprise Applications
This post provides an overview of my new free eBook "UX Patterns for Enterprise Applications".
What This Book Covers
User Experience (UX) is an important field, lots of money and research is going in defining this field. Getting the UX right is an important step while designing consumer apps. Unfortunately, while building enterprise apps UX becomes a low priority. In my opinion, the reason is very simple, the conversion rate is not an issue, users have to use the application no matter what, so no one spends time and money on UX research.
Most organizations do not have dedicated UI/UX designers to projects, and developers like myself end up doing most of the UI design. So the idea behind this eBook is to look at the common functionality that most enterprise apps provide, and share patterns that developers can use to improve the user experience.
Patterns
- Navigation
- Inbox
- Layout
- Milestones
- Urgency & Timeliness
- Input Fields
- Smart Defaults
- Tabular Data
- Linked Data
- Location Data
- Relevant Data
- Search
- Actions
- Error Messages
- Feedback
Download
You can download the free eBook from dropbox.
UX Patterns For Enterprise Applications – Feedback
Just like a process model requires continuous improvement, so should the UI. A good tip would be to provide a link to users to submit quick feedback.
Want to learn more about UX Patterns? Download your copy of "UX Patterns for Enterprise Applications" here.