One of the most common Cloud Challenges are customisation on premise application. Many assessment done to existing on premise will reveal these reasons why you should not move to Cloud. However, the assessment approach has been done incorrectly. Instead, it should be telling you on how you need to move to Cloud.
We find what we want to see
A good cloud assessment approach will not be one sided. It should have a balanced data and strategy to give the reader the right materials to make a decision. This is to prevent the bias of “finding what we want to see”. It is common to reason that heavily customised application to remain on premise instead of moving to Cloud. Vice versa, findings often point that Cloud should only handle lightly customised application.
Strategy to Cloud
As products move to SaaS, users will be forced to move customised applications to Cloud. It is important to provide strategy on how to migrate the customised applications. Many Cloud assessment will use Big Bang approach to review if the application can move to Cloud. You should also request for other strategy to be included in your Cloud assessment approach like phase transition or pilot migration.
Cloud assessment approach is often bias and skewed towards Big Bang migration approach. You should consider for other migration strategy when you are conducting your Cloud assessment. Thus, this will provide you a better picture to decide if you can migrate to Cloud.
Rapid Application Development (RAD) is around since the days of Visual Basic (VB). Since then, there is a preference of lightweight and low code framework with Agile approach. APEX (Application Express) is one such framework offered free with Oracle database. What does this signal for heavyweights like Spring or J2EE framework? Should you switch to low code like APEX?
Ease of Maintenance
The key push factor to switch to low code framework like APEX is the ease of maintenance. This helps users to focus on solving business problem rather then creating technical solution. Changes can be made and deploy quickly. This suits high complexity and exploratory problems where scope is largely unknown.
Low code environment places emphasis on outcome instead of being expert in thr programming language. Thus, platform like APEX suits users who are not technically inclined to setup entire infrastructure like servers and database. This emphasis business driven skillset like problem solving instead of technical skills. Users can also realised business solutions quickly with low code deployment.
The switch to low code platform like APEX will be growing. This is driven by the need for agile solutions to solve changing requirements. Usage of APEX also allows citizen developers to co-own and maintain the development.
In many projects, stakeholder list is the output of stakeholder analysis activity. Not many are aware that you can actually anticipate the type of the project outcome from stakeholder list. These are the red flags that you need to lookout when you are reviewing the stakeholder list.
Get the Right Stakeholder
The creation of stakeholder list is important because you can review the roles of each stakeholders. It is common to see names that are just participants and not contributors. A right stakeholder must contribute and be accountable. If they are not fulfilling these objectives, it is worthwhile to reconsider these names.
Champions and Sponsors
For projects veterans, you will soon realise the importance of champions and sponsors. These two roles are critical success factors for all projects implementation especially digital transformation. Many of enjoyable successful projects I worked with have such players. These stakeholders make a great difference to the projects. They often provide morale, passion and clear direction to projects.
In many projects, there are moments where stakeholders are inserted based on political or namesake reasons. You should remove these stakeholders and ensure the right ones are there to contribute and be accountable. Champions and sponsors are necessary to provide the right support and ensure your projects are driven in the right direction.
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.
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.
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 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.
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.
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.
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.
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 and On premise reminds me of A Tale of Two Cities. One is being replaced gradually without the other having knowledge of it. It is not surprising some teams will remain in self denial of the proliferation of Cloud.
Similarities and Revolution
Cloud is nothing new and have been around for decades like hosted servers or managed services. The revolution comes about in the form of Digital Transformation from need for larger and larger server capacity in a particular entity and virtualisation. Suddenly, everyone jumps to the bandwagon as costs plummets with competition. However, not all teams are challenged to change.
How this Ends?
If you are familiar with the ending of the story, Darnay is knocked unconscious while being replaced by Carton for the guillotine. Does this sounds familiar if you are belonging to the teams who are not on Cloud? In many organisations, this replacement are taking place without involvement of on premise team. In most case, decisions are done at top management level and the teams are only engaged during migration. What a stark reminder to being at the guillotine!
A Tale of Two Cities are playing out at many organisations. However, it is a good suggestion that this should not be the plot. The ending is not pleasant for many. It is time we revisit the playbook and mirror another tale!
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.
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.
Developmentwith 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.