The traditional style of software development and implementation was based on 2 primary types of software components: Custom-built software and Commercial Off-the-shelf (COTS) software.
Custom-built Software: Most organizations prepared a list of requirements, based on their business and industry, and worked with a team of developers to get them developed from scratch. The approach suffered from a lot of issues, such as the high cost of development and implementation, a long waiting period, hosting issues, difficulty in upgrading and further expansion, data exchange with partner organizations, and more. It was still the preferred way because the organizations did not want their trade secrets to leak out, they could have software that was fully customized to run their specific business problems, and they had full control over the features of the software. This was the case with custom-built software.
COTS Software: In the case of Commercial off-the-shelf software, organizations bought licenses of a commercial product, and then an instance of the software was installed only for the organization. The installed instance of the COTS software was customized to a certain extent, like the organization’s logo, language preferences, localization settings, and other regional settings. Some of the business rules were also customized or new wrappers were provided by the software vendor. Any future upgrades were charged separately.
In both cases, the solutions were targeted toward solving one organization’s problem. The cost of developing the solution, purchasing its licenses, and operating it was high. The data generated by the solution was in proprietary formats and not easy to exchange or understand. Moreover, the time to build a fully functional solution was long and the process was cumbersome.
SaaS: With the advent of globalization and several rounds of the industrial revolution, more and more organizations started to collaborate and work with each other. It became an industry practice to define the standard processes that could be followed by other partner and vendor organizations. This was good for the business and made more profits for all the participating organizations. With standard industry practices, lower cost of operations, easy sharing of data, and dedicated solution vendors, the concept of SaaS (Software as a Service) were discovered.
Building a SaaS from an existing product
If you are still using a software solution that is custom-built for your organization, you may be sitting with one of the best opportunities for your industry to launch a new service that could be useful for businesses of all sizes.
“Every software can be offered as a Service irrespective of the domain and industry. The only thing that would vary is the levels of security”
For building a service, you need to take care of 6 things and it would be ready for hosting.
- Industry and Domain standardization
- Solution architecture
- Security model
- Integration mechanism
- Deployment model
- Pricing model
These steps are iterative and may take several rounds to reach the desired output. Adopting an appropriate software development methodology is the key to running through each iteration. We dive into a more detailed look at each of the steps below.
Industry and Domain standardization
Most business analysts would agree that organizations in a business domain follow business processes that are very similar. All they need is to identify those processes and build them from a neutral position in the software. In this way, these processes would be usable for the greenfield and smaller businesses in the domain to adopt and follow them. Definition of the business standards is the key. Some industries have consortiums following the same route, such as eTOM (Enhanced Telecom Operations Map) for the Telecom industry and OTA (OpenTravel Alliance) for the Travel industry.
Solution Architecture
A domain-driven approach is necessary to implement the standards defined by the organizations. An approach that can clearly separate the layers of technology, non-functional concerns, and business requirements. Each business function should be conceived as a microservice that can be independently separated from the other microservices in the solution. Following an Onion model could be one of the solutions. The focus of the solution architecture should be on small pluggable services that can act independently.
Security Model
Security is the key to a solution hosted on the cloud. It is at risk of cyber attacks, data thefts, phishing, impersonation, data exposure, component vulnerabilities, and more. A seemingly standard component can also turn out to be a potential source of damage, such as log4j was found to be a potential script injection source in Dec 2021. Security needs to be implemented at many levels, such as coding, validation, deployments, solution, network, and infrastructure.
Data partitioning is an important aspect of Security. It is implemented to ensure the data of different subscribers remain separate from each other. Each of the subscribers is called a Tenant.
Integration Mechanism
Defining plug-n-play integration points with standard integration mechanisms is important for exchanging data with other applications. The standard integration mechanisms include RESTful protocol, SOAP protocol, Data pipelines, and Event queues. The standard data formats are defined for each industry for providing pre-integration.
Deployment Model
When a solution is developed using microservices, it is important to prepare a good deployment model that makes use of modern deployment paradigms, such as containerization, and automatic orchestration of microservices. It is very important to ensure high reliability of the service and easy accessibility across the globe. The deployment model needs to ensure spread across multiple regions, high scalability, and high availability. Achieving an availability of five 9s is possible with a well-architected solution and a flexible deployment model.
Pricing Model
Pricing is the most important aspect according to the business owners of the organization. When a solution is converted into a SaaS offering, the pricing model is prepared based on the following factors. The pricing unit is decided based on the duration of service usage, the number of service users, count of service invocations, volume of resources consumed, network capacity, and data volume.
Conclusion
The process of converting a traditional product to a SaaS offering is a long one. The aspects described above must be expanded in detail and planned to perfection before executing meticulously. A successful SaaS offering can be created from any traditional product when it can address all of the above aspects.