Migration to Headless: Practical Considerations

Modern Commerce Day, 2021

It was a pleasure to present at Modern Commerce Day, 2021, powered by commercetools, and headlined by the MACH movers and shakers of the year. If you missed the event or just want to reference all of the great content again, you can access all sessions on demand and get your complimentary Modern Commerce Day Report. This content is being published as an additional method to access my session: Migration to Headless: Practical Considerations.

What is Headless?

Headless could be considered the many heads approach. It is full separation of your front-end from the back-end and allows you to unify your back-end across multiple heads - or touchpoints - for example, your e-Commerce site, your administration system, mobile apps, IoT devices, and immersive experiences.

Headless entails moving off of the monolith and building an API-first approach to your back-end assembly. So why does this even matter??It matters because it allows you to:?

1. Unify your core business logic
2. Provide a consistent experience across many different touchpoints, and create new touchpoints in a matter of days
3. Reuse, not reinvent the wheel
4. Compose a best-in-breed solution that best fit your unique use case
5. And best of all, it reduces technical operational risk

Top Concerns

What are some of the top concerns organizations have regarding this journey? I conducted a mini poll to understand what the top concern was for headless migration. Total cost of ownership came out on top at 37%. The other rankings were as follows:

• Business Buy-In: 26%
• Technical Knowledge: 26%
• Vendor Management: 11%

This was a very interesting result, as vendor/partner selection and management are very intimately related to Total Cost of Ownership of a MACH solution.

Key Consideration - WHY

What is the key consideration to make when starting this journey? I believe it’s knowing your WHY - in all aspects of life - but especially in digital transformation. And yes, this is a WHY without the question mark; it is intended to be a statement that allows you to move forward. Take stock of the business issues and concerns within your organization, make sure to collaborate on your WHY with all stakeholders. To get you thinking about what to ask, here are some leading considerations:

• Maybe you fell behind in customer engagement during the pandemic, or you’re looking for other ways that technology can help connect and support your customers?
• Can your current system support new features easily?
• Can you maintain your PCI compliance?
• Can you scale infrastructure easily??
• Maybe you don’t even know what you don’t know?

So clearly ask and define!

• Why do we need to do this?
• Why do we want to do this?
• Are we ready to do this?

Business Buy-In & Education

When it comes to business buy-in and education, the definition of your WHY needs to drive it and it needs to be completely organic. This isn’t about what some other organization has done, or even how they have accomplished it.?Innovation comes through collaboration, and if you aren’t making considerations for how technology can accelerate your business, then innovation hasn’t been a core competency, and it needs to be.?Headless is not new; microservices are not new; cloud is not new; APIs are not new - my Christmas lights were even powered via an API this past holiday season! Each use case will be very different, and the motivating factors need to be determined based on current business needs, pain-points, and inefficiencies.?Focus on how the benefits of headless connect with your needs:

• You can unify in-store and digital experiences by building a stable base and not reinventing the wheel when building new experiences
• You can achieve faster go-to-market for features, and improve speed of deployment
• It allows you to select best-in-breed partners for critical features and compose a solution that fits your business needs??
• It also reduces downtime risk through isolated “micro” updates; your deployments will be focused on key features and not overlap with the entire platform when released
• The distributed cloud-native systems provide for improved resiliency, allowing smaller parts to fail
• It provides scalability in extreme peak traffic situations, and reduces the need for months of preparation
• It also solves looming end-of-life on current systems; gaps in versioning; and gaps in security

All of these benefits align with opportunity costs.

Think about the acceleration of technology, if your technology solutions cannot keep up, then your business won’t be able to keep up with consumer expectations.

Headless is about laying the foundation for customer touchpoint acceleration in scalable ways - you know the saying... work smarter not harder… well, this is it!

You'll want to consider if you have the right culture? This isn’t just about agility, it is about true collaboration and enablement of teams to harness technology to solve business problems.??

And also, do you have the right team? How easy or hard is it to instill or accept change within the organization as a whole?

Finding the answers to these questions will determine your ability to succeed. Not just in implementation, but everything that comes next.?

Methodology

For methodology, you have a couple of general options, and of course you can feel free to mix and match what works for you. Taking the strangler approach means?taking your time, building the foundation,?and moving critical features one at a time.?This is ideal if you have a lot of complexity, but can be expensive based on needing to maintain two (or more) solutions in parallel. Make sure you have a solid end-date for expected completion so that the project does not drag out forever.?

Going for a full-lift means determining the minimum viable product (MVP) and getting it all done at once.?This is no easy task, but with support and focus in a goal-oriented organization, there are many benefits to moving as fast as you can.?Make sure you properly plan the later phases of development, based on your MVP, ahead of time so you can set clear expectations.?

In either case, keep moving, and make the proper change management plans to ensure you don’t get behind in another digital transformation. Don’t wait as long to consider new technologies and start experimentation early. If there are motivating factors to how fast you need to go, it will set the tone for the remaining decisions you need to make. Sometimes when you need to get things done will drive the strategy vs. how you need to get things done. Your complexity and openness to consider an MVP will certainly play into the delivery timeline.?Even with an MVP, and depending on complexity:?

1. Will you require user training and onboarding for the new solutions?
2. Will you have enough time to ideally complete all milestones of the engineering lifecycle, including Quality Assurance, DevOps, and documentation?
3. How will access control and security provisioning impact the project?

These full-scope migrations can take anywhere from a few months to over a year to achieve in full depending on complexity.?Multiple contracts means more in-depth procurement; keep this in mind as part of the total timeline.?Each partner, including a systems integrator, will also require time to assemble and prepare the proper support teams to get the project off the ground. No matter what, establish your success criteria; be clear about your KPIs, revisit them often, and make sure stakeholders are aligned with go-live decisions.

Partner Management

This one simply boils down to how clear you can make your RFP or selection process. Defining your WHY should help you establish the proper RFP process. Be specific with your goals, ask questions relevant to your needs and have clear expectations and guidelines for how you will score partners against these goals.

Be realistic about which features you will need or want over the next several years. Certain partners will offer a lot more features than you will consume and others won't have enough features to support your business case. It will be up to you to find the right fit.?

Understand the features well, make sure they align with your specific needs. You can certainly also ask for a proof-of-concept to iron out your top concerns ahead of time. Many partners will have trial periods you can utilize to make a proper assessment.??

Something that is close to my heart is a partner-first mentality, not just the traditional client/vendor relationship:

• Will they be there to help in an invested manner?
• How fast will they respond?
• How will they enable your business?
• Also, how will you help them accomplish your business goals?

How many partners do you need (for e-Commerce)? You could really get very distributed in your choices and design. Some partners will be able to combine certain services, while others will remain very specialized.?Your core considerations for an e-Commerce head are going to be:

• Front-end
• Content delivery network (CDN), Backend-for-Frontend + edge services
• Commerce (which can consist of cart, promotions, product information management, customers, search, orders)
• Content management system (CMS) + digital assets
• Payment services
• Order management system
• Of course, the list can get quite extensive based on your particular use-case

Finally, capitalize on the ability to augment your internal team. Understand the features partners won’t be capable of supporting and the level of custom development that will be required.?Determine if your internal team will be able to support these initiatives, and the amount of support they will need in order to execute on them. Making clear investments in these initiatives may require you to split your roadmap and resources to dedicate and align your team to the proper goals without interruption.

Total Cost of Ownership

This brings us to total cost of ownership (TCO), which as a reminder was a top concern. TCO is a very subjective consideration and is highly dependent on the level of customization and usage your organization needs.?The good news is that one size no longer fits all, so you can assemble your solution based on the plan that makes sense. Usage based models are also helping to reduce costs and it is expected that they will continue to do so over time.

The number of partners required may be initially perceived as a total cost increase. My general statement on TCO is that going from an enterprise monolith to a composable headless solution - utilizing MACH technologies -? can certainly be achieved at the same cost or lower.?And cost is certainly a proper partner fit question and should be integral to your RFP.

Team Resources & Technical Knowledge

Now for all things team... Start with a clear design that takes into consideration business teams (such marketing) and the way their tooling will be integrated.?This includes integrations such as a content management system (CMS), analytics, and A/B testing.

If your composed solution does not require any custom coding needs - meaning you can assemble the entire e-Commerce head using all external SaaS orchestration:

• The team will need strong API utilization and orchestration knowledge
• It’s very easy to learn, program, and adapt the experience with APIs as needed

If you do have custom coding needs - meaning you will need to develop your own APIs using the MACH open technology principles:

• Understand that there will be a learning curve for microservices and serverless technologies for teams that have been running on monoliths for a long time
• You really need an engineering mindset, team members that are solution oriented and self motivated?
• And finally, support - make sure your teams have plenty of support in navigating this migration

In Summary

Understandably, if you've read to the end of this article then you are embarking on a major technological decision. My best advice is to simply think about your problem statement in the most practical way possible. There is a lot of hype in the market right now around MACH and composable solutions - and don't get me wrong, it's real, but your business should drive the technology. I also guarantee you probably have a lot of reasons you need to do this that you have to be honest about. Taking these simple steps will help with your discovery process:

1. Define your WHY
2. Use your WHY to educate others in the organization
3. Allow your WHY to define the methodology that fits best for your solution
4. Develop a clear RFP and find suitable partners
5. Give your team all of the support they need and start your journey!

This is sure to be a very dynamic and rewarding experience. Don’t forget to take the time to appreciate the journey, your team, and the advancement in technology that has brought you here.