zaterdag 21 januari 2017

PAAS, the magic word

Since customization in Oracle Cloud applications is not possible (next to personalization of course) the new magic word I keep hearing is 'but you can use PAAS'. Sigh of relief right?
But what does this mean?

PAAS is a nice acronym for 'a machine' that is located 'somewhere' with 'some kind of tooling on it'.  In case of PAAS it's actually a machine in the cloud, handled by an external party (Oracle in this case).

So what is the idea behind 'we can create customizations using PAAS'? Actually what we are saying is that you need a machine to build your customizations and you can connect it to your SAAS application. You can fetch data from it using available web services or BI queries (also accessible as a web service) and you can write back data using web services. But only if the service is available! So if there is no service for it, you cannot automatically get data back into your SAAS application.



Now this machine where we build our customization on could be anywhere. It could be a local machine, you can rent it at a hosting company or rent is as a cloud service. Only in the latter case we actually speak of PAAS.

And if I have this PAAS environment, what do we still need to do?
You've got to have the tooling on it to build the customization! So let's assume we want to build some kind of fancy front-end, so we need ADF. We probably need a local database and we probably also need SOA Suite if we want to develop processes (although calling web services can be done in ADF as well of course).
So you always need a Database Cloud Service (DCS) and next to it you could use a JCS (Java Cloud Service) and install your own ADF/SOA Suite on it. Of course you would have to maintain the applications (keep them up to date with the versions you need, keep them running).
But you could also rent a SOA Cloud Service which would have the latest SOA version. This may be a good or a bad thing depending on what you want.
If the SOA Suite version changes, you may get into trouble with the services you've build to connect to SAAS of course, so you would have to keep track of each time it's changed underneath you.
Both methods have their advantages and drawbacks.

Of course to build the customizations you don't specifically need a PAAS environment, you could also use your own datacenter or hosted environment as you might do now. It depends on total cost of ownership eventually.

And WHAT can I build once I have my environment?
You can build custom screens containing custom logic, fetch data from your SAAS application, manipulate it and write back data. As said, writing back is a bit restricted, because a service MUST be available to be able to do that. Of course there are more and more services coming up, but we notice that a lot of the services still are missing certain elements (for example you can create a contract, but not risks and deliveries related to the contract).

So you can't actually change an existing form in SAAS, but you could copy it and rebuild it in your own application and skip the original form in the SAAS application. It's clear that would not be the reason why you bought the SAAS standard application in the first place ;-).
I would advice to restrict whatever you build next to SAAS is an addition, and not replacing functionality ..

Anyway .. as an application custom developer I see enough opportunity to be building customizations still for SAAS applications,  but I want to emphasize that PAAS is not the magic word that solves your problem. It's a fancy way of saying that you can build custom logic, forms, etc on an external environment (either in cloud PAAS or on premise/hosted environment).

:-)

Geen opmerkingen:

Een reactie posten

Opmerking: Alleen leden van deze blog kunnen een reactie posten.