SaaS / PaaS / IaaS . . . but what are we talking about?
“Go to cloud” or “Step into the cloud” are some of the most common items in modern organizations’ IT strategic plans. These concepts are broad and can refer to different goals and objectives, depending on the specifications of the organization in which they are used. However, they can be reduced to a common denominator. It is the tendency to use specialized IT services provided by external entities, often combined with the abandonment of the implementation of these services “in-house”.
An example of such approach is the use of server or hardware infrastructure made available via the Internet, i. e. the use of PaaS/IaaS (Platform as a Service / Infrastructure as a Service) type services.
Infrastructure as a Service – PaaS/IaaS model
Such services are an interesting alternative to investing in your own server room. Why is the decision to use PaaS/IaaS increasingly common in organizations? Building your own infrastructure is an investment of significant capital expenditure. It involves securing funding as well as human resources with the right skills to ensure proper operation, maintenance and repair. All of these elements are not only expensive, but also complicated. More so the larger and more numerous the organization.
Instead of building your own IT infrastructure, you can use external providers. In exchange for a subscription fee, they provide services that allow you to achieve the same or very similar goals that you would achieve with your own server room.
Software in SaaS model
A similar approach can also apply to your IT system. It consists in using software provided as a service by a company specializing in such activities. These are SaaS (Software as a Service) services and applications made available in the cloud model.
SaaS is an alternative to installing the system on your own resources – i. e. implementation realized in the on-permises model.
The differences between building a server room and using server infrastructure provisioning services are tangible and quite obvious. Is it the same for applications installed in the on-permises model and made available as SaaS services?
Definitely not! What to look for when deciding to use a solution provided as a service in the cloud?
False analogies between on-permises deployment and SaaS service
Making an application available as a SaaS service is not the same as using the software on your own infrastructure.
SaaS providers grant access to the application itself, which is ready to be configured, but do not give access to other levels of the system. In the SaaS model, vendors do not provide access to the level of the database in which the information is stored or to the servers on which the system is installed.
The result? Certain design activities will not be able to be performed by implementation teams. For their implementation it will be necessary to cooperate with the manufacturer of the software to be made available.
Therefore, at the work planning and scheduling stage it is crucial to ensure proper cooperation not only between the internal team and the implementation partner, but also with the system developer. Similar challenges related to spurious analogies between bringing on-permises and SaaS into an organization can be identified many, different at each stage of the project.
Of course, such identification is possible. if you have previous experience using SaaS or implementing specific products. Otherwise, threats to the success of the project can be overlooked.
A natural remedy for the above is close cooperation with an implementation partner who has real experience in introducing SaaS services, gained in cooperation with various vendors.
SaaS implementation is about service configuration, not software implementation
The system available in the SaaS model is, as a rule, a global solution, designed to suit “everyone”. Its creators aim to universalize and standardize the handling of business processes, to realize the requirements from “all over the world” in one system.
Naturally, these solutions may not address all local needs specific to a particular region or organisation. This is another difference compared to software installed and deployed on a single – dedicated client instance.
As previously mentioned, the ability to modify and access individual system components is limited. For this reason, in the case of SaaS solutions we do not speak of de facto implementation. We are dealing with the configuration of the service.
Standardization of business processes in an organization becomes crucial to the success of a project and brings undeniable value to the company itself. However, only the standardization performed with the support of an experienced partner will result in such a reengineering of business processes that will allow to maximize the added value from the use of configuration options, provided SaaS services.
Functional gaps and integration of the service with external systems
A functional gap is, simply put, a lack of functionality that is important from the customer’s point of view. An on-permises software implementation project usually involves some customization of the system to meet the specific needs of the customer. They are possible, among other things, because the systems are physically installed on the customer’s infrastructure and the customer has inherently unfettered access to individual system components.
The on-permises solutions themselves did not significantly “tie” the hands of the implementer. It was free from the rigors of global functionality.
The configuration of SaaS services does not allow for such customizations. Experience of on-permises system implementations is therefore not crucial in this case, although one may encounter a different opinion.
The realization of functional gaps in SaaS projects consists in building external solutions that provide the expected functionality and their integration with the SaaS service. Perform necessary data processing or provide new formats.
It is necessary to provide these solutions with the right data from the SaaS system (the interface of data coming out of SaaS), and then pass the effect of their operation back to the SaaS system. So it becomes crucial to manage the integration properly.
The same integration will also apply to external systems. Today it is difficult to imagine a system completely disconnected from the “IT world” of the organization, so this point of configuration of the SaaS service seems inevitable. Consequently, proper integration management becomes critically important and needs to be handled properly. Functionalities supporting such a service and simplifying the construction of castomization are provided by the SBS Integration Platform.
The problem with castomization? Hire robots!
Due to the limited configuration possibilities of SaaS, the use of business process automation tools (RPA – Robotic Process Automation) should be considered. It consists in using IT tools simulating the user’s work in an application or in several applications. This can be used, for example, for:
- Improving the operation by entering data into the system by a robot from an excel file or transferring data between forms / modules of the SaaS service itself,
- Information exchange between the SaaS service and external systems – integration.
- Improving data import (if there is a lot of repeated data to be entered, then instead of entering data from a file, you can prepare an automatic machine that will upload the file and add it to the system)
A possibility worth considering is the construction of such mechanisms for the purposes of test implementation. Robotics solutions are relatively cheap and can be delivered quickly.
Check the rules for provisioning and managing a SaaS service
The market practice is that with the purchase of SaaS subscription, in addition to the target production service, the manufacturer also provides a test service. However, the rules of service provision and management may differ significantly, even in the case of different classes of systems provided by the same company. Moreover, only he has unfettered access to all components of the SaaS service and many issues can be realized only by close cooperation with the system developer.
When deciding to use the service in SaaS models check the rules of cooperation. Asking seemingly trivial questions and clearly addressing obvious issues is therefore invaluable.
So how long can I expect the bug to be resolved?
When are patches and new locations delivered?
The answers to these and many other questions can be surprising, making their impact on the project very important. The right question can be identified and asked by a partner who has already conducted many implementations, both on-permises and in the SaaS model.
Identify an exit route from SaaS
In the process of purchasing and configuring a SaaS service, we naturally focus on the goal of starting to use the service within the organization. However, the successive stages of the system’s life cannot be disregarded.
The purchase of SaaS services is usually temporary in nature. What do I do when my subscription is about to expire? When and what action should be taken? How can I stop using the service and switch to another system? What if the implementation of the new system is postponed? How not to lose data during migration to a new system?
In the process of purchasing and configuring a SaaS service, we naturally focus on the goal of starting to use the service within the organization. However, the successive stages of the system’s life cannot be disregarded. The purchase of SaaS services is usually temporary in nature. What do I do when my subscription is about to expire? When and what action should be taken? How can I stop using the service and switch to another system? What if the implementation of the new system is postponed? How not to lose data during migration to a new system?
SaaS implementation is a challenge
The best recipe for problems related to the introduction of SaaS services is to work with the right implementation partner. An independent external company will provide reliable support not only in implementation but also in choosing the right service. The project of launching a new system in the organization will be planned and executed without unnecessary delays, problems, stress and additional expenses that could have been avoided. It’s a waste of time knocking down open doors – benefit from the experience of others.