Serverless is a great concept for Cloud. It really abstracted the infrastructure and let the developers focus on application. It is also build on the model of on-demand or “pay as you use”. This really change the development approach to a focus on coding and simplify the deployment of backend services. Conceptually, the idea is great. However, organisations are not quick to embrace and digital transform to serverless. A key reason is understanding of serverless and how to make the switch.
What is Serverless?
Serverless literally means “no server”. Developers build applications on abstraction layers like containers or dockers. The focus is shifted to coding and cloud providers will handle the servers like maintenance, capacity, high availability or fault tolerance. Effectively, your codes only consumes resources when in usage. Some called this FaaS (Function as a Service).
Barriers to Serverless
Serverless concept is a major part of digital transformation. This is because it disrupted your legacy infrastructure and application development model. Most organisations do not have switch because of change required to transform existing legacy coding for serverless. In addition, there is a lack of understanding on how serverless can bring benefits. Of course, you will also need to understand which applications are suited to serverless approach.
Serverless is a part of digital transformation and it is not possible to avoid this step. You will need to understand and determine the advantages of serverless and what it could bring to your development team. A way you can do so is to start small and pilot simple functions on serverless.
Application design have come a long way but the change in user mindset is still at a snail pace. A way to mitigate this change effect is by shifting the user mindset. Technology innovation may create a bandwagon effect and some may want to jump into these. Others like operations preferred stability and less disruption from change. There are often determination and resistance of users to retain old ways for older application. How should these mindset be shifted?
Understandthe Old Ways
No, RPA (Robotics Process Automation) is not the solution as always proposed! Application design often neglects the process outside of system and only focus the “As-Is” within the system. Older applications have fused with flows and processes outside of the operations. Users are used to conduct their daily tasks using the same approach.
These create a false sense on ease of use for legacy applications. One common example is shortcut keys for terminal applications that make it fast for data entry. Newer application usage of mouse and keyboard slows down operations as they need to navigate between two input devices.
Strong Case of Change
Technological innovation is never a strong case for change. Human nature resist change and crave stability. Without a compelling reason, the general users will not switch or change. This is the mindset that must be shifted. What is the case for changing the application? Users will often query “What is it in for us?”. Buy in must be initiated at all user levels and not just the management. Thus, you should provide a strong case for the application change.
Although application design have improved by leaps and bounds, the inclination to change to these updated applications remains slow. This is due to the need of stability from the users. You need to understand how users do their tasks with the old applications. Only then, you can provide a strong case of change to shift their mindset.
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.