Tag: DevOps

2022 Clouded Space

~ Danny Kwok ~ 1 Comment

2022 will see a year of COVID normalisation. Similarly, the “clouded” space will see emergence of key players. Every organisations are expected to deploy application in at least 3 major cloud platforms aka multicloud. By then, teams are expected to be equipped with cloud skills that are generic across different cloud platforms. The clouded space will continue to increase during 2022 as major software shifted to cloud.

Cloud Transformation

You will soon see that digital transformation will be changed to cloud transformation. The stabilisation of COVID pandemic will give rise to future cloud transformation that will work well across geographical locations. The increased usage of cloud creates demand for skills that can adapt and transform applications to cloud based platform.

Agile Applications

Applications time to market will continue to be DevOps and Agile. The redesign of AMS (Application Managed Support) towards DevOps will continue throughout 2022. Organisations will continue to invest for in-house capabilities and obtain the optimum Agile application and team. We will expect to see continuous struggle to eliminate traditional project managment approach in favor for Agile methods.

In 2022, it is near impossible to escape from the “clouded” space. Cloud transformation is expected to dominate with increasing usage of in-house generic cloud architect. We will continue the battle for full Agile approach to align with cloud capabilities.

Advertisement

No Downtime Approach

~ Danny Kwok ~ Leave a comment

Application downtime is getting lesser and lesser with Cloud computing. Users are more demanding without the need of downtime. Thus, we need to move to the approach of hotfix and high availability environment.

Picture by Ethan
Shift to Zero Downtime

The design of zero downtime will require a digital transformation approach to your entire architecture. Another consideration is utilisation of the Cloud platform for different high availability approach. As this approach will incur additional cost like licences, you may want to evaluate a switch to pay as your use model instead of fixed licensing.

Development with No Downtime

Another key change is your development approach. This must be changed to reflect deployment with no downtime. Instead, hotfix and patches must be applied seamlessly without any downtime or impact to user operations. Therefore, your development will need Agile and DevOps to enable this approach.

If you have intention to move to a services with no downtime, it is time to reform your architecture and development approach. This involves utilisation of Cloud platform and Agile development to achieve this vision.

Is there a need of Hypercare for Agile SDLC?

~ Danny Kwok ~ Leave a comment

Hypercare is a process in Waterfall SDLC (Software Development Lifecycle). It is very similar postcare you receive after a major operation. For many teams who makes the switch from Waterfall to Agile, management still demand the need of hypercare process. Is there really a need for hypercare for Agile SDLC?

Hypercare is Just a Sprint?

Hypercare is often regard as a warranty period whereby traditional waterfall all accommodate a degree of big fix due to scope creep. In Agile, there is no such process. Instead, the deviation. or gaps are recorded in the backlog. The backlog items may be selected for the next sprint. This render hypercare unnecessary in Agile. Effectively, management or users become concern for this missing warranty! Thus, you may find some Agile project do state a period of hypercare. However, this is actually the same as a sprint.

The Emergence of DevOps

Another key reason that hypercare is unnecessary is due to the rising popularity of DevOps. In fact, DevOps functions like a hypercare process with its quick turnaround, speed and rapid delivery. Agile and DevOps works hand in hand and you may consider DevOps in place of hypercare period. Therefore, your users and management will have a similar assurance that is given in the form of hypercare.

It is noteworthy that hypercare may no longer be required in the Agile and DevOps world. There is a need to educate and align users and management on these understanding. This may also include the change in future RFQ or procurement whereby hypercare could be removed. As a result, you will see a lower cost with the removal of hypercare process.

Why AMS is obsolete?

~ Danny Kwok ~ Leave a comment

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?

~ Danny Kwok ~ Leave a comment

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.

Digital Transformation and Migration

~ Danny Kwok ~ Leave a comment

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

~ Danny Kwok ~ Leave a comment

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.

AMS vs DevOps – Month End Closing

~ Danny Kwok ~ Leave a comment

It is month end closing! The first day of the month is usually the financial closing month as well. From a system view, there is always a heavy server load from last minute orders or batch job running monthly. This usually cause a whole lot of recurrent issues. I will do a quick comparison on how AMS (Application Managed Support) and DevOps view this standard issue.

AMS (Application Managed Support)
  • AMS will wait for issues to occur and await instructions to react and rectify the issue.
  • More support tickets will mean more job done.
  • The issue are addressed at face value. There will not be RCA (Root Cause Analysis) unless requested.
  • AMS resolve symptoms to ensure low severity and faster SLA
  • AMS are measured by SLA from support ticket. It is usually worthwhile to repeat same ticket type as response time will be fast due to known issues.
DevOps
  • Problems and risks are mitigated with business and system development knowledge.
  • Zero support tickets is the key objective to system stability.
  • DevOps conduct RCA for all issues and proposed enhancements or BPR (Business Process Re-engineering) resolve the root cause.
  • DevOps adopt short term and long term fix to prevent further recurring issues.
  • DevOps can be measured by low support tickets and positive Customer Experience (CX).

From the comparison, you can see the obvious benefits of transforming your AMS to DevOps. However, there is a reality that DevOps are much costly than AMS. So, which approach should you be going for?

Agile Exit Plan or DevOps

~ Danny Kwok ~ 1 Comment

When you are doing Agile, you naturally gain a new skillset on exit planning. This is due to the time box that is set for your changes. Waterfall favor extensive test coverage, testing and sign off. On the other hand, Agile focus more on code quality, speed with CI/CD (Continuous Integration/ Continuous Delivery) methods. In another words, you formulate your exit plan while building for Agile. This is also commonly known as rollback plan.

In recent times, this is rename as DevOps that function in similar manner. In my team, I always emphasis End to End knowledge i.e DevOps and a need for Agile Exit Plan. Here are some ways of building your Agile Exit Plan while moving towards DevOps.

  • Good Agile deployment must have resilience way to monitor and rollback your codes.
  • Data integrity is a majority of deployment errors. Cultivate good code quality with exception handling.
  • Train SME (Subject Matter Expert) who can provide good advice on exit plan for each Agile deployment.
  • Develop 80/20 rule for your Exit Plan. Factor 20% as exception and focus your resources on the 80.
  • If you do not have CI/CD, consider a feature toggle approach or canary testing in your Agile deployment.

It takes years of practice to master Exit Plan with waterfall approach. However, Agile is so intense that you can hone your skills within a year or two. If you are also handling Production like me, you are DevOps before you realise it.