Brianne:
Welcome to the webinar on replatforming. Today I am joined by the cohost of the replatform podcast as well as Ash, Illumina. We'll go into bio's in a few moments. Before we get started, just wanted to start with some housekeeping. All attendees are on mute. This webinar is recorded and will be emailed out within 24 hours. And we encourage you to submit questions via the chat. We'll be monitoring the chat and at the end we have time for Q&A. So please submit your questions, we'd love to hear from you and hear what's resonating, what you want more information on. As far as our speakers, I'm joined today by Shaneil Lafayette. She is our commerce technology associate here at Elastic Path. And I'm joined also by James Gurd and Paul Rogers. They are the cohost of the replatform podcast. You've likely heard from them. James also owns the Digital Juggler and Paul is the managing director at Vervaunt.

Brianne:
Ash, director of GIS commerce, Digital Experience at Illumina will also be sharing his experience as he is recently in the process of replatforming to Elastic Path. Today, we'll be covering key identifiers for replatforming readiness. Paul and James will be sharing replatforming tips and Ash, Illumina will be sharing his case study. Before we wrap up, Shaneil will be sharing the benefits of switching to a composable commerce approach. And with that, I'm going to hand it to Shaneil.

Shaneil:
Awesome. Thank you, Brianne. So with the advancement of technology and ever evolving customer habits, many companies have been increasingly entertaining the idea of replatforming to more agile solutions like headless commerce and composable commerce solutions. However, many are still very hesitant and we get it, right? Replatforming can be really daunting. Firstly, these projects have large upfront investments from both a budget standpoint and a time standpoint. On top of that, you've already made a large upfront investment for your current solution. So the thoughts of embarking on yet another large investment might seem scary, and it's hard to let go of and to deal with that sunk cost. Then on top of that, there is no guarantee that it will be successful and it could also cost you your job.

Shaneil:
Many of our customers had the same thoughts and have had fruitful replatforming projects like Illumina, who you will hear from Liezel. Here are some ways that you will know your business might be a prime candidate for replatforming. Firstly, your current solution can't keep up with the growth of traffic to your website. As a result, peak sales often cause websites to go down and losing your valuable revenue. Secondly, maintenance and upgrades are time-consuming, do sort of rigidity of your current solution thus slowing down your deployment of different channels and different features.

Shaneil:
Thirdly, adding new features, customizations or partner technologies to your solution have proven to be difficult, and actually sometimes infeasible. Fourthly, you've experienced exuberance unexpected costs throughout your e-commerce journey with every new change. This is something that we hear so often. And lastly, your platform is coming to their end of life. It's either you upgrade to the new version or look for a new solution. If you're experiencing any of these pain points, then it may be time to consider replatforming to a more agile solution or best of breed solution. And to help you get prepared for approaching your replatforming project, Paul Rogers and James Gurd are here to help.

James Gurd:
Cool. Excellent. Thanks so much Shaneil. Cool. First of all, hello everybody. And thanks for tuning in. Myself and Paul are going to share some insights based on our experience. We've run replatform projects for a lot of brands, including Victoria, back in Toten, Sunspel, we both currently working with Pam Guyer. And what we've tried to do is prioritize based on what we see as having the biggest impact. And also our client teams should focus based on what often trips people up and where things get underestimated in terms of the impact they can have in project success.

James Gurd:
So let's start with the basics, the fundamentals, which is being organized and being disciplined. Often the temptation with big projects is because of the complexity and under stress if we need to get this done, it's jumping straight in instead of taking the time to really structure the project correctly. If you get the structure right upfront, it can save you a lot of headaches later on. So key things is when using open architecture, move into something like a composable and especially if you're doing it using composable and moving to headless when you're not used to it, you've got to be clear on what you're doing and why. There isn't a blueprint to start a store, but some of them are more legacy setups high. Yeah, you have a set module services and APIs, which means you can create something completely custom, but you have to be careful when customizing, do we sense about what you're building and why and learn to prioritize.

James Gurd:
So this starts with clear vision goals and having success metrics in the project. And why is this important, is basically whenever you're making a decision during the project, in terms of how do we want to build something or what customization do you want to introduce? We've got to be able to tie it back to an overarching project, golden objective, to know that we're on track with achieving our vision for that project. The next bit is governance and it's something which I don't see a lot of people putting enough effort into, especially in the smaller business. Bigger business typically have governance structures in place, but SMEs struggle a bit with this. And it's about being clear on how the project controls are put in place. Having a single sponsor, not multiple sponsors, which I've seen before, which clouds decision-making and brings politics into play.

James Gurd:
A single commercial sponsor who has the finite sign off ownership for decisions, clear decision-making responsibility, who in the project team can make different types of decisions so that he can speed up decision-making and having a clear escalation path. As Shaneil said, these projects are complex and risk is inherent in these projects and things do sometimes go wrong and not to plan. If you have a clear path in place to handle those issues and escalate them up towards the senior decision makers, you take out some of the emotion of that issue.

James Gurd:
The next bit is, I'm looking at scope of budget, obviously critical. Knowing what your high-level scope is and being clear on what is your MVP, a minimum viable product versus subsequent release phases, it really helps in the heat of battle to be able to make smarter decisions to say, "Okay, well, do we really have to obsess about this now? Because that's not what our MVP, we can push that down on the line." Budget can also help frame decisions. If you know you have a finite budget you're working towards and a particular element that you're investigating is going to push the budget out. You then have a decision, do you actually defer that? Or do you have to go back to whoever owns the budget to say, "Hey, we need more to deliver the business vision."

James Gurd:
Let me go on to business requirements. Before you engage in any kind of discovery process with an agency partner for implementation during which you build out a detailed specification, you've got to know your high level requirements and where they fit from a priority order point of view, what has to be delivered and why. This isn't going into the ends level of detail, it's just high level statements and use cases that you know your project has to satisfy because you can very quickly then do an objective assessment of how you achieve those, and using the platform and where there are current strengths and where you might need to do customization.

James Gurd:
And the next two are linked together. Project management and comms tools and processes, I think there's probably a bit of a no brainers. There has to be somebody who has overall responsibility for delivery of the project, who coordinates resources, both internal and external and has project management disciplines. Obviously essential because when you start getting down the line and everyone's in a mad rush to get things delivered, there needs to be somebody bringing people back to milestones and focusing them on the critical tasks in the project. You need that discipline from the start so that you don't get disorganization built into your project.

James Gurd:
And then the comms tools links are, how do you communicate? Avoid email overload because when people are bombarded by emails day in, day out, emails get lost. They disappear down inboxes, people don't act on things. You don't have a good audit trail, not everyone replies to. All of a sudden an email that's meant to be visible to everyone, disappears from visibility and communication gets fragmented and it causes us a lot of chaos. So get your tools right and the process for communicating the lockdown so people know how to communicate effectively.

James Gurd:
And that links into the last point for me on this and the organization and discipline is, risk charter. There will be risks. Have frank conversations in your business. What do you think the risks are? If you evolve into a composable approach from non-composable, where do you perceive the additional business challenge is? And then once you've got your risks defined, you can start to work as teams to put mitigation plans in place. And risk is inherent in these projects but sensibly manage, it doesn't have to derail it.

James Gurd:
Cool. We'll move on next to what I think is another important consideration, which is what is the impact on your operating model within the business? When anybody changes platform, typically there is an impact in terms of a business model and process. And you have to understand that. And before embracing new technology, I advise customers to focus on two key questions. I'm going to step out of context for this, because what you can see from the image on the right, a few of you probably have things for the chief MarTech annual marketing technology landscape. There's so much technology out there. There are so many different providers and each one has a slightly different flavor of how they deliver things.

James Gurd:
If you don't know exactly what you want to do, how you want to operate and how you want your ecosystem to work, you end up going down a rabbit hole of looking at things and not knowing why and how they will plug into that vision. The key context here is, monolithic and legacy applications have technical debt and they often impose restrictions on businesses. And one of the reasons for moving to more agile setups is to try and get more mobility and to speed up releases and decision making. However, if your business is you used to work in a very specific set way, and you suddenly throw in a technology that offers you complete flexibility, your processes aren't going to be aligned and therefore your speed to market constraint is not in the technology it's in your business ability to execute. So you have to find the optimal balance of the technology and your process and your capabilities internally.

James Gurd:
Composable is much more than just the technology use. It's about your business culture and your internal ability to act and very important to have those conversations. And for me, best way to encapsulate this is it's a mindset shift. The typical mindset on a an old legacy system from the clients I worked with is, okay, how do we get the platform to do this? But the mindset shift for modern e-commerce organizations is, how do we want to do this? And how do we best use the technology in the package business capabilities to achieve it? And at what point do we need to do customization and extension on top of these microservices and APIs? Really important to think about.

James Gurd:
That's why I say two questions every business should answer, whether it's them doing it themselves when they're working with an external consultancy is, what does e-commerce mean to the business and how do we need to adapt in order to put that vision in place? And how does evolving from our current set up to our new setup impact our process and our ways of working? Because you have to take people on the journey. You can't just suddenly chuck people into a new environment and expect them to be happy with it. They need to be educated on the change to their working practices. Cool. Over to you, Paul.

Paul:
Great, thanks, James. Some really good points there. Ultimately practical considerations, I think a large project of this nature can seem really complex and daunting. And ultimate is really complex and it is a huge change and it is a big project, particularly if you're moving from a monolithic platform through to a composable architecture. But with the right approach, the right team, the right process, as James says, I think this can be managed. And ultimately I'm going to touch on basing later on, and James already touched on phasing. But I think that's one way to reduce and simplify the scope of these types of projects.

Paul:
It's really important to focus on the business and management aspects as James said, and ultimately, I think all of this comes down to prioritization. And again, we'll touch on that in a little bit. But from a practical perspective, some of the key things I'd suggest really focusing on and honing in on are the scope and trying to phase the project as much possible. James talked about the concept of an MVP and really defining what that looks like. And ultimately with a more complex composable belt where you have a number of different systems and you're all working with different sets of KPIs and everything else. Trying to create a first phase that maybe isn't necessarily using all of those systems straight away can really simplify the scope and de-risk the project.

Paul:
Data migration is an important part of any replatforming project. And I would personally suggest trying to start that as soon as possible, one to free up people because a number of key people are going to be involved in that phase of the project and free them up for further on down the line. It will help you to be able to test as you go. And again, this is a key risk area and getting that out of the way will help you to really understand your timelines.

Paul:
Testing. Another really important part of any replatforming project, and often this is going to be dictated by the people that are managing the project and the methodologies you're using for managing projects. But the more you can test as you go and build testing into different phases and different kind of releases then the easier it will make it towards the end of the project. And ultimately you're wanting to avoid a situation where key stakeholders or even people that are really in the depths of the project are just having to go into a single UAT phase. And that's the first time they've been exposed to key parts of the project.

Paul:
The next one is SEO. This is always a really high risk area for any replatforming project, is something that needs to be taken seriously. You need a real specialist involved in a project. I always suggest assigning a product owner in this area and getting them really ingrained in the project and the business, making sure they're exposed to all of the different stakeholders around the project, and definitely getting them involved in the discovery as well so that requirements are outlined and built into the scope of the project. Really important to plan ahead.

Paul:
And then the other thing I was going to essentially say for these types of projects is that because of the nature of the more modern front-end stack, there's likely to be pretty heavily JavaScript based. This is even more important and there is a lot of risk here, but it can't be managed if you've got the right consultant influencing the project and working alongside the developers, ideally someone with experience of working with these kinds of technologies.

Paul:
And then lastly compliant. Another really important area for any budget and I know James has got a lot of experience in this area but making sure you're outlining all of the requirements from a compliance perspective and then assigning owners who are then influencing each stage of the project and part of different levels of testing. And again, a big part of the day-to-day of the project, key areas here might be GDPR and some of the U.S. equivalent data protection regulations accessibility, which is increasingly important, particularly in the U.S. and then security as well.

Paul:
And then, sorry I can't see that slide. And then in terms of your technology stacks... I was talking about phasing earlier and I think this is a really important area to think about when you're phasing the project. Ultimately, you could very easily launch an MVP built on a composable architecture then you can then scale up with. For example, here I've suggested an MVP could be an e-commerce platform path, more kind of base level front-end tech stack, a payment provider potentially, and integration platform but not necessarily and then the infrastructure for those solutions. And then from there you could then start to introduce best of breed solutions.

Paul:
For example, PIM is something that I personally advocate a lot to a lot of our clients. And I've seen add a lot of value to the different teams within businesses we write with. You could introduce a higher level CMS solution or a headless CMS or potentially a DXP to give your team more control around the front-end side of things. And then potentially more specialist solutions around search and merchandising, personalization, et cetera.

Paul:
And then ultimately going back to the first point when it comes to defining your tech stack and the solutions you're using, I think it's really important to really understand where you currently are, the solutions you have at the moment, the capabilities you have and then starting from there in terms of what an MVP might look like, and then also your digital maturity and how you're trying to change that and then where you need to get to and what each of those areas look like. And I think that's why it's important to really understand what you need for launch based on what you have at the moment and the team you have, and then plugging the gaps and then starting to move forward from that and having a plan in place to introduce better solution.

James Gurd:
Excellent. Yeah, I think that's a really, really good point. And we speak about this a lot on the podcast. Is this concept of fast follower?

Paul:
Yes.

James Gurd:
And this is increasingly floppier amongst e-commerce businesses is, de-risk in the initial launch because switching over to something new has a lot of challenges and it's stressful. The MVP, you have to be really smart about what you're willing to accept and not try it because everyone just wants to put all their stuff into an MVP and it ends up being not an MVP. Yeah, good point. And the data migration SEO definitely, I've seen project trip up where they've decided that's not important. And then two weeks before launch people are like, "Oh, we haven't solved the technical SEO.

Paul:
Yeah, absolutely.

James Gurd:
The last point we're going to talk about before Paul does a nice summary top five things recap, is resourcing and this is essential. Paul talked about the implications of tech stack, and you can see from the sheer variety of different technologies, you can plug in these days into open architecture systems, is with that you require ownership of each of these areas are not as specific skillsets. And as teams evolve and use more best in breed technology, they might not necessarily have the skill sets in-house to make proper use of those tools.

James Gurd:
And interesting, a report came up from Gardner around the composable commerce in the future, and they said by 2023 they expect 30% of commerce organizations will require an API product manager to help modernize their digital commerce application architecture. So that's not API skills within a vendor like Elastic Path or within an agency partner its internal in their own teams, in the same way that lots of teams are employing engineers in-house for their own development capabilities, like Jim Shore, for example.

James Gurd:
You need to align your organization with cross-functional capability aligned with the business capabilities. You're trying to deliver our actual technology stack. And that might sound like a mouthful, but it's basically mapping business capabilities to technical capability, and understanding who owns each bit of that stack and where you currently have gaps in skills that you might have somebody who's a junior in a particular area and they don't have the seniority to execute the scale you want to, and they need support more senior level. Don't put them into the deep end and make them feel uncomfortable, put the right support around them so that the business can execute as you expect it. Good example is if you suddenly decided to switch an AIML personalization engine and such a merchandising agent then, but you don't have a merchandising team with the e-commerce function. Who owns that? Who will use that tool? Who will help you deliver an ROI out of it?

James Gurd:
The last thing you want is to invest in something you can't get the ROI out of because then people lose heart in the technology. Another good example is, Paul talked about custom front-ends. And we're increasingly seeing these people wanting to take ownership of front-end development in-house. They're decoupling the front-end from the back-end application in recruiting front-end development teams, lead developers, met junior weight developers. But you've got to recruit those people.

James Gurd:
If you're not experienced in running and managing technical teams, do you have the knowledge and experience to recruit the right people? How would you vet people? How do you select the right candidates? And increasingly recruitment, has become a specialist skill within businesses. And some organizations, they are recruiting their own head of talent internally, who then has ownership for putting recruitment processes in place to recruit really good quality candidates, but bringing in people who are aligned with the business culture as well.

James Gurd:
You really need to think about a way your skillset is going and expanded over the next few years and have a plan in place to recruit the people at the right times. And start early because if you want to recruit somebody like a lead front-end developer, good luck and then in the next few months it's so competitive. Trying to find these senior people and in UX as well, you have to be structured and organized and you have to recruit in advance. Paul, over to you to do a nice handy summary of what we've discussed.

Paul:
Right. The first point, clearly communicate project goals with stakeholders and set expectations early on the MVP. I think ultimately that MVP it's important to get as James rightfully pointed out, important to get everyone bought into a real understanding from all key departments and stakeholders as to what that is. Yeah, and I think that needs to be documented and it's a working concept for other projects. Evaluate current team and SI offering and then bring in additional people where you needed. James had some really good points around team there.

Paul:
Ultimately, I think this is a really key part of a project to really looking at, particularly if you are working with a number of different solution. Some of the ones that I mentioned before are examples, but you would likely have a number of other third party areas built into your composable architecture. And ultimately you might need to bring in different consultants, different contractors, you might need to hire full-time head counts. And I think that evaluation piece, which is something that James does a lot with and has a lot more experience than I do around. But you really need to understand who you need to bring in to fill those gaps, and ultimately make the project a success.

Paul:
Get as much of the data migration and content migration done as early as possible. This is, it's a relatively simple one, but I think again, this is really important to really allow you to focus on the remainder of the project, the quicker you get that done the more time you have to focus on other areas and ultimately is really commonly one of the things that delays projects.

Paul:
Create the phases for the roll-out. I think the concept of phasing is really important within a replatforming project, particularly at discovery or pre-discovery. I think I talked about few examples of technology before but there are so many more. And ultimately you want to get that defined early on, the concept of a fast follow-up deployment can be used to your advantage. If you're managing these projects you can start to document that, start to prioritize them around the things that you can deliver beyond the launch. And then the only other thing is always have a layer of contingency, I would say.

Paul:
And then the SEO influence. Increasingly important anyway, but the more kind of modern technologies you're working with the more you need SEO influence and also some of these JavaScript frameworks are stronger than others from an SEO perspective. But if you've got the right influence you shouldn't really be compromising around it, you should be working around it. There's lots you can do there. I think that is a really important part of these types of projects.

Ash:
All right. Thanks, Paul and James, fantastic depths there. One that clearly resonates with me is the first point about setting expectations and what MVP is. I already see a question in the chat. I think we'll have a lot more discussion on that towards the end. But today I wanted to take our audience through our replatforming efforts and Illumina. Just through the presentation, I'll go to an introduction, just talking about Illumina and what we do, and what e-commerce at Illumina even means, why we're replatforming and what is the driver over there, why we chose Elastic Path and then obviously round off with what our journey has been, so far we're currently underway implementing this platform and what's next with Elastic Path, things like these.

Ash:
Illumina, we're headquartered in San Diego, California, and we make DNA sequencing instruments. We have a broad range of customers, global customers in AMR, APJ, Greater China, LATAM. And they kind of go from academic to government, to pharmaceutical, to a lot of different institutions around the globe. As you can see the major ones that I've listed over here at the broad institute 23andmeancestry.com, Sanger. One relevant example of what we do, we recently partnered with Moderna in the development of the vaccine that's out right now for COVID. And we have a lot of other COVID tests that are helping with the genomic surveillance that is required to detect the mutations that are coming out of the new variants that are coming out. We are very, very active in this fight against the pandemic right now.

Ash:
But let's talk a little more about the e-commerce part and Illumina. I think most people when they look at e-commerce, they think Amazon, and I think everybody does that, even I do that. But the model for us is a little different from what Amazon has. Amazon is more business to consumer, we're more business to business, right? Our customers are other businesses or corporations buying from us.

Ash:
And that comes with a lot of different nuances, right? We have customers buying directly on our website. We have distributors as our channel partners which are value added distributors that come to our site and partner with us. We also have e-procurement channels through e-procurement systems, such as Ariba, Jaggaer and Coupa. Our B2B commerce model is more about providing an omni-channel experience for our customer, which is a little different from when you look at B2C. B2B introduces a lot of different nuances that we have to consider when we are actually replatforming or implementing our e-commerce system.

Ash:
Next slide please. What are we trying to achieve at Illumina? In one sentence and it's right up there, we're trying to accelerate online sales while delivering our best in class customer experience. That became our model. A couple of years ago when we looked at our current system and said, "Well, how do we do this?" Right? We were constantly hitting a wall, whatever you call it, with things that we wanted to do, we wanted to do all purchasing online. We came up with these value drivers that you see on the screen here. We wanted to enable all the Illumina users to purchase online any of the products, regardless of the type. And with the current system, we weren't able to do that. We wanted to deliver a website performance that is global because we have customers all over the world.

Ash:
Our current system is on-prem and we wanted to do something else so that the performance is better. And it actually gave us to the business in the regions because it's very different of how people do business in let's say the America versus in Japan. And we have to cater to those customers, delivering the best in class customer experience. We want to look at performance, we want the customers to come to our site, get through their business of ordering products and check out as fast as possible, right? They're there for a reason. They know what the products are, they know what they want to buy. We want to get through the process as soon as possible. Performance is a key factor. And then we want to ensure long-term stability. And back in 2019, I think IBM sold... Our current system is IBM WebSphere, and they sold WebSphere to ACL, which is more of a services company.

Ash:
I think there was a generally anxiety in the industry with the sale, as to how WebSphere is going to be supported. Now, I don't want to say that that was the factor that caused us to replatform. We were thinking of replatforming even before that just because of the capabilities that we wanted to introduce, but this also added to that motivation.

Ash:
Next slide, please. Let's talk about motivation and what really... When we started diving deeper into why we want to replatform, we took a look at the current state, right? And we wanted to make these bold changes to our e-commerce system. Our current state, we had so many issues with the subpar customer experience growing up in cohesive with purchasing, technical limitations, revenue growth challenges. We couldn't provide our customers with capabilities to redeem quotes, the slow site performance always was a hindrance.

Ash:
If we look at the statistics guard abandonment was a key factor. Obsolete technology, the technology that we were on, when we're talking about something that was built years ago we talk about all these monolithic type of systems that are outdated. They're slow-performing limited capabilities. And then what that resulted into is rapid a manual task for our internal stakeholders, our customer care, our customer service people, because our end customers were having so many issues with ordering online. They used to call in and they probably still do because that is the life system right now. And then they have to be handheld through the ordering process, right? That takes a lot of time from our customer service people.

Ash:
So taking that, we wanted to make a huge shift, right? In the channel adoption. We wanted to increase channel adoption because one drives the other. The channel adoption will drive the acceleration of the online sales, right? So where do we want to be? We kind of put that in place, what the future vision is, that as you can see, I'm not going to go through and read through all of that stuff but the main thing for us was to get customers purchasing online as much as possible while mitigating and eliminating all of these issues that we are facing with the current system.

Ash:
Next slide. Let's take a look at the technical perspective, right? We went through a lot of the business side of things as to what we wanted to do, what the customer experience wanted to us to be, how we can help our internal stakeholders, all of that. From a business standpoint, we looked at all those different factors. But the technical perspective for us and me being the person who runs these systems and runs the themes that runs these systems, we wanted a cutting edge technology, but with a focus on the fundamentals, right? Obviously we wanted to take this system that we have currently from our on-prem data centers to the cloud. We're going to go to AWS. We're going to deploy this in Amazon Web Services obviously.

Ash:
Then let's talk about microservices. I know that these are almost like buzzwords that are thrown about, but this is not, to be honest not a very new concept in the sense that APIs have been there for a long time, services have been there for a long time. What I'm happy about is that it's now into commerce and it's now into software solutions that facilitate e-commerce, right? And that is driving the shift and it's really cool. Container deployments, and that's what we're going to do. Okay. Restful services and I know elastic but has level III which is just fantastic, it is like the cadillac level of restful services.

Ash:
But again, coming back to the fundamentals, all this ties in with things like the solid principles of developers, right? And the single responsibility pattern, the S in the solid stands for that. And having these Lego blocks, if you will, what we call composable objects, the composable parts, that single responsibility pattern really fit and really hits home with these kinds of technologies. It goes towards a more strong and more robust CIC pipeline. And we want to be agile. When I talk about agile, it's not just from a software development standpoint. We want to be agile as to releasing features to our customers as soon as possible in minimum time. It's customer experience, as well as the feature functionality that we want to release to our customers. And with an antique way to exist and that's not possible, but with a composable, a microservice type of a system, it's very easy to do that.

Ash:
We really wanted to go towards something like that. We thought about headless and we looked at a lot of different technologies, and then given our business, we've always known that the UI is something that we have to completely customize. And this gives us a chance to have a UI that's more cutting edge, that's more bleeding edge and plus a chance to create that customer experience the way we want it and not be hog-tied by the system that we're implementing.

Ash:
Why did we choose Elastic Path? Elastic path was chosen after a rigorous RFP process in the world five different vendors. But for very high level points, when we looked at the total cost of ownership over the next four years, obviously it was a no brainer to us. The platform capabilities are amazing. And we went through a POC with Elastic Path before we even signed the contract with them. And it was really, really amazing to see some of the critical capabilities that we wanted. That we prove that out that we can do this with the system.

Ash:
The level of support, again, the engagement that we had from Elastic Path was fantastic. They really understood our concerns. They were more than happy to come and do a POC with us even before we signed a contract with them and it was very successful. And then the extensibility and the alignment with vision, right? We know where we want to go and we know Elastic Path understands where we want to go. And I think from a partnership standpoint, it's going to be a fantastic, fantastic journey.

Ash:
Next slide. Let's talk about Illumina's journey with Elastic Path. Like I said, we are currently in underway implementing this platform with a goal of going live in May of this year with phase 1. The way it started was obviously from a discovery phase we went through the rigorous selection process. Like I mentioned we proved out some critical capabilities as the next step in the process with a POC with Elastic Path, now we're on the way, right?

Ash:
We are in the phase 1 of a go live. What we're doing is this is not a project, it's a program. It's not a sprint, it's a marathon, right? It's going to go on for a couple of years until we completely have all the features and capabilities that we want to give our customers. Once we go live with phase 1, there'll be other phases that come, enhancement and iterations that is going to continuously enhance the e-commerce system, and we could be partnering with Elastic Path to see what capabilities we can leverage. That's kind of where we're heading. What's next is the transformation of our e-commerce ecosystem. This is our fourth step, very excited to go live with phase 1 in May, and we'll see what happens next. With that, over to Shaneil.

Shaneil:
Nice. Thank you so much Ash for giving us that insight. I know like Illumina many businesses once only had two options branding in. Next slide please. Two options, on one hand we had traditional legacy platforms, right? And those can be very appealing because there were safe, could get things up and running quickly, but they're often too rigid. On the other hand, we had fragmented microservices that really empower you to create innovative experiences but they tend to be way too complex and risky to stitch together.

Shaneil:
What we want to empower people to do is to stop compromising. No longer will you have to compromise these two options because there's a third option with composable commerce. Now, compostable commerce is a business centric approach, for people who don't know, that leverages a modular architecture and an open ecosystem to rapidly build and deploy commerce experiences. For business centric solutions, we have quick starts for building your solution and business tools that grant the marketing team to take control and make changes and remain competitive. So no longer will you have to rely on your technical teams and your IT teams to make changes.

Shaneil:
The second thing is the modular architecture. We can leverage flexible technology like JAMstack for your front-end and MACH based technology for your back-end, and as well as extensive developer tools. So this is giving your team the extreme flexibility to continuously customize and design unique and differentiated commerce experiences.

Shaneil:
And lastly, the open ecosystem. This consists of a library of assets, integration frameworks, and complete guidance and support for composing your full solution. No longer will you have to worry about vendor lock-ins and there's an open integration framework for you continuously to develop and optimize. So what does this mean for your team? When we talk to business users, what do they ask for? They need speed and they don't want to wait six months for IT to respond. They're getting less time and costs you can deliver and faster... Sorry, can everyone hear me?

Ash:
Yeah.

Shaneil:
Okay. Deliver innovation faster and reduce risk and cost. And you can differentiate in the markets and just continuously optimize without that reliance on IT again. For the technical users, when we ask them what they ask for, they want the ability to keep up with the business without breaking anything, right? They can leverage prebuilt solution to innovate faster, gets up and running quickly in weeks. And then also lower the learning curve, which means it's easier for hiring.

Shaneil:
And then lastly for developers, what do they ask for it? They want to consume services and they also want docs, demos, SDKs, APIs. And this has given them more control over designing your solution. If you would like to join over 250 brands to get the control of DIY, of the simplicity of Shopify as enterprise scale, feel free to reach out to us. We've worked with many different brands developing unique commerce experiences, and we would be happy to help you. If you have any questions now is the time.

Brianne:
Great. Thank you so much everyone. We have had a flurry of questions come in, if you have not yet submitted now is the time to do so. And to kick us off, we've got several questions around MVP. How do you define an MVP for an organization? With that, I'm going to hand it to James to answer that first question.

James Gurd:
Excellent. A million dollar question. Lots of arguments, that's how you there. But the reality is for me, I have a starting point in which is, what do you have to do? Number one is you have to be compliant otherwise people go to jail. You've got to tick all the compliance function, your platform has to fundamentally achieve all those. So GDPR over in Europe, you have the equivalence in other countries, ADA, from an accessibility point of view, all those things. PCI compliance for payment, those are non-negotiable.

James Gurd:
Then you go on to functional capabilities that the business needs in order to satisfy customer demand and in order to trade and be profitable. Everything that you currently rely on to sell online and generate revenue and the customers use properly and frequently in order to interact with you as a business, then has to go in because if you materially deteriorate the service to your customers, you compromise yourself commercially. And if you stop your team being able to execute trading plans, you can compromise yourself commercially. That's always my starting point.

James Gurd:
When people say, "Oh, but we've got to do personalization. Do you currently do it? Is it delivering results? Are you an ROI out of there? And are customers dependent and reliant on it?" And if the answer to those is, no, then all it could be also an MVP that so you want to be in there. And that goes into, okay, well. Depending what ratings, a lot of people use MoSCoW systems, not a big fan, but I have worked with clients a day. That's not a must for me.

James Gurd:
You don't have to have personalization to operate unless you're currently already doing it. And it's already currently part of the reason why you're getting such good commercial rates. So that to me is a starting point, is don't screw up anything that currently works and delivers value to you, your customers, or your internal teams. And think about the internal team there. Don't take away tools they rely on to do their day-to-day job. Yeah. You've got to understand the internal process and admin tool in point of view. So that's typically my starting point with clients where I would advise them.

Ash:
Just to add to what James was saying. I see a question about, how do you define an MVP for an organization that has built an e-commerce platform with less customization? My answer to that is, one, when you define the MVP, again, going back to what James said, we got to look at the functionality. The customization of your current system are a consequence of either some kind of a limitation or something that you needed to do which made you do that.

Ash:
So I wouldn't lead with the customization itself in the sense that you never ask, okay, we're doing this in the current system, that's why we need to do it in the new system. That's not the way to go. We need to look at the functionality and then look at whether we need to customize it. Maybe there's a better way of doing it to deliver that same functionality. You lead with the functionality and then you can move towards whether we need to customize this or not, or how does it work in the new system? And that's how you define the MVP list.

Brianne:
Great. Thank you both. I see a question that came through about recording. Yes, this webinar is recorded. We will be emailing everyone later today or tomorrow morning, depending on how long the video takes to render with this recording. So you're all set there. I see, have a question for Paul here. Paul, can you elaborate more on headless implications with front-end practices? You mentioned SEO and GDPR, can you share a use case on SEO fail when replatforming to headless?

Paul:
Yeah, absolutely. Yeah. I think SEO is the main thing there. And ultimately you just need to make sure the front-end side of things and the JavaScript frameworks you're using you have a crucible version for all search engines. For example, if you're using Angular or React, then you need to use something like pre-render to create a service side snapshot. For search engines and Google is getting a lot better recording JavaScript, but some search engines certainly aren't at the same level. And even then like with Google, I've definitely seen issues in the past, but ultimately it's just a lot more complex. And yeah, I've definitely seen examples of where there's very specific nuances with certain page templates and things like that that have caused issues.

Paul:
You just need someone that's on top of that and is capable of... Yeah, really understanding how search engines according to the site and reacting to any issues, but then also getting everything set up properly from the start. And then just in terms of a use case for SEO fail. Yeah, to be honest, in that side it just needs to be managed well, but the bigger issue or not the bigger issues is that it definitely fails as a result of that not being managed well, but just as important as the data migration and the redirect side of this way.

Paul:
And then from a GDPR perspective, I don't think I have any concerns very well in that, it's just the same principles where you need to make sure you're handling cookies in the right way, you're handling marketing opt-ins in the right way, et cetera. Yeah. And so it doesn't add too much complexity if you're using a composable commerce based architecture, it's just the same principles apply.

Brianne:
Sorry I was muted there. Great. Thank you so much. And there's several questions that have come in for Ash. Ash, I'm going to put you on the spot here. What choices did you have to make as a team leader in order to be ready to take on a headless architecture?

Ash:
Yeah.

Brianne:
And what are your selling points to leadership to convince them to switch from a model to a headless platform?

Ash:
Yeah. Those are great questions. Just from an internal standpoint, to get ready to handle a system like this, obviously you need to build a team around this. And you need to have the right skill sets in the team, making sure that... With headless we already knew that we had to fully build a custom UI and we had already thought of using Angular for doing that. So obviously that was from a technical standpoint, I had to make that choice, I had to make that decision that, "Hey, we need to kind of get this skillset in." The other thing is, from a headless percpective we knew that going to the cloud architecture, which is going to boost performance, we knew that we wanted to go to Amazon web services.

Ash:
It wasn't too much of a choice as such. It's not like we deliberated too much on that, I think it was a given that we have to go to the cloud and Illumina having a huge Amazon account anyways, that was a choice but not really, it was kind of a no-brainer. But from a functionality standpoint, from a business standpoint also we wanted to make sure that everything that we're offering today to our customers is available when we go live with the new system. And given that group completely replatforming all all this functionality has to be built in a very new way, in a more flexible way it's going to be good. But we wanted to make sure that we don't miss out on anything.

Ash:
So that's one, for the second, the selling point was really performance. I'll just say the person who's asking that question is the one I built the business case with. Ricardo Crusoe, he's not with Illumina anymore but we worked together on this. The selling points for both of us it really was from a performance standpoint that was the big one, and from a customer experience standpoint, we were unable or we are unable to deliver the kind of customer experience, the kind of performance we want to offer to our customers because of which we lose people or we cannot accelerate channel adoption and cannot accelerate online sales. Those were the big selling points there.

Brianne:
Awesome. Thank you so much, I will say. I think others are likely having that question too. So a great question for sure. Shaneil, I see a couple of questions coming in for you. Let's start with the first one I received. Is compostable structure still a microservice architecture?

Shaneil:
Yes, it is. It is still a microservices architecture. We leverage and mach based technology. That sounds where microservices API, cloud native and headless commerce. Now, what is different about the composable commerce architecture is that not only can you leverage the small microservices, but you can also leverage package business capabilities, which basically puts these business already functions together rather than you having to stitch together a very small microservices solutions to deploy these specific features and functionality. I hope that answers the question.

Brianne:
Yes, definitely clears it up for me. I have another question here for you. I think it's for you, it says does the product mandate cue-based approach?

Shaneil:
As it relates to composable commerce, compostable commerce is an approach versus a product. But if you're asking about Elastic Path specifically, Elastic Path does not require a skew-based approach. So you have the flexibility to build products in a way that works for you.

Brianne:
Awesome. Thank you so much. I do have a question that came in that I think everyone or I would love to hear from several of you. If you could give one piece of advice to someone about to replatform, what would it be? Ash, do you want to take us off?

Ash:
Yeah. What I think and what is important is that one, do your homework. I know that's a loaded statement before you replatform, but what I mean by that is it's very important for organizations to know their customers and know their products. Because ultimately, when you're replatforming and when you're implementing a new e-commerce system, you need to know how you operate, for us, it was as an example we operate all across the world and there are so many different nuances as to how business is done in different parts of the world. And the e-commerce system that we have to put in place has to take that into consideration depending on where the customer is coming from, right? That's an example.

Ash:
Knowing your products, obviously you need to have a strategy as to what you want to really sell online and where you want your customer service or rather the sales operations personnel coming in to do more high tech sales. As an example again for us, we want all the low dollar value, high volume type of transaction happening online while the more key high-touch transactions for our instruments happening through the inside sales and sales organization because they have those relationships that they're building with our customers. So that would one piece of advice, James.

James Gurd:
Yeah. Very good advice. My advice is don't even think about technology until you've understood your business vision and where e-commerce fits in and the wider business and what you need to do and why and what your goals are. You've got to be really clear on what you're trying to do and why. There are so many platforms out there and each platform can enable so many different things. When you start you've got to know what you want to do and why and what your priorities are, because that's the only sensible way that you can then look at the technology like I suppose you say, "Right, how do we now use this and how do we best execute our business plans?" Leave the technology to after you've done the business planning.

Paul:
Plugging it?

Brianne:
Yeah.

Paul:
Yeah. The same, yeah. Ultimately for me I think once you've gone through that exercise James talked about, I think really trying to understand the gaps and you bring in consultants in if they're needed for me would be the main, as an example, that SEO point there, for some reason I've ended up touching on SEO quite a lot. I think you know that's a really important thing to have the right level of influence in, same principle applies if you don't have the right PAs or if you need to bring in a technical stakeholder internally, or yeah if you are doing a PIM project, bringing in a product owner for PIM, I think ultimately that's really important. And it's not always needed, but in my experience, it is usually is particularly for a bigger project.

Brianne:
Awesome. Yeah. Shaneil, what would your advice be?

Shaneil:
Well, firstly, I would just at the very beginning really evaluate your current solution, what you're trying to achieve, and then also looking at your total and planning for the future. A lot of people, they think about their implementation costs, the very upfront costs, but there will be changes that come along down the line, you will want to optimize your solution. You will want to react to change in customer habits. You want to react to things like the pandemic, we don't think about those things going in. Not just thinking about your first year implementation, but also your year two, year three changes down the line that should really help to narrow down the type of vendor that you should be choosing or the type of approach that you should be using as well.

James Gurd:
Just one thing to quickly add to that. The reality is that technology doesn't solve all your business problems.

Shaneil:
Yeah.

James Gurd:
And I think somebody pointed this out in the Q&A, it's a really good point is, you're not going to fix every issue in your business just by moving technology and you'll create new challenges. You've just got to think very carefully about what you're doing and why, and understand the implications, because nothing's perfect, nothing can be. Technology and people we're all prone to failure, right? It's the reality. You've got to go into this with open eyes and realize that there are challenges along the way, and don't be disheartened when things do go wrong in projects. As long as you have the structures in place, you can handle it.

Shaneil:
Even more, reason to pick a solution that allows for changes and innovations, because you go in and you want one thing and end up realizing that that's not the right fit for you. And then get getting stuffed really affects your budget and then also your customer experience. So really finding that solution that will allow you to change throughout your entire e-commerce journey.

Brianne:
Great. Thank you all. At the right time there's more questions we can get to but if you left your name, we won't be able to follow up with you after. And thank you all for joining us. I had a great time and definitely learned a lot. Thank you to our presenters and to our attendees as well. Your engagement and questions have been phenomenal. So with that goodbye and hope to see you all online.

Shaneil:
Thank you. Bye

James Gurd:
Bye everyone.

Ash:
Bye everyone.