Why I Need a Cloud Platform

It is my third year of having a cloud platform. Year 1 happened due to major project. Year 2 was exploratory and I started to use simple features like object storage. It was only on the third year that I managed to explore and build an entire cloud architecture. There is no turning back because Cloud platform has provided me freedom to Agile and configured applications quickly. These is a reflection on why I need a Cloud Platform.

Self Service

The reality of self service finally reached the IT community. That self service comes in a Cloud Platform. As product owner, we usually need a box in the past to initiate any new product features. Such request takes a long time from procurement to deployment of the application module. All these efforts can now be self service at a cloud platform. You can quickly spin up a compute within minutes. You can even setup entire eCommerce architecture in a cloud platform.

Finally Agile

Another favourite advantage in having a cloud platform is to be fully agile. I am no longer constrained by dependencies like network, computes or storage. These are now easily available with cloud platform. In another words, you can agile innovations with high uncertainty. You can also RAD (Rapid Application Development) or DevOps your changes because cloud is configurable.

The freedom of being agile and ability to self service are key reasons on why I will continue to need a cloud platform. If is also rare to find organisations that are still on-premise. I am excited that the next years will be spend to migrate the needed to cloud platform one way or another!


The standard REST methods in ORDS (Oracle REST Data Services) are GET, POST, PUT and DELETE. We usually started testing REST with GET because it is usually the easiest for SELECT statement. POST will be next for INSERT for new creation. The complex PUT will be the last for any UPDATE process. DELETE is seldom provided to preserve data integrity. So, why should you leave PUT to the last? This is because no modification process often requires exception flow and handling.

Photo by Ethan
Handling PUT

You should relate PUT to modification process. REST does not have constraints to modify data unless you add the conditions. There are two approaches to handle PUT. One way is the trigger that will allow user to modify the data. Audit trail should be handled at source and/or target application if you want to keep track of the changes. Another way is to set conditions in your PUT services to prevent unauthorised modification.

PUT Response

A key characteristic of PUT is primary key (PK). You will need the PK to amend the correct data. So, what happens if PUT cannot find the PK? There are two ways to handle the PUT response.

  1. You can give a valid response or 201 status if PUT is successful.
  2. You can choose to INSERT if PK cannot be found.

PUT is the last and most complex REST service that you may want to expose. Handling PUT and its responses will need careful consideration on how you want to manage data modification. In some cases, you may choose to omit PUT service to preserve data integrity like DELETE.

Troubleshooting APEX REST Synchronisation

Oracle APEX REST can be a pain if it is not working as expected. Today was the day we delved deeper to REST to why data source is not synchronised to the target table. It was another day of hair pulling and lots of testing to figure out how synchronisation should be working for APEX.

Synchronisation is One Way

There is a misconception that synchronisation will keep the target table to be similar with the local table. This is the mindset we have while troubleshooting. However, we finally realise that the synchronisation is to local table and not vice versa. You should not change the local table and expect it to be synch back to your target table. The synchronisation type also shows that it is one way with 3 types – Append, Merge and Replace.

Design for Two Way

The synchronisation approach could mean that the local table should not be used as a transactional table. This will mean that you need to design your application for a two way data transfer between your local table and target table. One method is to direct REST POST to your target table and let APEX auto synch to your local table. Another method is to separate your transactions to be different from your local table. However, we will need to test this approaches in details.

Synchronisation can be straightforward if this is a direct table processing. If there are conditional logic and preprocessing, you will hit synchronisation issues. This is because of the one way synch from target table to your local table. So, it is back to drawing board for design of two way synch.

REST in Peace

Recently, we are exploring a lot of REST API. Although REST is quick and simple, there are challenges to take note while using it. This is because we are used to field types such as date. There are also things to take note while handling the different REST methods like GET or POST.

When REST don’t work!

REST services can be challenging to troubleshoot when it’s not working. One of my favorite tool is Postman. This allows you to test REST endpoints quickly. The most common errors of REST endpoints encountered in Postman are firewall, parameters and typos. Half the battle is won if you can get your REST working in Postman.

The Other Part of REST

If your REST is working in Postman but not working in your application. Then, this part of issues likely lies in your application configuration for REST. The way to troubleshoot can be broken into the following parts.

  • Setup of REST endpoints
  • Configure then right parameters
  • Unit test of REST methods
  • Check your logs

The failure points for REST can be a real test for your patience. You will need to trace each steps of the REST methods. This will help you determine the root cause. Most of time, errors are due to configuration, parameters or typos. Stay strong and hang in there!

Why PM is Outdated

In the world of Agile, there is no PM (Project Manager) role. I have questioned on the relevance of PM in Agile project. With Agile gaining grounds, it is time to determine that PM role is outdated. These are reasons why you can run your Agile project without PM. To be specific, it is time to put a stop to freeloaders working as PM for Agile projects.

Why Agile Obsolete PM

In waterfall project, PM is required to work on project management e.g. schedule, scope. There is a lot of trackers to track schedule, gaps or issue logs. In contrast, Agile focus on self empowerment and self organising. There is no need for PM in this framework based on this key principles. You will not need a PM to chase or track after deliverables. As an analogy, waterfall is like a baby with constant minding from the guardian. Agile places the collective accountability to the Agile team.

Adaptability Outpace PM

A PM mainly function like an observer to the project. Monitoring and tracking does not provide the adaptability required by Agile. Often, PM is outpaced by Agile team. The additional communication layer of PM becomes redundant. Users or customers can work in close collaboration with Agile team. This is a key reason why Agile do not require PM. If you are running an Agile project, do expect to be frustrated by the placement of the PM.

It is time to realise that you no longer require PM for Agile projects. We should not continue to be in self denial mode to have this role for historical reasons. Agile team is highly independent to get things done and adapt quickly with users or customers.

P.S. Self declared PM continued to exist during digital transformation period. It is time to wake up and transform PM role as well!

REST and Dates Type

Database field types like numbers or dates are no longer relevant for REST services. This is because REST transmission are often in text format. Thus, you will need to consider your database design while handling REST. Should you choose a date type or retain string format for REST?

Selecting the Field Type

The key factor to select the field type is how your applications will consume the information. By default, setting data for REST endpoints in string is fast and simple. Applications often use these like staging table. Thus, your initial design should often default the data types to string for easier processing. This also allows you to consume the data without worrying about the data format. However, there are scenarios where your applications will require a specific field type to utilise feature like date and calendar.

Field Type as Data Integrity

The issue with setting string type will mean you can consume all kinds of junk data. This could be costly if you do not enable any source system do not enforce any field definition checks. Thus, field type helps to determine what type of data you will be expecting. This helps to reduce and reject data that do not conform to your field type. As this is stricter, you will required mapping checks between source and target systems of the REST endpoints.

Many applications are new to REST and the usage of field types. Such example are dates where the you may debate to use date type of retain it as string. The selection you must take will depends on your applications or the efficiency of the REST endpoints.

Language Pack vs Translation Service

Many Cloud service have provided language pack and translation service options in their product offerings. I managed to test both of this in ODA (Oracle Digital Assistant) Chatbot. It is ideal that translation service be used as this simplify the maintenance and need for language packs. In reality, languages are complex and on the fly translation often turn to gibberish.

Why Language Packs?

These are the reasons why you still need language packs for your key texts.

  • Accurate translated texts.
  • Avoid ambiguity in translation.
  • Support acronyms and puns.
  • Able to translate industry terms correctly.
  • Faster translation for fixed text.
Why Translation Service?

In Chatbot, translation service is a must-have beside language packs. Other type of application may not need translation service. Will translation service obsolete language pack? These are some reasons why you must enable your translation service.

  • Helps to increase language type coverage.
  • Prevent unnecessary setup.
  • Aid Chatbot which allows NLP (Natural Language Process)

For the moment, it seems you have to support both language packs and translation service. Language packs are more accurate but cannot cater to unknown wordings like translation service.

ORDS vs Standard REST

Many applications are providing a standard set of REST API. Thus, you may wonder if you will still need to setup ORDS (Oracle REST Data Services). This is a quick summary on why you will need ORDS to extend the capabilities from standard REST.

Why you need to enable ORDS?

The key reason to enable ORDS is enhance what your current application can provide. Standard REST API usually provide a common information at a product level. This will mean that you may need multiple REST or additional function to get your desired datasets. In contrast, ORDS allows you to customise what you need with a single REST service. This suits high volume and reduce overheads from standard REST API.

Why stick to standard REST?

ORDS should only be used if the standard REST API cannot cater to your requirements. The good part of using standard REST API is to facilitate upgrading and lower maintenance for future. This is because these are seamlessly handled by the upgraded system. If you do not have specialised team to handle ORDS, you should stick to standard REST instead.

There are pros and cons to use ORDS instead of standard REST points. You should evaluate the setup against the user requirements. In most cases, ORDS can handle more than the standard REST.

Security Review Checklist

Security review is a plan that will be needed for many Cloud deployment. Currently, many security review are paper in nature and lack clarity on the security requirements for many organisations. It should be a standardised process to be conducted for all applications. A checklist is one way that can be provided for developers. Template use cases can also be given to speed up the review process. Two common security to take note in your checklist is infrastructure and application.

Infrastructure Security

Infrastructure security leverage on PoLP (principles of least privilege) as the guideline in the design. They are usually configured at infrastructure objects for cloud platform. These are the common checkpoints you can take note.

  • Secure all root and administrative access to authorised users.
  • Ensure network subnets are segregated from public Internet access.
  • Ensure that your applications and services are segregated with the right security policies.
  • Ensure you have the appropriate user roles and security groups.
  • Implement services to detect, protect and mitigate against threats like DDoS attacks.
  • Data or network traffic must be encrypted.
Application Security

Application Security are setup or built within the application. Your checklist must include the following key points.

  • Authentication must be setup to prevent malicious access.
  • Authorisation must be enabled at functions or data level.
  • Application must protect against SQL injection.
  • Cross-side scripting must be disabled.
  • CORS must be secured and used with cautious.

The above are standard checklist that can help you kickstart or speed up your security review process. It is important to develop your application with security requirements and not fix security at the last moment.

PMO for Agile?

PMO (Project Management Office) will be facing a dilemma soon. This is because many of the standards from PMO derives from waterfall model. As organisations shift towards Agile for project implementation, can we transform these PMO for Agile approach? This is one area that digital transformation can consider!

Photo by Ethan
PMO Relevance

Like all trends, project methodology moves towards Agile as mobile apps and Cloud become prevalent. PMO functions as “enforcer” or standards for standards like PMP or PRINCE2. It also serves to facilitate, support or even control project implementation. Relative to Agile, this is like a scrum master role! Does this means that PMO is no longer relevant with rise of Agile? Should PMO be transformed to scrum master roles?

Transforming PMO

For starters, I will advocate the transformation of PMO as scrum master if your organisation is going to adopt Agile as the main project approach. There will be a gap in project alignment when you are transitioning from waterfall to Agile. Rather than digital transformation, I will deem it as a project transformation journey. The new scrum master (formerly PMO) should be in charge of guiding the project transformation to Agile.

The adoption of Agile become stronger and stronger as organisations require speed and adaptability for projects. PMO will no longer be relevant because of these digital transformation. Thus, project transformation should be driven by the transformed PMO (scrum master). By now, you will realise that digital transformation involves the need for PMO to transform for Agile.