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.

Composability 101

Composability is an interesting term I came across in this article. It will redefine how teams are structured and managed in organisations. In summary, composability is a design principle to view the interaction between different systems. Organisations must move towards highly composable architecture to satisfy continuous user needs. Basically, it is how you are able mix and match your components together with ease.

Being Composable

The shift to composability is not new. Web services or SOA (Service oriented architecture) are earlier design of composability. The push to be highly composable is triggered by COVID-19 pandemic to be resilient and adaptive to business requirements. Unlike SOA, composability aims to be modular yet stateless. It is the vision to fully plug and play with quick and minimal cost.

Composable Technologies

Cloud platform is the best example of Composable technologies. You can quickly deploy and configure different architectural model within a short time frame. Different services can also integrate quickly using REST API. These technologies disrupts the traditional way of implementation business requirements. You will need to utilise Composable technologies to accelerate your collaboration and system delivery.

Organisations are now digitally transforming to composability mindset. The typical approach is to migrate to Cloud. Teams will be formed to be Composable and Agile. The ability to react will be the future way on how we develop our technologies as enabled to business needs.

PoLP 101

Over the years, it was still interesting to note that humans seek greater power. In software applications, they usually request more access rights and configuration control. Requests like this often becomes a topic for audit and security team. This is because the principle of least privilege (PoLP) is being practiced in many organisations.

Why PoLP?

The key advantage for PoLP is the limited access granted to user to perform the required functions. This restrict data exposure and interventions to the system. Roles, security groups and policies are some of the key Cloud concepts created for the purpose of PoLP. By default, many cloud services are PoLP in nature.

Security Strategy

PoLP remains a major security strategy for applications and infrastructure in Cloud. The idea is to prevent security breach if any of the user account is compromised. Root account and admin role are restricted. Cloud objects are also not set to public by default. Typical security measures are to expose the required layers to the public Internet. Other prevention includes limiting the number of privileged user roles and user accounts.

PoLP is a key approach for security in major cloud platform. There is ongoing debate that PoLP creates a hassle for development. For the time being, you need to continue to educate users on the importance of PoLP.

CORS 101

CORS (Cross-Origin Resource Sharing) configuration will be a standard feature in many Cloud products. Most of the online applications required embedded links or AJAX calls in their web pages. By default, CORS is mainly blocked unless you enabled it. It is one of the most headache issue if you are deploying loosely coupled architecture. This are some common things that you need to take note for CORS.

Using CORS

Common CORS implementation involves REST API calls, embedded iFrames, cross linking of services or sharing of data like location, scripts and stylesheets. CORS is necessary because you will be sharing data like location for your application. Sometimes, there is a need to subscribe to cloud services using REST API. Majority of modern applications utilise REST API calls or AJAX. Thus, CORS is one of the most common security issues to encounter during implementation.

Enabling CORS

The CORS implementation can happen at a few layers. These are the common issues that you can check if you run into CORS errors. You will need to enable CORS if you are doing these implementations. The areas that you must check and enable CORS are usually browser and application. Luckily, many modern browsers are now CORS friendly.

If you are new to web or cloud development, one of the earliest security lessons will be CORS. Browsers are now attuned to CORS unless in the past. Many cloud setup or REST also include CORS in their configuration. Do take note to enable CORS carefully to allow your application to run smoothly.