leadership – Indika Maligaspe

Revamping Your Development Process: Elevating QA, UAT, and Production with Speed and Precision

In my experience working with or consulting engineering teams on supercharging their development, QA and release processes, I have seen that most places in trying to balance speed and quality has led to immense mental stress and sleepless nights to engineering teams. Not only that , in most cases you end up shipping half baked or crappy code to production.

You do need to ship features out the door quickly, but you also need to ensure that we follow a process that allows us to ship code safely. There should be very little “Oh shoot, this should have been caught on QA or UAT, not while the users are using and their customer is in front of them”. Here’s a deep dive into how you can sharpen your process while keeping the madness under control.

Branching Strategy: Keep It Clean, Keep It Smart

Let’s start with branching—a no-brainer, but often done wrong. If your DEV, QA, and UAT environments aren’t in sync, you’re playing with fire. Here’s the fix:

DEV Branch: Think of it as the playground where things can break. Merge feature branches into DEV, but don’t push untested code past this point. DEV should be active but treated with caution.
QA Branch: As soon as DEV has something worth testing, promote it to the QA branch. This branch is sacred ground for the QA team to test without distractions. Don’t cut corners by pushing to UAT or production before it’s stable.
UAT Branch: The UAT branch is where your end users get involved. Ensure this branch is almost identical to production so that any last-minute issues can be caught and resolved before going live. If something goes wrong here, it’s the final warning before disaster.
- Tools that can help:
  - Gitflow: A branching model that can make all this neat and manageable.
  - Feature Toggles (via LaunchDarkly or Unleash): Allows features to be toggled on/off without deploying new code, giving you more flexibility.

A good branching and merging strategy is imperative and is the first sanity check you need to have.

Fixing QA Issues in Real-Time and Keeping Everything in Sync

Now that we’ve got branching down, let’s tackle what happens when things go wrong in QA (because they will). Bugs found in QA should be fixed on the QA branch—don’t touch DEV yet. Once the fix is tested, backport it to DEV to ensure the same bug doesn’t creep back in later.

Fix in QA → Test in QA → Merge to DEV. No shortcuts.

Skipping this will create chaos in UAT and production. You’ll end up with different bugs in each environment, making it impossible to keep track.

Speeding Up QA Without Cutting Corners

QA often feels like the bottleneck, right? The devs are done, and the product team is tapping their feet impatiently while QA painstakingly goes through tests. But we can supercharge QA without compromising thoroughness.

Automate Smoke Tests: Tools like Selenium, Cypress, or Playwright can automate repetitive tests so that QA doesn’t have to spend time checking basic functionality every single time. Smoke tests should run immediately after every push to the QA branch, catching major issues early.
Performance Testing Early: Use tools like JMeter or Gatling to test system performance during QA, not after. This helps identify bottlenecks before you’re staring down the barrel of a UAT disaster.
Create and Maintain Robust Test Data: This is a big one. Testing with half-baked or outdated data isn’t going to cut it. Use data anonymization tools like Tonic.ai or Mockaroo to generate realistic datasets that mirror production.
Shift-Left Testing: QA shouldn’t be an afterthought. Developers should write unit tests for their code (think Jest, Mocha, or JUnit), and the pipeline should include integration tests (with TestCafe or Pact for API testing) early in the process.

Shipping to UAT Without Losing Your Mind

You’ve got stable code from QA, and it’s time to ship it to UAT. This is where customers or users do their validation, but it has to be done methodically.

Mirror Production: UAT should reflect production as closely as possible. Tools like Docker or Kubernetes can help create isolated environments that are clones of production, allowing your team to test under real-world conditions.
Automated Deployments: Use tools like Jenkins, CircleCI, or GitLab CI/CD to automate deployments into UAT, making the process faster, repeatable, and less error-prone.
Quick Feedback Cycles: Don’t leave customers hanging with long UAT cycles. Use tools like TestRail or Zephyr to manage test cases and feedback in UAT. Make sure there’s a clear process for logging bugs and responding quickly.

UAT Expediency: Customers Love Speed—Give It To Them

UAT often drags because end-users aren’t testing efficiently. The key here is to give them structure and ensure they’re not just clicking around randomly:

Test Case Templates: Provide your customers with a checklist or clear test cases to follow. Use tools like Cucumber for behavior-driven development (BDD), where test scenarios are written in plain English, making it easy for non-technical users to understand what they should be testing.
Run Sanity Checks in Parallel: Before customers even touch the UAT environment, run automated sanity checks to ensure the system is functioning correctly (similar to the smoke tests in QA).
Feedback Mechanism: Use tools like Trello or JIRA to collect user feedback quickly and efficiently. Implement a tagging system that can help prioritize critical issues versus nice-to-haves, so the UAT process doesn’t drag on forever.

You can’t have your cake and eat it too—rushing things to production without proper QA and UAT will lead to headaches down the road. By creating a clear pipeline between DEV, QA, and UAT, and keeping those environments in sync, you’ll reduce the number of bugs creeping into production.

Key Tools Recap

Branching: Gitflow, LaunchDarkly (feature toggles)
Automation: Selenium, Cypress, JMeter, Jenkins, Docker
Data Preparation: Tonic.ai, Mockaroo
Test Management: TestRail, Zephyr
Feedback: Trello, JIRA

Focus on testing the right way with proper tools and processes, and you’ll see smoother releases, faster UAT cycles, and a lot less hair-pulling come production time.

Building a Strategic Security Roadmap – What I learnt over the years…

Several years back I had my first stint at building a strategic security road map to a client I was working with. I must say I was not a practiced and seasoned expert who knew “a-z” of building security strategies and road maps. So as usual, I just rolled up my sleeves and started digging in to finding out all I can about what needs to be done, who are involved , what should be my approach and thousand other questions I had. This did lead me down many rabbit holes, and after several years of researching, discussing with experts, working with security architects and many implementations later, I have come a little bit further down the road of implementing security strategies and I assume I am bit wiser (so I would like to think).

In this blog series I will try to impart what I have learnt so far in my journey in helping multiple clients implement security road maps from undersetting the need, planning, documenting, getting the buy in, to implementing security road maps.

So the first thing I needed to understand was the big “WHY”

Why do we need implement a security strategy in the first place? my take on it and as I see it, was for any organization to ensure that their “valuables”, such as information technology or systems or data are kept safe from unwanted access and usage.

Well, what does that mean then ?

Well, any organization has things that they value , such as data, systems, devices, or any other components that has business value to the organization, which are called “Assets“. Through a weakness in the organizations environment called “Vulnerabilities“, assets can be exploited by intruders called “Threats“. Hence these are the “Risks” that any organization will face. When building our strategy we are suppose to identify these risks and come up with plans, designs, and actions to mitigate these risks. We have to do this by putting relevant controls in place

When defining risks and their corresponding controls, we will need to consider

The opportunity for threats to exploit vulnerabilities with controls for mitigation.
The chance that a vulnerability will lead to a compromise by using controls for detection.
The effect that a compromise has, in terms of impact by using controls to response.

In order to implement a strategy we will need to come up with a strategy that allows an organization continuously look at,

Planning – studying and then designing a resistant security architecture for various IT projects in line with business needs and risk acceptance
Developing – prerequisites for networks, firewalls, routers, and other network devices
Performing – vulnerability assessment, security testing, and risk analysis
Researching – the updated security standards, systems, regulatory frameworks and best practices
Communicating – relevant risks, vulnerabilities, and mitigation strategies to senior leadership

So how do we go about doing this…

Well, this is just the start on my approach to enable an organization to implement a security road map. In my next articles I dive a bit deeper, by taking a case study on an actual implementation of a strategic security roadmap, what was learnt, what went right , what failed, and some tips and tricks .

Duties of a Software Architect – build for customer needs, not ours.

In my previous article (UNDERSTANDING THE ROLE OF A SOFTWARE ARCHITECT), I explained the role of a software architect as well how we can categorize software architects. Whilst writing that article what came to my mind is, do we really know what our duties or responsibilities are as an architect. So I decided write from my experience what are some key duties or responsibilities from us as architects.

One of the key challenges, which I have seen many times in projects and dealing with other architects or even myself for a major part of my career (which is over 21 years now), where most times we as architects try to come up with technological and architectural solutions but we miss the actual problem we are trying to solve. Sure, we know all the tools, the technologies, the diagrams, and the notations but for what we are using these tools of our trade is a sometime a question. I believe as an architect the most important thing required by us is not a technical write up or an end state diagram or even a large solutions document, but simply to understand what’s the problem or the challenges our customers have. Given below are some projects from my experience where the teams almost missed the clients need by trying to build sophisticated solutions but by re-evaluating the actual customers need were able to come up with “Just good enough architecture” to help the clients to get what they need.

In a project one of our customers had an issue where their system which had grown organically over the years was at a state where it was not able to scale to handle the traffic volumes any more. The architecture teams were tasked at re-implementing the key areas of the systems that needed to scale. The team came up with a pretty cool target state, but that would be almost a complete rewrite of some major areas of the system and potentially would take a considerable time and effort. However rather than jumping in to building this cool new target state, the team decided to re evaluate what the actual need was, was it to build this super cool system that can scale at large in couple of years or was it to handle the traffic loads incrementally so that business see’s the system improve and scale with the demands. Once we identified the actual need of the customer was to have the system to have the ability to grow with the traffic growth gradually as well as have a buffer and resiliency to a sudden spike, we came up with a road map on how to get to our target state incrementally. Then by developing some simple optimizations to the data base structure, queries, introducing parallel processing to some key areas that were impacted with traffic growth, and a bit of additional hardware to support the parallel processing, we were able to handle almost 3x the traffic load. Whilst the business was enjoying the scale, the team worked in introducing caching to reduce the loads on the database, decentralizing the data base so that loads could be handled by slave data stores, and working on breaking the system’s key areas to service orientation with cloud native features and ability to add hardware on the fly (elasticity). This bought the system to be scaled at large and it also gave the business an immediate return on investment as their business grew exponentially.

In another system, which was logistic based, the team had architected a sophisticated solution where it was micro service based, and with rich front end UI’s using the latest front end scripting frameworks and web applications. A major part of the development effort was going for the web and mobile front to make sure that they were very attractive and user friendly. However when we again re-evaluated to look at the actual need of the client, and how the client would use the system operationally, we identified that the operational staff at the client end rarely needed to use a UI, what they really needed was a simple list with data to do their job and to get the list printed when needed. Once this was identified the need for sophisticated UI’s was no longer a need. This reduced a huge complexity from the system and cut down a major portion of development efforts. Another area identified was the system mainly needed trigger based jobs that needed to execute periodically and rather than developing the components as web applications or web services as originally planned, just doing simple CLI’s- the system complexity, cost of infrastructure and development efforts could be reduced drastically.

We had a request from one of the clients that they were having a challenge where they were getting data from various sources and the time taken to load that data to their main system, which needed to happen regularly, was extremely high. Their recommendation was to see if a data science approach can be taken to use machine learning to reduce the overall time taken. So the teams were engaged and architectures were planned. However a closer look at trying to understand what the actual challenge the customer had, we identified that the overall process from end to end had multiple manual workloads that the areas that were looked at to be automated through machine learning, would not help the client that much. However after visualizing the current work flow, identifying what are the manual bottlenecks and how they can be automated through simple automation processes, were identified that we can ensure the overall time taken can be cut down drastically and all this can be done whilst the data science aspect (which obviously takes time for training and implementation) is getting implemented. Hence the customer starts seeing benefit almost immediately.

In another project for an online transaction processing product where for the team to deliver a simple product feature to production after development completion, it was taking at least two months. They were looking at implementing sophisticated tools and revamping / rewriting the system to be cloud native etc… This was a massive project which potentially could have taken years. However when we really drill down to the actual root cause of the problem, we were able to identify that the challenge mainly was in two main areas of the system where any change done in any area of the system impacts these two key areas. So rather than trying to revamp, rewrite the complete system from scratch and bringing in new sophisticated tools up front, we were able to come up with an end state architecture, where the system would become a micro serviced, cloud native, with proper devops pipelines, and that could release features to production within couple of minutes. However more important than that, we built a simple road map where within a short period of time the product teams had the ability to safely release features within two weeks after development by bringing in QA automation to key areas and devops tooling with team collaborations to the overall project. This gave a huge boost to the product teams to release features rapidly. Later we started working towards the end state where the releases can be done within couple of minutes.

These are some example out of many which I has to get involved in, which shows that rather than trying to find technical solutions, we need to be able to understand what is the problem that our customers have, why are they looking at us to come up with a solution, and then only look at how best we can help the customer with solving their problem. Let’s face it, if the customers do not have a problem, they certainly do not need to spend on an architect. I believe “Just good enough architecture” is an approach we would need to take rather than “grand scale architecture” when coming up with solutions.

Understanding the role of a Software Architect

According to Wikipedia the role of a Software Architect is defined as

“Architects make high-level design choices based on their programming experience. An architect has thought through all the aspects of a software, just like an architect that builds a house. A construction architect knows where the ducts will be, where the electric connections will be and where the wall outlets will be. A design that a common person sees is just the walls and windows but a detailed design that is abstracted from the outsider are also present with the architect. In addition, the architect may sometimes propose technical standards, including coding standards, tools, or platforms.”

However according to my experience and according to actual software architects out there who have shared their experience; this is just a small portion of what goes into being a Software Architect. A better analogy for me would be

“An architect is a person who works with a diverse set of people both technical and non technical to guide a project / product or an organization to it’s business success using technology , engineering, collaboration, leadership, project management, standards, and governance.”

According to above an architect plays a role of technical visionary, leader as well as people and process champion to ensure a project is successfully completed.

Well, what does these actually mean?

However when we look at the content that is out there, we mostly see the technical aspects as designing, modeling, deep technology knowledge , engineering principles etc… but if we look at above list, we are looking at more non technical then technical aspects.

So what is an architect expected to do?

To understand this, let’s understand the typical types of software architects that we can find in the industry. Though there are many, I can see three clear distinct types or architects,

Enterprise Architect – A strategic architect who looks at the overall organization’s business processes, people, information flow, and business & technical strategies. The main goal is to align an organization’s IT with business goals. An enterprise architect looks at the long term initiatives.
Solutions Architect – A tactical architect who looks at cross domain and cross functional system interactions such as frameworks, infrastructure, road maps, guidance, cross cutting process & governance, reuse and strategic solutions. The main goal is to look at an organizations product or services suite and help to implement strategic solutions across the board.
Application Architect – An operational architect who is a subject matter expert and will focus on single application stack. Integration Architect, Cloud Architect, Data Architect, Mobile Architect etc… An Application Architect would focus on components, maintainability, modules, classes, libraries, languages etc…

Most of the content available mainly details application architects, which is about the operational implementation and remaining highly technical. But the different between a senior engineer and an architect are those non technical skills, which I would coin as the essential skills needed for an architect to be successful.

So to be an effective software architect, we need to understand the role of an architect and the key role non technical essential skills play in the role.

So to answer the question “What is the role of a software architect” ? the best answer that I can put out is , a person who guides a project or product from inception to closure with a diverse set of teams by using leadership, management and broad set of technical skills.

In my next article I will dive deeper into understanding what are the technical and non-technical duties of a software architect.

Building an IT Strategy

Developing an IT strategy may look as a daunting task for many IT leaders and even a defined IT strategy may not yield the right outcome. Many reason could contribute to a failed IT strategy but some of the main reasons being

IT leaders being pushed for IT strategies where the business itself may not be having a right strategy with clear vision, mission, goals, and objectives
A strategy being based on several tactics that keeps changing frequently
A strategy based on some external consultant with a 200 page document that nobody really follows.

IT strategy should be based on answering one key question,

how will IT helps business success?

So it is imperative that what defines as business success is identified up front. There are many tools in identifying business success, but one simple but yet powerful tool could be using Value Discipline model by Michael Treacy and Fred Wiesemara. The Value Disciple allows an organization to understand what is the one thing that will create a competitive advantage over others and what is it that an organization wants to be famous for. Another great feature about the Value Discipline is that in can be applied at any stage of organizations growth

Strategy

Strategy should define a vision of how the company will succeed, what are the goals to succeed. Basically how will the company win, by focusing on what?

Strategy is long term, will not, and should not change frequently

Strategic plan

Are the short term tactics that will allow us to get to the long term strategy? These are short lived, 3 months – 1 year. Regularly evaluated and changed to meet the current need and environment change.

IT strategy can be broken into three key areas DEMAND , CONTROL , SUPPLY.

Demand encapsulate the business demand to ensure business success and the IT contribution to that success

Control defines how will the organization ensure the strategic design is enforced correctly

Supply is how will IT evolve it’s capabilities to meet the demand

Demand (How will we win)	Control (How will we ensure strategic design)	Supply (How will IT evolve it’s capabilities)
Business Context (Value Discipline)	IT Principles	IT Service
Business Success	IT Governance	Architecture
Business Capabilities	Finance Management	People
IT contribution	Metrics	Sourcing

The IT strategy document should be an 10 – 15 page document that encapsulate what is needed for the organization from the above table. Not all is needed , but we should pick what we need for our business.

Some highlights from above are

Demand

Business Context (Value Discipline) – What discipline should be our core discipline that we will never compromise for any reason. This is what will make us win the game of business

What will be the measurement of business success?

Business Capabilities – What are our core capabilities we need to have in order ensure that we meet business success (Cycle Time, M&A, Efficiency , Process Improvement, Agility and Change, Transparency, Innovation , etc….)

IT contribution – How will IT contribute for business to win?

Control

Principles – 8 or 10 core principles that will govern all IT decisions which should be catered towards how IT will help business win. Two key questions to ask each time we make a decision (strategy moment)

How do we succeed as a business
How will IT help

Governance – What will govern every IT decision in every area?

Metrics – what are the KPI’ s that IT leaders need to monitor in order to ensure that the IT strategy is being followed and IT is delivering it’s promise to support business sucess

Supply

IT Services – what are the IT services that needs to be improved, altered or added to ensure that IT supports the business.

Architecture – How should the application , infrastructure , product architecture improve or will enhance the capabilities of the business.

People – What and where are the skill gaps that needs to fulfilled in order for IT to supply business success

A well laid out IT strategy and strategic plan will ensure that IT delivers on it’s promise to ensure business success.

I hope that above gave some insight to IT leaders on building an IT strategy that will work and has worked for me.

5 Attributes of a Great Software Engineer

Software Engineering is the process of applying engineering to design, development and maintenance of software. Most engineers who come from engineering schools are taught about engineering practices, programming languages , coding standards etc… but once you enter the world of professional software engineering and the dust settles down , you find the rules of the game are not exactly what you expected.

In the last 15 year I have dealt with software engineers who are rock solid , enjoying every minute of their work and others who are dreading to come to work everyday. After discussing and researching on both sides of the fence, what I have seen is that it is not the difference in skill set , the talents or IQ that makes the difference between the two , but the attitudes and the personality attributes that count the most. Listed below are five of the key attributes I’ve found that makes the biggest differences between the two groups

Passion

All great software engineers have a passion for giving solutions to variety of complex problems. It is in their nature to give solutions and they do not back down from challenges. Let’s face it, software engineers have either just finished solving a problem or are in a problem or heading towards a problem. So you need to have passion to find solutions to these problems. The solutions could be a software design, an analytical / logic design or a code change. But whatever way you look at is you need to have a passion for going into problems and giving solutions. If your cup of tea is not giving solutions to complex problems, then software engineering may not be the right hat for you to wear.

Desire to learn

Any software engineer I have come across who is worth his salt desires to learn. They desire to grow and expand their skill set as well as understand what their giving their software solution for. In order to do this a software engineer needs to have burning desire to learn.

If as engineers we are not sure of what solution we are developing we need to learn what we are developing our solution for. We need to learn what the requirements are. Gone are the days when an analyst would list down the specifications step-by-step with the intent of getting it developed in that order. Agile Development is an excellent example for this. It is expected for a software engineer to learn from clients and develop a solution that caters to clients needs.

The technologies in the industry are changing ever so rapidly that it is extremely hard to keep up, but as engineers it is expected. So desiring to learn and spending at least 1 hour per day on building themselves is key to any software engineer. They need to make sure they are in par with the industry needs and the latest technology , engineering trends.

How do you learn, well the best ways are

Ask Questions
Join a User group
Read
Try things out

Discipline

They say there are two pains in life, the pain of discipline which weighs ounces whilst the pain of regret which weighs tons. A true software engineer is totally focused and disciplined. Disciple is the difference between a cowboy and a seasoned engineer. I believe there are two areas that a software engineer really needs to be disciplined in

To end what you start – You need to make sure that you complete things that you start, otherwise you will have foundations laid down allover but no building to show for that. With the technology changes and new challenges that are thrown to engineers by the industry, it is easy to get lost in trying out new things always. But it is extremely important to finish what you start. As a software engineer you need to have a reputation as a person who the industry can depend on to deliver and that does not come if you are not disciplined.
To look before you leap – You need to think and see what are the consequence of doing something before doing. My metaphor for this is “Read the README before running the Software”. Most software engineers jump into something without doing the due diligence and this is asking for trouble down the line in any project. You need to spend that upfront time in planning (maybe not 100%) at least to a level where you know what needs to be done, where the potential road blocks can be and what can be done to overcome them. Sometimes you may not foresee all the challenges, but that is not in your control. But you need to be disciplined to spend that time upfront in planning before implementing.
Learn from your mistakes – You need to be discipline enough to document what went wrong with each project and see how you can improve on this. Most of the time I have seen engineers make the same mistakes over and over again. This leads to loss of credibility and potentially damaging projects. So as a rule make notes of what went wrong and improve with every step you take. This requires a discipline to document , analyze and above all commit to improving yourself.

Flexibility

I have herd the term “I am a Java engineer” , “I am C# engineer” , “I am Python engineer” or “I am Database engineer” , “I am a Business component engineer” etc… so many times by Software Engineers. For me this is not what a software engineer should stand for. A software engineer should be flexible enough to adopt change. They should be able to learn and see what the current situation requires and becomes the very agent that provides the solution. Now you may choose to master an area of expertise, but you should not get locked to any. The more flexible you are in changing yourself to the current needs of the industry the better solutions you can give and more you will be valuable to the industry.

Apart from this a software engineer should always try things out and see how they will fit into to the solutions that he needs to give in the future. Do not be afraid to change or try new things due to future failure. Always be flexible and adaptable.

A good software engineer is not bound by a technology, a framework or any area of development. They provide solutions to the industry by looking at what is best suited and how best to get that solution implemented.

Enjoy

The last but the most important attribute I have seen by solid and successful engineers is that they enjoy being a software engineer. They love and thrive on the solutions that they give and what they are called upon to do.

They enjoy what they produce and how they go about producing great software solutions. I believe they actually view the work they do as an art rather then just a profession and this leads them to enjoy the process of creating their masterpiece.

So enjoy every moment how challenging it may seems at the time. Remember somewhere in the not to distant future you will look back in time at a challenge or some problem you went through and laugh at what you faced and how you overcame , so why wait… why not just enjoy the challenges and what you do now it self.

So there you have it, five attributes that I have seen over and over again from rock solid engineers. I know if you add these attributes to you , maybe you can also become one rock solid engineer.

Modernizing Legacy Systems to Cloud

Most companies who have been in for business for more than 5 years do have legacy applications. Once the company realizes the potential benefits of modernizing legacy applications for cloud, then it is up to the technology head (CTO / CIO / VP – Technology / Chief Architect etc…) to come up with a strategy to do the migration. Though this might look daunting luckily there are several proven strategies that can be leveraged on.

First and foremost understand why you need to migrate and what the benefit is. This is the first key step that needs to be done before anything. This would help in understanding whether you want to go for Hybrid cloud or Private cloud, Public cloud only. By critically looking at your current business model, existing system and future plans the shape of migration can be planned.

For example if your application has high sensitive data or is very chatty by nature then private cloud will be the best option, if you system is going to incorporate web fronts, social media integration etc… You may look at a hybrid solution or if your system is anyway light weight and your plans in the future do not include dealing with highly sensitive data you can look at just going with public cloud.

Next understand the architecture difference between monolithic all in one, Hybrid cloud and cloud architectures and see what fits best for your system. Is your system a large monolithic system which is difficult to decompose? Or are there parts in your system that can work independently and are light weight enough to be moved around? Or are you even planning on some new features that can be done as separate sub systems that can be used to glue into your existing system with glue code. In this phase you can identify what are potential candidates. Another area to analyze is the workload each area of the system does. Depending on the load you can decide which areas would need high scalability and plan accordingly your cloud migration.

Now that you have identified whether you want to move ahead with modernizing the existing system to cloud, let’s look at some options you have in doing this safely.

Lift and Shift

This is the first step in moving to cloud, where simply the monolithic application can be taken and move in to a cloud environment as is. At this stage the early analysis that was done will become priceless. You would be able to understand whether you would need to have a private cloud or hybrid cloud solution where certain parts of the system with sensitive data or chatty behavior can be shifted and any area that is light weight and can reside in a public cloud. My recommendation is always go for a hybrid where your master database and core components in your monolithic system to be in a private cloud or dedicated servers and any customer facing web tier apps or disjointed parts of your system which can run on their own to be in public cloud. The key thing to understand is that, there is minimum or no change done to the systems architecture. This is the least expensive and fastest in terms moving to cloud however then you will not get the full benefit of cloud.

Partition or Incremental Replacement

Next option or the natural progression from “lift and shift” is to start migrating parts of the system incrementally to cloud or partition the system and migrate. Here again the analysis done initially will be priceless as you can identify which areas will be easiest to migrate / replace or which areas of the system would benefit from a cloud migration. You would create a list of your systems functional / business domain units and put down a priority for cloud migration. You can look at what is the business value, how easy is it, what is the cost for each unit of your system for creating a priority list.

For example if your system has a web front where customers come into place orders, then that is an ideal candidate as that can be easily migrated to cloud with some effort, however by doing this you could leverage the elasticity of cloud. Also if your analysis revealed that this area of the system is what get’s most of the hits seasonally then again this is an ideal candidate. You can even look at having the web front in public cloud whilst the database and even business tier apps still residing in private or dedicated environment initially.

Once you have the list prioritized you would go on either moving each part of the system to cloud by modernizing or replacing with another application / system. The cost in this phase / option is higher then lifts and shifts but you will be able to leverage befits of cloud more and you are now getting in to a true cloud system. Also this will be very less risky than doing a full blown cloud migration in one go and following an application migration list will mitigate risk.

Refactor and Cloudify

This is the most costly and up front time consuming option. Here you would look at your system with your analysis done and completely re-engineer your system with newer architecture and / or technology to move into cloud. There are methods of bringing your system architecture to cloud and those needs to be studied. You will need to invest upfront time and resourcing to start refactoring your system to be cloud ready and use cloud. For example you may go from a monolithic system to a SOA based or Microservice based architecture, you will go from one single database to multi-master database architecture, you may even have to change your technology stack to support cloud, you will need to change your delivery, deployment processes by leveraging orchestration tools etc.. However once done your system will be fully cloud compliant and will be able to reap the benefits of cloud including cost reductions, elasticity, high availability , safe deployments, continues deliveries etc…

So there you have it, three ways to modernize your current system to cloud. My personal opinion and what I have used for most is to go from “lift and shift” to “partitioning and incremental replacement” or refactoring. This will be less risky and will allow you to reap the benefits of cloud early as well as give you time to learn and absorb all that comes with a cloud based system.