Danny Kwok

There’s no box

Recent Posts

  • Electric Vehicle and Petrol Station

    As I was leaving the petrol station, I ponder over the moment where I may have the chance to use an Electric Vehicle (EV). What will happen to the petrol station? Can they be converted to Electric charging?

    This dilemma is a constant reminder of what change can bring. Though sustainability movement brings many benefits, there are awareness that we are never receptive to this change. Sustainability will bring about a disruptive nature to incumbent. There will also be high switching cost to consumers.

    Long Road

    Unlike all new technologies, sustainability is driven by the thought of a dying Earth. There are a lot of political and huge forces resisting this efforts. The most well known is perhaps the withdrawal from Paris Climate Agreement. It is very likely I will not see much drastic change in my lifetime. Of course, I do hope that the future generations can do better from the seed of sustainability.

  • Global TMS Localisation

    TMS (Transportation Management System) is a system that is specific to the local countries. It may be a challenge for many to solution this as a global system. However, the trick is to know which part to localise your global TMS. Here is a sneak preview on my cookbook to globalise your local TMS.

    • Your global TMS must be configurable to handle localisation.
    • There must be good TMS SME (subject matter expert) to guide the localisation.
    • TMS SME also act as key change agent to manage the localisation process.
    • Train local Champion in the business unit.
    • Outsource TMS solutions prudently and insource your localisation knowledge.
    • Localisation is more than system requirements, you must also understand cultures, habits and even local norms.

    Many organisations do not have a formal localisation teams. Do invest to train your resources on the importance of localisation. Often, these requirements are not stated and only surface during usage. Thus, an experienced implementer will consider localisation for TMS.

  • OTM Debugging

    Today, I had spend 4 hours troubleshooting OTM (Oracle Transport Management) only to realise that the mistake was due to a change of Service Provider ID. This change was not updated in the Rate Offering. As such, the shipment planning was not able to pick up the rates. It was a very silly mistake and also shows the challenge of debugging in OTM. Anyone doing OTM will know the power of OTM debugging. Here are some debugging tips which could help anyone still doing OTM!

    OTM Debugging Tips
    • Test often with each change of configuration. Use Agile to configure and test each change within a day.
    • Prepare a standard checklist for checking. This is important for Shipment Planning and rates setup.
    • Turn on your diagnostic log. It is more friendly than the log file.
    • Ask your OTM buddy for second opinion in your debugging approach. You may find new perspective.
    • Turn on your log files as last resort. The log file can either help you or discourage you. Go to the last page for the clues.

    If you still unable to find the issue, rollback the change and configure your change again. This time, configure and test more aggressively. The key to debugging OTM is patience and practice. The only way is to get your hands dirty.

  • Smart Coding

    Coding is not difficult to master if you are good at logic. However, how do you learn to code smarter than the rest of people? You can learn these tricks from my personal cookbook.

    1. The more you code, the shorter it gets.
    2. Simple logic works faster and more efficiently.
    3. Dare to rewrite and recode. Same rationale as point 1.
    4. If you find it hard to read, the computer will find it hard as well.
    5. Learn to understand the domain knowledge. This helps to select the right logic codes to fit task.
    6. If the decision making logic is more than 5 to 8. Consider to optimise it to reduce to 5.
    7. Speed is better than elegant codes. Users can feel the performance but cannot read how elegant is your coding.
    8. Know the cost of SQL. 1 long complex SQL is slower than few few simple ones.

    It is good habit to know the timing of your codes. With practice, you will be smart to code for performance and maintainability.

  • Why AMS is obsolete?

    If you want to know the details, you can go through the code.

    AMS

    Recently, I got a surprising comment from an AMS (Application Managed Support) vendor above. This really confirm my view that AMS will be obsolete in the emergence of DevOps. Luckily, our team have been less reliance on AMS and transitioning to DevOps model over the past few years. Therefore, there is totally no issue for our team to read the codes. However, such mindset is the reason why AMS will be replaced in the next few years.

    Paradigm Shift
    • There is little value add for organisations to support AMS with focus on clearing tickets and reduce SLA.
    • AMS objectives are outdated due to paradigm shift to Cloud and Agile.
    • There is no knowledge increase in AMS resources to achieve better Customer Experience (CX).
    • The values of AMS contradicts that of newer paradigms.
    The Replacements
    • AMS is gradually being replaced by either DevOps or Self Service Technologies (SST).
    • New experiential indicators are gaining popularity to measure user satisfaction.
    • It is more cost effective and efficient to replace than to retrain existing AMS.

    These reasons serve as constant reminders that new paradigm will always replace in favor of old. It helps to push us to seek long term skillset in preparation of this shift. Thus, we should not be contended in our comfort zone.

  • Why you should DevOps?

    Many years ago, I was astonished that development team and support team were separated in large organisations. Coming from smaller organisation, I often need to handle support after development and relate the pain points of support. In some cases, I add the support requirements to my development efforts to factor the changes encountered during support. Time have shown that DevOps are better in many aspects compared to traditional AMS (Application Managed Support).

    It is the support team issue!
    • Project duration is often short and development team usually code against known requirements and test cases.
    • For future risk and issues, development team tends to transition this to support team.
    • Support issues that require change is considered enhancement.
    • Data or user education are support team issues.
    Enhancement is development scope
    • Support team are measured by support ticket and SLA (Service Level Agreement).
    • Known issues are easily fixed and can meet meet SLA.
    • RCA (Root Cause Analysis) are only done upon requested and there is no incentive to resolve root cause for support team.
    • Resolution of root cause falls under enhancement and belongs to development scope.

    There is now a demand for DevOps as many organisations switch to Agile. The disconnect between development and support can now be resolved. However, this will comes at a steep cost as DevOps is more than development and support.

  • Is your Masterdata clean?

    A recent project reminded me of the real world scenario where masterdata is never clean. We are being told that the textbox is a free text and city can be a street, district or even province. Of course, this creates a challenging downstream impact for your data analytics.

    Masterdata POV (Point of View)
    • Decide the POV of masterdata. One system masterdata could be another system transactional data and vice versa.
    • Use a reference point and communicate a common language of masterdata.
    • Knowing your end game will decide what masterdata to be collected with a relevant POV.
    Tips to clean your masterdata
    • If more than 50% of your masterdata data needs cleansing, it is worthwhile to drop this masterdata,
    • Know what to clean and not to clean for the sake of cleaning.
    • A clean masterdata exhibits consistent patterns while an unclean one is a total chaos.
    • Know your domain well to clean effectively!

    Cleaning masterdata is a iterative process. You get better and resilient with practice. A good data sense is also advantageous. Good luck cleaning and may the force be with you!

  • Digital Transformation and Migration

    I find an interesting item while decluttering. This item reminds me of digital transformation and migration. So what have these two subjects have in common?

    Digital Transformation of Legacy System

    Digital Transformation comes at a much steeper cost if you have legacy system. The key consideration is what you should and able to transform. Although there are many consultants who can advise on the subject of digital transformation, very few can tell you what you can transform in relative to your existing legacy systems. This creates a dilemma of whether to starting afresh or maintaining your legacy systems. Inevitably, you will need to consider migration approach instead.

    Migration of legacy system

    The decision on migration of legacy system is typical of big organisations. However, this comes a huge risk which are common to all migration project i.e cost and duration. Do start with a simple checklist before you make this decision. They may increase the success rate and decrease the migration costs.

    • Do you own all the source codes or the capabilities of your legacy system?
    • Can the pilot migration be completed within 3 months?
    • Are you practicing Agile or DevOps approach?

    It is a simple checklist but difficult to achieve. Experience shows that duration is proportional to cost and greater success is achieved with quick deployment. In-house SME or Agile DevOps will ensure you can handle any migration constraints between legacy and your transformed system.

  • Agile TMS with DevOps

    Unknowingly, I have spend more than 5 years with TMS (Transportation Management System) using OTM (Oracle Transportation Management) system. Overall, I enjoy the ease of configuration to deploy Agile solution using technique of DevOps. The control of global TMS solution also create high degree of adaptability for the team.

    How to Agile your TMS
    • TMS have short transit window. It is favorable to adopt Agile.
    • Do design for change rather than design on sign-off requirements.
    • Configuration solution with custom plugins can cater for all TMS scenarios.
    • Determine your Agile components.
    When to DevOps
    • DevOps complement Agile approach. This suits TMS because TMS contains many exceptions in the real world.
    • Use DevOps to close your loop in Agile implementation.
    • Consider to include monitoring tools or reports and analyse your data to determine your solution effectiveness.
    • TMS is usually 20% localisation. You may choose to DevOps on these localisation.

    In summary, TMS needs a good product platform. You will also need to train your your TMS team to be Agile and DevOps ready.

  • OTM Object Locks

    OTM (Oracle Transportation Management) Object locks have been my nemesis lately. You can see my past battles with refactoring and code quality. In migration or upgrades, direct copy of old packages from old to new domain often do not work as expected. Of course, you will only realise it when you hit object locks.

    Signs of Object Locks
    • If you see very long PLSQL packages, it will mean the codes will take a while to travel from end to end. Any delay will lock object or tables giving the user a non responsive feel in the UI.
    • Many UPDATE SQL are seen in the agent or PLSQL.
    • Locks in Agent are used in Modified agent.
    • Copying of data from different objects like Shipment to OR (Order Release).
    Tips
    • Removal of PLSQL packages in Agent and DSU (Direct SQL Update) to bare minimal, especially Modified Agents.
    • Reduction of codes in PLSQL. Delete or comment out old codes.
    • Reduce your UPDATE to a single point.
    • Add exception handling in your PLSQL to allow graceful exit of your PLSQL.
    • Conduct unit testing to each Agent or procedures before enabling them. If in doubt, remove them.

    It is a painful process and huge amount of mandays are spend. Of course, lots of practice and hair tearing are done before you realise these tips. Hopefully, they are of help to those doing migration or upgrades of OTM.