Many software development projects fail because there is no clear understanding of what needs to be developed or because the solution that has been created does not solve the business problems. Both technical and non-technical reasons can be at play in this failure.
For many organizations, finding ways to build better software seems like an impossible task. There are too many moving parts to consider, from the cloud to mobile devices and everything in between. There are also a lot of IT pros who have been burned by harmful software or projects that were not only expensive but led to security breaches. This article will show you ways to build better software solutions based on my experiences as an architect at IBM.
The first step in building better software is to understand that everything starts with the business problem you are trying to solve. The next step towards developing a winning solution involves your view of risk. To build better software, you need to define what reasonable means in this context. That can be difficult because so many variables are involved, but determining the value proposition is critical to building better software.
Defining the business problem:
The first step in developing a solution starts with understanding the business problem you are trying to solve. Break down your requirements so that anyone can understand what the system is supposed to do for you and how it will benefit your organization.
We have seen projects fail because requirements are wordy, incomplete, or unclear. If you can’t define your business problem in simple terms, developers will struggle to understand what needs to be built. Here is an example of defining even the most complex business requirement:
“Loan officers and borrowers use the Loan Origination Application (LOA) to track their customers’ loan status and apply for a new loan. The system updates real-time for all parties involved.”
We can remove the fluff from this requirement as follows:
“Loan officers use the Loan Origination Application to track customers’ loan status and communicate with outside organizations about that customer’s application.”
This version of the LOA requirement is much easier for developers to understand and more likely to succeed because it is so clear.
Part of the challenge in defining good involves understanding your risk tolerance. What are you willing to accept as a failure? For example, if you build an LOA that should update real-time for all parties involved but fails to correctly update real-time, you might consider that a failure.
However, many will feel that this is an acceptable risk because there is no guarantee of 100% uptime in most organizations – and even less so for public cloud applications where the service could go down at any time.
As you can see, defining what suitable means is critical to success. If you have a high-risk tolerance, then your definition of good might result in more defects. You also need to be aware of technical debt and how it can negatively impact your solution.
Developing the right solution:
Once you understand the business problem and what reasonable means, you can decide how best to solve that problem. There are many different architectures to consider, but you need to pick one best fit your risk profile.
Suppose your business problem requires 100% uptime. In that case, you might choose a cloud-based or highly scalable solution because it is much less likely to fail than an on-premises database solution (although even enterprise databases can experience outages).
For example, if your business problem requires 100% uptime, you might choose a cloud-based solution with automated failover.
If your business problem doesn’t require 100% uptime, then an on-premises database configuration might be just exemplary. If your budget is limited, you can consider cloud services to get the most value for your investment. Just be aware that some cloud services are more cost-effective than others.
The best way to set yourself up for success is by defining your requirements and expectations before you even start coding. And remember that technical debt can be a genuine business concern, so make sure you test your options before choosing any particular solution.