Tag: Cloud

Software Transition Phase for Cloud

~ Danny Kwok ~ 1 Comment

During digital transformation, transition phase from legacy to cloud platform will be necessary when you are having complex web of tightly coupled applications. These are the symptoms where you need to consider transition steps before moving to your final To-Be state.

Data Flow Diagnostic

Data flow diagnostic will reveal a history of changes that have created data inconsistencies across integrated applications. You need to do a data flow analysis to understand the data sources and output. It is important to note that there will existing discrepancies in how data flow from your application to others. This is a key sign that you must correct these flow before migration to Cloud. If you choose to migrate the same data flow, you will definitely encounter the need to customise your cloud architecture to handle the legacy data flows.

Fog of War

Another need for transition phase occurs when you encounter “fog of war” between applications. This happens when application have no idea on what the data are being translated or used. This uncertainty creates a high risk if you are going to migrate directly to cloud. It is worth to invest a transition phase for risk mitigation and discovery of the unknown scope.

There two key symptoms listed in a complex coupled application environment are candidates for a transition phase in your migration to cloud. The transition phase will help to correct legacy design and gain clarity in your final cloud objective.

Cloud Expectations

~ Danny Kwok ~ Leave a comment

Cloud expectations is a requirement that is often missed out. Unlike on premise, we often forgotten that Cloud is a product with constraints. Before you embark on a major cloud migration, it is recommended that you conducted a review of your existing architecture and expectations.

Understanding your Customisation

The common challenge with Cloud migration is customisation of existing on premise product. These customisation are often lost in translation over the years for legacy reason. Some of these customisation would even be uncovered during the cloud migration. Thus, it is important to do a deep analysis of your customisation. One guideline is called CEMLI (Configuration, Extension, Modification, Localization, and Integration) framework by Oracle.

Prepare your Cloud Expectations

Cloud expectations requirement must be translated to your critical success factors. These expectations will determine the effectiveness of your cloud migration. It is common to realise these expectations are missing. The user expectations will also mitigate the risks from Cloud migration. One such cloud expectation will be business continuity and minimum disruptions to operation.

There is a relationship of customisation and cloud expectations. Cloud is a product and will have larger gap for heavily customised on premise application. Thus, you will need to set clear cloud expectations to mitigate these risks. One common way is removal of customisation in preparation for cloud migration.

Pay as You Use

~ Danny Kwok ~ 3 Comments

Pay as you use will be the most common costing model as applications are moving to Cloud. This is changing the entire financial view towards applications. It is the most cost efficient and sustainable model as organisation will spend on actual consumption of IT resources. For business, this will provide better margin for their product offerings.

Why Switch?

Pay as you use allows you to leverage on costing based on actual consumptions. This helps to reduce idling time in your applications. Allocations of resources can also be sized to the seasonal period. Such model are widely used for electrical utilities or mobile usage. This concept applies to Cloud where specific data consumptions can be measured and charged accordingly. Thus, this model will impact on how organisations should pass the cost savings to consumers.

The Challenges

Although cloud providers are billing in consumptions metrics, it is not straightforward to translate these to applications usage. You will need to review your architecture framework from a costing perspective. Subsequently, this translates to a change for your existing financial view on how IT is being procured, charged and allocated.

Pay as you use model will continue to effect the changes to the financial view for IT. Business will continue to demand on how these cost savings should provide value for their product offerings. Therefore, we must design the entire product lifecycle around this costing model.

IT Outsource to Co-Sourcing

~ Danny Kwok ~ Leave a comment

Outsourcing will be on the decline as Cloud architecture grows with adoption. Many organisations are now turning to co-sourcing model because Cloud allows you to self service very quickly with configuration. This allows you to Agile quickly and adapt to different business needs. So, how should organisation make the switch to co-sourcing?

Recalibrate your Team

The first step to co-sourcing is to recalibrate your team skillset. This means your team will need to start to utilise their technical skills. A good start is to take on some enhancements changes internally instead of outsourcing to vendors. However, there are some teammates or management who cannot make the switch to this model. You will need to make the hard choice to rotate your team for co-sourcing inclined resources.

Co-sourcing with Vendors

The next step is to leverage your vendors for co-sourcing needs. You will also need to communicate to vendors your co-sourcing objectives. Both parties must build on mutual trust and work towards open knowledge and transfer of skillset. There is a misconception that co-sourcing will lead to a decrease of business for vendors. On the contrary, business will increase as more innovations can be implemented.

IT Co-sourcing is expected to overtake or even replace existing outsource model. There are two key steps to convert your organisation to co-sourcing. First, you need to recalibrate your team to build on technical skills. Then, you must communicate to your vendors for this vision and work mutually to achieve this model.

Multicloud Managment

~ Danny Kwok ~ 1 Comment

Multicloud management is becoming a challenge when you are trying to tabulate your overall TCO (total cost of ownership). You will also require a broad set of cloud skillset across different cloud providers. Most organisations will adopt multicloud due to migration of legacy systems to cloud. Another reasons are the strengths of each cloud providers. How should you prepare towards multicloud management?

Cross Functional Cloud Team

Cloud providers have a common dictionary and concepts. You should start to develop your resources to acquire a general cloud skillset. It is also time that you build a cross functional team for managing your cloud assets across different providers. The team must be adept to tabulate and normalise cloud consumptions across different platform. This team will also assist in best Cloud practices. However, the team is not to be a replacement of COE (Center of Excellence). Many organisations refer this team as a Digital Transformation team.

Multicloud Vision

As legacy migrate to cloud, it is estimated that your future applications should be cloud in 5 years time. Thus, it is time to formulate multicloud strategies and vision for your organisation. The vision will steer your multicloud managment into these approaches:

  • Centralised Multicloud will seek to view all your cloud usage in a single view and manage from a control tower vision.
  • Regional Multicloud approach leverage cloud providers selection and consumptions at a regional levels due to timezone and locations.
  • Applications Centric approach builds from transition of on premise application to Cloud.

Multicloud Management will be replacing traditional IT management as the migration of cloud is underway. It is time for organisations to transition your management to multicloud management instead than retaining your existing team structures around your traditional IT architecture.

Configuring Software Product 101

~ Danny Kwok ~ Leave a comment

Configuring software product is the key trend and reason of moving to Cloud. Some key characteristics of configuration approach are real time changes, hotfix and self service features. Many traditional project manager have misalignment to apply development methods for configuration model. If you are one of them and new to configuration approach, you may find these tips useful.

Digital Transform Mindset

Digital transformation is a main component for configuration model. Many will think digital transformation is about application changes. In reality, this is transformation of your mindset to a configuration approach. You should be inclined to review products that are highly flexible and configurable instead of turnkey method. This is a commonly seen in many local offices where stakeholders try to engage local solutions to solve a global problem.

Tips for Configuration Project

If you are new to configuration project, you will likely need to adapt these few tips.

  • Configuration suits Agile.
  • Cloud allows configuration at various levels like infrastructure, applications or services.
  • Train insource SME (subject matter expert).
  • Organise your teams for configuration capabilities.
  • Engage management support to adopt configuration platforms.

The constant market changes and COVID-19 is spurring the configuration market. Many resources and education stay entrenched in software development practices. It is time you switch your mindset and embrace configuration practices. This way, you can stay relevance and adaptive.

Serverless 101

~ Danny Kwok ~ Leave a comment

Traditional architecture always involve the setup of a server for applications usage. Cloud architecture changes this dynamic with the introduction of Serverless mod. This is also driven by the popularity of REST API where you can sell services with these API calls. So, what is Serverless? Is it time to make the switch?

No More Servers

Serverless is a godsend for application developers. This is because traditional architecture always involve the headache of server setup and maintenance. How much capacity will be needed? What is the running cost and setup time? Is it time to upgrade the server? Serverless eliminates all these headaches as the cloud providers will handle the hardware layers. The developers will only need to deploy the applications or functions.

Use and Pay

Another push factor to switch to serverless is cost. Serverless allows metering and you pay for your usage. Thus, this remove idle servers for your legacy applications. You also do not need to worry of infrastructure downtime as Cloud provides HA (high availability) with serverless. There is also no more running and maintenance cost with servers.

Serverless let developers focus on logic instead worrying of the infrastructure setup. Most cloud providers supports common languages like Java, Python, Nodejs or PHP. You all also gain further cost reduction by removing the servers requirements and maintenance.

REST 101

~ Danny Kwok ~ 2 Comments

REST (Representational state transfer) is going to be the standard for logistics in future. I view it as a big improvement over web services or SOAP. It is quick and simple to setup and let systems connect easily. Information can also be exchanged without complex setup.

Why REST?

REST had solved a majority of issues from web services with standardisation. The payload exchange format can be rendered easily with HTML, XML or JSON. It uses common http protocol like GET, POST, PUT and DELETE. The best part of connection is its statelessness as in http protocol. This means you do not need to worry or keep track of your connection.

When to REST?

Majority of cloud platform and applications are REST ready. You will need to consider migration of your legacy connection for REST endpoints. With this change, you will often reduce the reliance of ETL tools required by older applications. You will also find that you can scale with Cloud easily with REST.

Generally, cloud architecture are REST capable and ready. You will find that you can communicate easily from on premise to cloud using REST. Therefore, you should upgrade your application with REST capabilities to create your networked system with your partners.

OTM On Premise 6.5.x

~ Danny Kwok ~ 1 Comment

OTM (Oracle Transportation Management) last version for on premise is 6.4.3 since 2017. Many are encouraged to move to OTM Cloud as Oracle had stated there will not new version. Fast forward to 2021, there is a new update to the on premise approach. To my surprise, Oracle announce that there will be further patches to extend the life of on premise from 6.4.3 to 6.5.x till 6.5.3.

Source: OTMSIG Channel
Good News?

The surprise turnaround from Oracle is good news because many customers are unable to move to Cloud on time. This is not surprising as Cloud platform was faced with risk and uncertainty 3 years ago. Many struggle to migrate without a clear picture of OTM Cloud as it becomes a huge black box of PaaS (Platform as a Service).

OTM Cloud remains Innovation Platform

Those with OTM on prem will still be faced with a decision to move to OTM Cloud. The message from Oracle is that OTM Cloud will remain their innovation platform. It seem that we are unlikely to see much changes for on prem version for 6.5.x except for patches and minor enhancements.

In summary, the extension to 6.5.x will give many customers more time to migrate on premise to OTM Cloud. This is a big relief because migration to OTM Cloud is not just a technical change but a digital transformation strategy.

Cloud Dictionary

~ Danny Kwok ~ 1 Comment

The world of Cloud is merging to a common language. This is because different cloud providers are coopetitors to offer compatibility across their cloud. One of the market leader are setting many of their terms in the dictionary. These are some common cloud terms you will find useful.

Most Common Cloud Terms

Some of the common cloud terms are listed for quick references:

  • Bucket – Cloud storage or your hard disk equivalent
  • Region – The geographical area where your cloud server is physically located.
  • Assets or Resource – Your server, storage or applications.
  • Container – Application for deployment that are meant to be isolated from other processes
  • ACL (Access Control List) – Your security policies and rules for managing access to your assets.
  • Tags – Setting a tag with value helps with search and reporting.
  • Shell or CLI (Command Line interface) – Black terminal screen or console to allow you to use command line instead of user interface for configuring your cloud.
  • Serverless – Serverless Application Model (SAM) that allows you to run functions without the need of server.

There are a long lists and these are the most common ones for starters. I will continue to add as I come across these common terms.