Great Experience with NZeTA App

Many countries now require visitors from supposed-to-be visa-free countries to apply for ETA (Electronic Travel Authority) or similar scheme before entering the country.

ETA is easier to obtain as compared to the visa.  The former requires only online submission and the results would be made available within a short time, a few days max. However, filling up the form for the ETA – especially for the USA – may be quite daunting.  It is not difficult but simply time consuming.

Until I applied for ETA for New Zealand, NZeTA.  From 1 October 2019 New Zealand will require visitors from visa-free countries to obtain NZeTA prior to the travel.

The New Zealand Immigration provided two options to apply NZeTA: through web or mobile app.  Interestingly, it costs NZD 3 less to apply using the app as compared to the web.  Out of curiosity I chose to apply using the app.

Searching the on Google App Store (well, I am an Android user) app was easy.  The installation was a breeze without any issues.

The application process was surprisingly easy.  Upon opening the app, I was prompted with the welcome page.

Followed by acknowledgement for the usual privacy and term and use.

The next step caught me a bit off guard. It prompted me to take a picture of the passport.

However, rather than taking the picture of the whole passport, the app actually scanned the Machine-Readable Zone (MRZ) area. The screen would show a blue bar where you should align the MRZ. As a result, capturing the MRZ was a breeze!

The next step was quite interesting, it asked me to do selfie!

It took me a few attempts to do the selfie. Once completed, the app displayed the information captured from the MRZ, with the picture on the top-left corner. It asked me to confirm the details.

After that, the app asked a series of questions, starting from whether I want to stay in NZ or coming as a transit passenger, whether I am an Australian permanent resident, and so on. Interestingly, the ‘expected’ answer is always highlighted.

After answering all the questions, I proceeded to pay the ETA and the International Visitor Conservation and Tourism Levy (IVL). The payment was done using credit card and it was a fuzz free. I did not use the feature to take picture of the credit card – which I believe would help me to key-in the credit card details; I chose to key-in the card details myself. The only missing is there was no 2 FA for the credit card transaction.

And that’s it! The whole process was completed in less than 10 minutes, all from within the app itself. It was a great experience!

The app made it easy for anyone who applied for NZeTA. There was no need to upload any additional documents or pictures. The app also reduces or even eliminates error by using MRZ to fill up the details; no need for the applicant to type all the details manually.

The selfie is also interesting. There is no need for the applicant to rush to to instant photo booth or photo studio to take the picture, which would delay the whole application process.

The app practically eliminates all frictions in applying the NZeTA. It is a great innovation from The New Zealand Immigration. As a citizen, friction-less transactions such as what the app offered is the one I am looking for when transacting with the Government; and as a public servant such app is the yardstick for a good Government eServices.

Process and Customer Experience at Economic Rice Stall

One of places I usually go for lunch in the weekdays is the food court at the Esplanade Link.  It is only a short walk from Raffles City complex, it has variety of foods, the foods are generally good and the price is reasonable.

My favorite stall in that food court is the Economic Rice.  This stall always has the longest queue during lunch time; and yet people don’t mind to queue.  Despite the long queue, the queue is surprisingly fast, thanks to the way they serve the customers.

The stall is in the corner, in “L” shape, something similar to the image below.  There were usually four stall keepers manning the stall, other than perhaps another two or three at the back who do the cooking.  The queue started from the stall keeper in the corner, marked with ‘1’.

Capture.PNG

The stall keeper ‘1’ main responsibility was to ask the customer what he wants: whether he wants rice or porridge and whether he wants to eat the food at the food court or to ta bao (take away).  He then scooped the rice to the plate or a take away box.  He was responsible to scoop the first one or two side dishes that are closest to his area.

The 2nd stall keeper, marked as ‘2’ on the picture above, would then take over the dish.  The customer move dto the left and continue to order side dishes from the area closest to the 2nd stall keeper. Meanwhile, stall keeper ‘1’ took new order.

Once completed, stall keeper ‘2’ handed over the plate or takeaway box full with the food to the 3rd stall keeper, marked with ‘3’ on the picture.  In front of this stall keeper there were two big bowls, one with gravy and another one with curry.  Stall keeper ‘3’ main responsibility was to ask the customer whether he wants curry or gravy to be added to the dish. If the customer ordered porridge, stall keeper ‘3’ would scoop the porridge to the bowl. He then put the dish in front of the 4th stall keeper.

The last stall keeper, stall keeper ‘4’, marked with ‘4’ on the picture, was mainly responsible to handle the payment.  He was also in-charge to put the takeaway box in the plastic bag.  Customer would then leave the stall.

As illustrated above, each stall keeper in the stall had a very clear roles and responsibility; and they followed it to the dot.  There was also a coordination between stall keeper ‘1’ and stall keeper ‘2’; the moment the 2nd stall keeper was free, he would immediately take the plate/box from the stall keeper ‘1’.

Putting the curry and gravy in giant bowls was also a brilliant idea. Without those bowls, if the customer wanted curry or gravy, the dish needs to move back to stall keeper ‘1’ or ‘2’, disrupting the order from other customers.

All of the arrangement above resulted in an efficient queue.  The customers would have a great experience as they could get their meals fast.  The customers would then willing to queue despite the long queue.  The stall also benefits, it could get more income as they could serve more customers within the same period.

However, the stall owner might realized that the arrangement could be improved further. For example, not all customers would want extra gravy or curry.  The 3rd stall keeper was not as busy as his colleagues.

The 4th stall keeper, the cashier, was busy with money (the stall does not accept cashless payment), worse if the customer gave him a big note. For takeaway, he need to close the box, get one plastic bag and put the box[es] in the plastic bag.  This was slower than the speed the first three stall keepers in serving the customers, caused a delay.  It was uncommon to see three to four customers waiting to pay.

Today,  I came to Esplanade Link’s food court again and I noticed the layout of the stall changed a bit and I noticed the queue was even faster.

There was no change in roles and responsibilities for stall keeper ‘1’ and ‘2’; however once stall keeper ‘2’ completed the order, he would hand it over to the cashier, who occupied the space originally meant for the big bowls of curry and gravy.

Customers would make the payment.  The cashier did nothing but accept the payment.  If the customer did not want to get curry or gravy, he would simply pick the dish and leave. For customer who want extra curry or gravy, he simply moved to the left and then scoop the extra curry or gravy himself from the giant bowls.

Stall keeper ‘4’ was responsible to put the boxes to the plastic bag or to get the porridge.

This simple improvement, swapping the role of stall keeper ‘3’ and ‘4’, is brilliant.  It removed bunching at the cashier – when the cashier was busy putting the takeaway box[es] into the plastic bag, which slowed down the whole process.

Customers who eat in the food court and who don’t want to get curry/gravy could immediately pay their meals and go.  The queue for them was faster; other than there was no bunching issue, they also skipped the gravy/curry step in the previous process.

For customers who want extra curry or gravy, they could get the curry/gravy themselves.  As there was no bunching, they could get the food faster.

For takeaway customers, the experience may be the same as before, or perhaps slightly better because there was no bunching.

This small improvement does improve customers experience, simply because the queue moved faster and they could get the food faster.

I am not so sure whether there is a financial benefit, too.  However, as the queue moved faster, it would lead to shorter queue, which may attract more customers.

Whether the stall owner realized or not, he had improved the process and customer experience. He also showed that such activities could be done even by small business like his.  Huge Improvements could be achieved by simple (and looked trivial) changes, such as swapping the stall keepers.

</>

 

 

 

Embracing Messiness

One day I was asked to draw how the applications we have are interfacing with other applications. It was a quite big task to come out with such diagram, but I managed to do it.

The diagram looks like this.

Untitled

(of course, I need to remove the details)

When I presented the diagram, the most comments were about how messy the applications are.

I disagreed. Such messiness, in fact, should be EMBRACED.

Firstly, there is no application that can do all the functions that the organisation needs. An organisation typically uses different applications and integrate them at the back-end so that to achieve a good user experience across different applications.

When an organisation moves to the cloud, it opens up even more applications it can use. The integration between cloud-based applications (and also with Intranet-installed applications) would even be more pervasive.

With the advent of microservices and container, the integration would even more complex than typical application-to-application integration. A particular business function may be served by multiple microservices, each may call other microservices.

Microservices and container when combined with DevOps also introduces more complexity. If properly configured, a container can run in different hosting environment at different time, transparent to the user, but introducing a more (at least to what some people think of) another dimension of messiness (and complexity) as the service has no ‘permanent home’.

Trying to simplify the interfaces between applications would simply not work. What the organisation needs to do is to embrace such messiness with some measures to prevent chaos.

For a start, the organisation should put in place governance. The organisation should know what interfaces are being deployed, who is calling what, version, security, schema and which interfaces to be retired. This will also allow the organisation to better reuse existing interfaces, rather creating new ones.

However, governance itself is a rather tricky concept as may hinder application development. Governance implies set of rules that must be followed by developers otherwise there would be some kind of penalties. The scrum team may also see governance slowing down their works as they need to go through ‘review’ process. Some pragmatic approaches on governance needs to be applied.

The organisation may also consider to implement some systems, such as API Gateway or message queue to provide the layer of governance on interfaces. It also provides additional layer of security with the cost of additional complexity and reduced reliability as such systems may become a single-point of failure in the whole organisation.

Data governance is also important. An entity should have consistent data structure throughout organisation and across all applications. An inconsistency would simply create confusion, not only for users but also for integration. It would make interfaces more complex as application would need to transform the data to its own data structure. Intermediary systems such as API Gateway could used to do transformation; however it would simply move the complexity into such system and with more complex governance as there is a need to track the transformation logic.

</BH>

Two Lessons for DevSecOps from Grounding of 737-MAX

As an IT professional who is working DevSecOps and with strong interest in Aviation industry, I learnt some lessons from the grounding of 737-MAX series.

Automation is Essential but People Need to Know What Automation Does

The crash of ET302 and JT610 might be due to MCAS (Maneuvering Characteristics Augmentation System). The computer reads attitude of the plane and in certain situation it would intervene. It is meant to assist pilots and in ideal situation the pilots would not notice.

In DevSecOps, automation is essential; in fact without automation, it is not possible to achieve DevSecOps. Tools are used to achieve automation.

Use it right and in the hand of good engineers, the tools would do wonder. The DevSecOps would be able to deliver features, fixes, and updates frequently to deliver business values.

US Airway flight US1549 showed how a pilot, Capt. Sully, was able to utilise automation (in the form of auto pilot) to help him to steer the crippled plane before ditching on Hudson River.

In contrast, the computer on Air France flight AF447 provided warning to the pilots that the plane was stalling and approaching terra firma; however the pilots did not respond to the warning and only at last minute it figured out what happened, but it was too late.

In DevSecOps, it is common to mix different tools from different vendors. Each tool has its own strengths and the organisation may have its specific needs and constraints that dictate the tools used.

An engineer who is clue-less on the tools would make DevSecOps fail to deliver its value.

The engineer must be familiar with all of those tools. Using the tools everyday, however, does not make an engineer familiar with the tools; it was simply making the engineer as operator.

The engineer is expected to know how the tools work, how the tools interact to each others, how to exploit each individual tool, how to interpret the errors generated by the tools and how to fix the issues.

Not easy, but at least the engineer could quickly recover the tool-chain when there is/are error[s].

If an engineer is not familiar what each tool in tool-chain does, then he would not know what to do when something unexpected happened. In DevSecOps, it would simply created delays.

Unmanageable Technical Debt will Snowball to Bigger Problem in the Future

The Boeing 737-MAX is the latest variant of the venerable 737 series that started in the 60s. Throughout the years, Boeing kept improving the plane. It accommodate bigger engines, longer airframe (for bigger capacity), etc. It makes the plane still relevant, especially after Airbus rolled out A320s in the 80s.

However, what Boeing has been doing was simply continuously tweaking the plane. As the landing gears are not high, there is a limit on how big the engines 737 could use. Boeing has been tweaking the engine pylons so much that on 737-MAX the pilot needs to be assisted by the MCAS.

The Boeing 737 design has limited the changes that Boeing could do. It has become a technical debt but nothing was done.

Likewise in DevSecOps. While meeting the objective to deliver business values is very important, the technical debt also matters. Delaying addressing the technical debts would simply make the problem bigger and soon or later becomes unmanageable and affecting the business.

It is important for the organisation and DevSecOps team to allocate time and resources to address technical debt. It is either to be done in specific sprints/releases or inserted as part of releases.

Airbus and the Unlucky 8

Recently Airbus announced that it would stop the production of the largest airliner, the A380.  Despite its popularity with the passengers, the plane is unfortunately not popular to bean counters airlines executives.

The premature end of A380 productions (as compared to its rival, Boeing 747 series), also cap Airbus unlucky experience of using supposed-to-be lucky number of 8.

From A300 to A380

Both Airbus and Boeing have naming convention for its planes.  Airbus named its first model it produced, the A300.  Subsequently it named the model in multiply of 10: A310, A320, the A330 and A340 .

However, when Airbus announced the A380, it deliberately skipped A350, A360 and A370.  The number ‘8’ was chosen because it resembles the double-deck cross section – the A380 is the first airliner to have a full-length double-deck* – and it is considered as lucky number in Chinese numerology.

It is not uncommon for aircraft manufacturers to have different variants for the same model; different in range, capacity or generation.  For example, the 747 started as 747-100 and subsequent variant was named 747-200.  Airbus A330-200 is shorter (and has more range) than the A330-300.

The A380 has, in fact, two eights because the base (and only) variant of A380 is … 800.

Despite having two ‘8s’, the Airbus A380-800 – shortened as A388 – has not been having good sales.  Other than Emirates – which ordered half of A388s produced, no other airlines acquired the A388s in large number. The A380 programme was doomed.

Alas, Airbus continues to have problem with number 8.

Among other models Airbus is currently producing, A350 is its largest twin-engine wide-body airliner.  It has at least 3 variants, A350-900, A350-900ULR and A350-1000; with -900 has the shorter frame (and lower passenger capacity) as compared to A350-1000.  However, the A350-900 was not planned as the smallest variant.

Airbus planned to ‘shrink’ the -900 to even shorter frame (and with less passengers count) and name it A350-800.  It was meant to serve thinner route while maintaining commonality with its larger cousins. However, the shrink made the variant noncompetitive; so the -800 variant was a stillborn.

Airbus unlucky experience with ‘8’ does not stop here.  It recently launched the re-engined variant of its popular A330 model, called A330NEO (New Engine Option).  It has two variants, A330-800 and A330-900; with the former is having shorter frame (and longer range) than the later.

However, the -800 model has not been popular. Airbus has received order for only 8 A338 from one airline, Kuwait Airlines; as opposed to 231 orders for the A330-900 variant. It is unlikely for A338 variant to have large orders, considering that the -900 variant is as capable as -800 and the entire A330NEO line is facing stiff competition from Boeing 787s.

Boeing has a better experience with number 8.

Even though its latest variant of 747, the 747-8, is not selling well (with only 154 orders), the saving grace for Boeing is it spent a modest amount to develop B747-8 as it was a modification from earlier model, 747-400.   Boeing also could claim that nothing could dethrone the ‘queen of the skies’ as it will still be producing 747-8 – with current backlog and production rate – will still be produced when the last A380 leaves Airbus production line.

While the 747-8 is not considered successful, Boeing has a better experience with number 8 with its latest twin-engine wide-body model, the 787.  This model has been a runway success, clocking more than 1,400 orders. Its smallest variant, 787-8 has similarity to A388, it has a ‘double-eight’. However the similarity ends there as airlines ordered 444 B787-8s, well better than 251 orders for the A380s.

So, number 8 may not be a lucky number for everyone!

 

* Technically the A380 has 3 decks; however the passengers would see only the main deck and upper deck. The lower deck is used for cargo or crew rest area.