Developers vs the business
Almost as old as the Marvel versus DC discussion is that of the relationship between software developers and the business itself. Developers care about the code, the business cares about revenue, and between the two lies a wasteland of misunderstanding and miscommunication.
While the pros and cons of acquiring software as a service (SaaS) have been well covered in general, there are other benefits of SaaS that have been less explored. One of these is its ability to bring the business and developers closer together.
Bridgette Graham, CEO and founder of J Soft Holdings, says: "Almost all companies have developers of some sort, either employed internally or contracted, and these are generally expensive resources as they are highly skilled and/or scarce and hard to find."
If developers are contracted, they're paid per hour, while if they're employed in-house, they traditionally earn big salaries. Either way, they're an expensive resource, but any business that wants to build its own solutions requires access to a developer.
The challenge is that developers don't always have the same priorities as the business. For the business, time to market and return on investment is important, while for the developer, getting the coding just right is a priority. And this is where conflict comes in. The business is putting pressure on the developer to move more quickly and produce more and more, while the developer is absorbed in... well... developing.
Business and developers are almost adversaries, with one chasing speed to market and minimising cost and the other in the endless pursuit of the perfect code. "It make more sense to have people who understand the needs of the business empowered to solve the problem at hand," says Graham.
Developers simply don't care about business processes, they want to write code and algorithms that don't necessarily add business value. If you can give that portion of the process to the people who do understand the business processes, the right people will start solving those problems. Another downside to developers is that they want to build from scratch every single time, and sometimes this can be to the detriment of the business. While the distance between software developers and the customer has narrowed, they still don't always understand the importance of the user experience or the customer value of the product they're building. What's required is an intermediary, someone who is enabled to solve those problems.
At this stage, we introduce the concept of empowering people working in the company that are technical enough to use low-code, no-code platforms, such as provided by SaaS, enabling them to do what developers used to do in the past, the so-called 'citizen developer', as per Gartner. These people are the process owners within the organisation, stakeholders who would have more insight into the business problem that needs to be solved.
Graham says: "Apart from AI (artificial intelligence), there are very few problems that haven't already been solved and solutions built. There's no need to waste time reinventing the wheel. We're proposing a pick-and-mix approach to coding or building apps, if you will. By making software available as a service in a low-code, no-code environment, we enable technical people who aren't necessarily developers to use blocks of solved code and, if needed, developers can build on top of that to create bespoke and innovative solutions for the business.
"Your developers, or other appointed staff, can focus on personalising existing applications for your business, using a low-code, no-code approach to DevOps instead of writing everything from scratch."
Not only is it expensive and time-consuming for developers to keep reinventing the same pieces of code, by going the SaaS route you can free up your company's technical skills to focus on products that add business value, on developing new and innovative stuff. With SaaS, you can get away with graduates building complex systems for you, which also has implications for skills; it becomes easier to find those skills, as opposed to software developers, who are few and far between.
It all comes down to needing less sophisticated resources, as well as less time and money spent on development. There's still a need for expert resources, but less of them and the ones you have are now freed up to focus on items that are progressive and of value. A lot of software development companies suffer from this problem: they end up putting senior developers on simple tasks. Low-code, no-code resolves that challenge.
Of course, the biggest advantage of having an expensive in-house developer is that your business owns that intellectual property outright. One concern that most businesses express around SaaS is who owns the intellectual property when the contract comes to an end? "Clients are increasingly focusing on the contract's exit clause," says Graham, "considering the risk and ramifications of losing access to your software should the client or service provider terminate the contract, for whatever reason."
"The risk," she continues, "is that just as you've built on the software and created the perfect solution for your business, you now need to change service provider because of a change in company policy, for example. An escrow agreement could protect the business against such an eventuality. The service provider must provide the business with some means to carry on regardless. This could be in the form of a runtime version that can run in its current state going forward until the business finds an alternative provider and platform, should the worst happen."
Naturally, if the relationship is going to come to an end, regardless of the reason, the business won't benefit from training, support or upgrades. But, it can opt to pay a once-off fee for a runtime version of the software, if they go that route. However, the business will never own the IP or be able to manipulate it because it will remain in its current state forever. This will only give the business time to bridge the period it takes to find a new provider and solution.
Graham concludes by predicting: "Software is going to become a commodity going forward. The business will just be able to subscribe to it and choose the bits and pieces that it needs to use as a building block for further development."