 All right, welcome everybody. Make sure you're in the right session. You're here for serving diverse business needs with one Drupal platform, a story about Panasonic's digital transformation and adoption of Drupal 8. Today, we'll cover some brief introductions. We'll talk about the story of transformation at Panasonic. We'll also cover digital transformation and the customer experience in general in terms of the transformation activities at Panasonic. And we'll take a look at some of the pieces of the digital ecosystem that were associated as part of the project that we worked on together with Panasonic. We'll touch upon what it means to go API first in a web redesign and a digital experience platform project today. And we'll take a look at some specific points about Panasonic's journey in adopting Drupal 8 in particular. We'll close by taking a look at some of the results, and we'll have some time at the end for some Q&A. Quick word about myself, my name is Dave Sawyer. I'm a lead optimization strategist with FFW. I worked closely with the FFW team with Panasonic on this project. I'm here today with my good friend, Rohith, here, who I'll introduce momentarily. If you haven't heard about FFW, we're a global digital agency. You can stop by and visit us at the booth here at DrupalCon. We provide a range of strategy, UX design, and web development services. And we're one of Acquia's leading partners worldwide. We've got about 250 Drupal specialists and over 120 Acquia-certified Drupal developers on our staff. We're also a proud Drupal Association Signature Supporting Partner. And we're a sponsor of DrupalCon Nashville. Very glad to be here today. You can check out about our Drupal contributions to the community at Drupal.org slash FFW. I'd like to introduce Rohith Yuneni from Panasonic. We are doing. How's DrupalCon been so far? I was hoping a bit more high at tone, but I know it's after lunch, so I don't blame you. All right. And thanks for the intro, Dave. Again, my name is Rohith Yuneni. I work with Panasonic within the North American business. I lead the digital strategy, architecture, and development groups here. Been here with Panasonic for about three years. Prior to that, came from the management and starting world, open source, and other areas. And then I've been focusing primarily around the digital architecture. Higher? Oh, thank you for that. Better? All right, cool. Start over? Good. All right. So as I was saying, again, Drupal's been a really special platform. We'll share some really good insights on how our journey has been in the last, let's say, a few years, but primarily the last year around Drupal 8. Again, a quick intro. I've been leading the digital strategy in the architecture areas where part of the work is dealing with open source platforms, but also expanding the strategic area for Panasonic as a business in North America. We are an entity within the larger Panasonic group globally. As a quick and sure of hands, I'd say, how many of you have been using or used Panasonic products as an end user? Oh, cool. So some of you know us, so great. And here's why I ask. This has really been a story of transformation. Panasonic, as a consumer, and I've been using Panasonic, I think it was my first cardless phone when it was way back when. And evidently, we just figured out when we got into the room, we were actually presenting through a Panasonic projector. So yay. But we didn't plant it there, so you're wondering. So again, getting back to the session, part of the story within North America with Panasonic, the world has been knowing, have known us as a consumer brand, building a wide range of products and, of course, a lot of technologies that we support various companies with. But at the crux of it, Panasonic's in North America business is a B2B company, a small portion of our business is actually a consumer, which is a good sign. So it's actually facing consumers. And we support a lot of businesses, governments, industries, in a wide range of things that we do. And part of this transformation journey and the way we engage with Drupal and specifically aid and FFW has been, how do we take that messaging out into the market? And how do we transform the way we connect with our customers? So we have a nice video to share, which we just tested the speakers. I think they're working well. But before that, this is the 100th year of Panasonic. And part of that transformation story and why it is a great time for us to be here has been we've been doing a lot of things over the 100 years. As you can see, there's that statement around what have we been doing around the 100 years and the 100 years of ideas. So it's a celebration, but it's also a tipping point where we say, let's change the way how we plan our next 100 years. So we have a nice video to share. Hopefully you'll enjoy watching it. Let's get that going and we'll get into the session. Technology, it inspires and amazes us. Moves us forward, unlocks our potential. Technology innovations allow us to create abundance out of scarcity and energizes our perpetual ambition for progress. And today, in concert with a wide range of elite businesses, the company that consistently strives to innovate and reimagine the technologies that move us forward is Panasonic. Panasonic is bringing to market integrated technology solutions that guide us through our daily journeys with newfound ease and grace in cities and factories, in automobiles and airplanes, in restaurants, stores, and stadiums. We're advancing new technologies like the Internet of Things and sustainable energy, cars that drive themselves and factories and homes that create and conserve their own energy, fixtures that emit not only light, but data, and solar lanterns that illuminate the night for students off the grid. We're developing materials that capture geothermal energy and allow smartphones to cool themselves. We're making communities more secure with advanced public safety solutions and intelligent highways. And as we have for generations, we're doing this with the same clear mission that has driven Panasonic to create new technologies for 100 years, to make life more fulfilling and the world a more enjoyable and sustainable place. Technologies that move us toward a better life and a better world. The reason I played that is just to set into context what we're about to talk here. And also, there are a couple of things that were mentioned very predominantly during their journey is Panasonic in North America has been a big solutions provider to wide-ranging industries, but also how we actually are changing the way certain things work, all the way from electric cars to the way roads can be constructed in the future and many other things. Digital is a component of it. And if we go down to the next slide, let's see. Oh, let's try to make that work. Cool. All right. Here's an interesting quote. And part of that transformation journey has been what's changed and how is it accelerating, right? The big shift that you've seen in one of these really interesting quotes I'd like to bring up is the amount of change and the speed of change has significantly grown. And here's an interesting, let's say, a comparison and the pace of how we're growing. APIs are definitely a component of that. And we'll talk a little bit more around how that's contributing to that overall speed of change. And where is all this progress driving? There's a recent McKinsey study, which I think it's been a while since it's come up. And some of you have read it, hopefully, is these are right now being proposed as the disruptive technologies that will change the way the industry will grow globally. And it's a global study, I believe, from McKinsey Global Institute. And at Panasonic, we're not just keeping an eye out on these trends. It's also, we're looking at ways where we fit in and we're at the forefront of innovation in many of those industries. And if you look at this, and here's kind of a quick mash-up, which says nine out of 12 of those disruptive industries, Panasonic is already a leader or has been a major player on it. So with that said, our digital transformation and the journey, the big challenge for us was how do we take this story out into the market? Not just bringing a new platform to enable digital presence, but also the story and the way to go to market around that. And right now, we're fortunate to be working with some of the top names in the industry. Here's just a quick blurb of them. And mostly as a solutions provider, anywhere from government to the airlines to data centers and so on and so forth, and cars in some cases. So with that context set, we'll get into them, the crux of the today's session, not to take too much of the intro time. So we'll focus a bit about marketing in a digital world and more and how our journey has begun, right? How did we end up with Drupal 8? We've been using Drupal and have been in the community, adopted the platform for quite a bit, but when we, and how we got to Drupal 8, I think that's part of what we'll talk about today and also how APIs have kind of been centered in the overall journey, right? So let's go into, okay, cool. So out of the 12 disruptive industries, right? One of the big questions any major enterprise or the new startup that's trying to go in and get a piece of the market share have been asking about is what does it mean to market in a world where there's a huge amount of disruption, not only in the industry, but also about developers are facing, for example, to find better ways to bear and catch up with the speed of business needs, right? As an enterprise, one of the big questions we always ask is how much longer is this going to take or how quickly can we get this out to the market because the industry's screaming for that change to be out there and as a marketer, as a marketing member, let's say within a projector steam, for example, the time is precious, but as a developer, there's time you need to spend to get a quality product out there, right? So that's where we see APIs as part of their digital transformation journey. They have been a core component of how we can innovate and how we can innovate faster and in the context of just building a digital journey. So let's see. Right, so I'm not gonna focus too much about the market. Let's get into the big question, right? And has been thrown around for quite a bit and many of you may have been reading through it. What is digital transformation? Any thoughts? Any phrases that someone can chime in with? Sure, change is a part of it. Sure. Anyone else? Sure? Sure. Sure, yep. All right, so here's, that's actually a good point, working smarter, that's part of it, right? And change is, I'd say a driver to get that, right? And here's how I see it and again, as Panasonic and the way we operate within internally, for some, it's obviously about technology, it's definitely a key driver, right? For others, it's just a new way to engage with customers, which could be on a mobile phone, which may not have existed years ago, right? And for others who startups or even enterprises that are transforming themselves, it might mean really creating a new business model of actually reaching their customers. Disruptive areas and also the regular ones, right? Could be government who are making really headways in how they actually go meet their constituents or hear their stories and things like that. So that's a great simple way to define digital transformation. The net out of it would be, it does not mean a single thing, it means many things, but it's usually positioned into, however you wanna put it. And for an enterprise, what does digital transformation look like and mean for an enterprise? First thing is creating values, working smarter, yes, and driving change to create new value, but it could be for an internal team, it could be for a development team, it could be for a larger shareholder group, right? Creating value in the core business, which is if you are a solutions provider, what are the areas that you can innovate on or build services on that can help you take your business faster into the market and in a better way, right? And most importantly, building capabilities that enable you to innovate faster in the future. The reason we had one of the key terms, API first, embedded and pasted all over the agenda of today's topic is that's a key component of what it means to be digital for the future. Digital now is getting there, but again, it's about how do you build that foundational capability today so you can accelerate your business for that future. So here's a quick way to look at, someone mentioned change, right? So I'd like to use that and tie it back in. Digital transformation is certainly about change, it could be as small as a particular team doing a certain thing in a certain way as opposed to a large enterprise going to the market in a completely new way. So here's a simple way to say what does it mean to start with change and how does digital transformation start with change? And the first thing is obviously challenge, always challenging the status quo, as a team, as a company, as an industry, right? Culture, culture in the organization and of course most of it could be driven depending on what type of organization you're in and what industry you're operating in. Startups may work in a completely different way than a large enterprise which has been around for over 100 years, right? But again, transformation, the faster you change or make that change, you're better equipped to meet that future disruptive demand. Experimentation, it's important and I'm hoping there's a good development community here in the room and obviously a lot in the building. Experimentation isn't something new but the scale of experimentation is pretty important when you talk about transforming your business to meet a huge industry. And I think I have one more, integrating. How well can you integrate your digital applications? You are, I'd say you're stuck in this case across the enterprise. And digital technology, I actually wanted to put up a slide where it was the MarTech. I don't know if many of you follow that where there's about over 2,000 marketing technology companies and pieces out there. I thought you'd get bored with it so we took it out in the last minute that explains the speed at which the marketing and digital technology, as a solutions provider, they've been innovating, but it also explains the demand that other companies are looking at for those type of technologies, right? So the key question there is, how do you integrate all these different things? In the past world, there was obviously the advertising world where it was fairly straightforward. You had someone running your advertising campaign, you had advertisers in-house or outsource most of the times, but as companies are bringing in more and more digital technology, it's even more critical on how they actually use APIs and other concepts to better integrate the technologies within the company. Here's one example, what it means. The fundamental shift that's been happening and part of my role at Panasonic is I leave the architecture from a digital group perspective and one of the big challenges is how do we make two teams talk to each other, but also how do we make things that two teams run across the board talk to each other? And it's critical from an architectural standpoint because at the end of the day, if you're trying to solve a business problem, the technology shouldn't be the barrier, it should be an enabler. That's one of the key things that we believe in and kind of preach internally is don't make or don't create the barrier with technology, use the technology or any particular solution as an enabler so you can get out to the market faster. So as you can see, this is a really good summation or a simple table that I was able to find around what's the fundamental shift? And I'll tie it back to what it means to Drupal 8 in a few minutes, but at an architectural standpoint, the traditional model has been you focus more on the product-to-service related businesses and the way you source technology and the way you build technology would be focused around those traditional ways of doing business. And one of the key, I'd say, kind of the buckets around how enterprise architecture and the shift is taking place is you need to be positioned as a perpetual evolution. I know that's a heavy word and Dave was warning me, you may not wanna throw that out there, but I'm gonna do that regardless. What I mean by that is it's another fancy way to say continuous evolution or grow continuously, but as you see, it's this fundamental change in thinking around how do we use web applications, how do we plan web applications and how do we wet new technologies as they come on board and the fundamental pieces that we need to carry those forward with. Here's what it means drilling down or breaking it down, right? Decoupling, decoupled Drupal, decoupled many things. That's something, I think there were a couple of sessions this week as well on that, but if you really get down to the bottom of it, a monolithic architecture, which has been there around third well in various levels of the companies and the technology frameworks, code testing, integration, that's the architectural view of how it works. There's always the approach of waterfall, agile, things like that that exists, but that's not really what this model talks about. This is what does it mean to be fully decoupled as in what does the independence of each component of your stack or each component of your development process really look like? The dependencies among your stack are what, and as a company Panasonic, we have a lot of business units with multi-billion dollar revenues and they source a lot of technology themselves that rely on us where we bring in an enterprise wide technology and run those for them. The biggest challenge is how do we make them work with each other, right? And we don't typically own every single piece of that code or every single piece of that stack. So the more dependencies you create as part of the stack, it obviously creates a fundamental issue on how do you scale, right? So this perpetual evolution model and the decoupling in its principle is essentially how do you decouple each of these layers within your stack or an application per se, including Drupal in this case, to meet those growing demands, to meet those growing changes within the market, right? And Rohit, if I could add, in the context of a web application or a responsive website, for example, certainly in a large enterprise organization where there are many data systems that may need to be integrated, it can be a big leap for companies to go from a very tightly coupled implementation to a completely decoupled implementation and I like to think about a sort of a slider or a range anywhere in between completely decoupled and the opposite end of the spectrum and in many cases it can be helpful in thinking of this idea of perpetual evolution and continuous improvement and development to think about decoupling certain pieces or using progressive decoupling and heading towards a fully decoupled goal in the end. Thank you for that. So with that context set around decoupling, the changing view of an enterprise architecture, the larger context of digital transformation, as I focus mainly on digital, I'll talk a little bit about what it means from a customer experience standpoint and what it means as a marketing organization, right? So this is a simple view and I'm not gonna go through it in detail, but the point there is what are those different dimensions of a changing marketing organization in this truly digital world, right? There's a lot of research out there and a lot of data points that get thrown around or how many people are actually using mobile to find information. Obviously, in a B2C world where you're directly selling something to the end user, that number usually spikes and as a B2B organization, we've been increasingly seeing where those numbers actually been growing more than 50% that most of your customers, including governments who may come to you, have been doing those research way in advance before they even touch you as a brand, right? So websites and being able to tie these things together, multi-channel campaigns, personalization, all the buzzwords, I'd say, is increasingly critical and that's where APIs and digital platforms have a really, I don't wanna call it a love-hate relationship, but there's obviously a lot of love around that which is how do you use APIs to create a platform that can extend itself but also help the teams extend it for you? That's the way you build a network around that. So we'll focus the rest of today's time around API-first approach and the digital platforms. Digital platforms, as you can guess by now, is what did we do with Drupal 8 and sharing a piece of that journey? There you go. So when we started with this approach and part of our journey has been, we've taken a fundamental look and built what we call as a digital caution, which is we essentially assessed every single team, the way they were going to market, every single website that they handle, so on and so forth. And we said, we'll need to take this big blob, put it to rest at some point. Before we do that, we have to take a holistic look of how we begin migration to a new platform but most importantly, what's the mission statement, right? So as part of that larger initiative, we came up with really simple two phrases or two lines in this case. One, how do we as a company create a best-in-class marketing toolkit to increase Panasonic's P2B awareness? And these are really critical, more than you would think, where Panasonic has about 200,000 plus employees and a few hundred, it's about 12 to 15,000 in North America alone. Key portion of that is how do you explain what you're doing within your company but also as an organization and as your team, what does it mean, right? So part of that change, I think I'll give him the points again, how do you explain to someone what does it mean to change? What does it mean to bring a new platform in like Drupal 8 into your day-to-day jobs for a marketer? So we started with these two simple mission statements and they've been serving well so far, right? They're not very granular and that's for a reason so that leaves you with enough room to plan your journey internally and also externally. So API first, what is API first? I think I missed my animation there, but... So the first question that anyone would ask is what is API first but also what does it mean to you as a developer, as a team lead or as a company, as a whole, right? And we try to explain what does it mean to us and what does API first mean in a general context and learning from our last year's worth of journey building a true digital platform. The name is very well thought out what it's called as API first where you're not essentially building a large platform and then thinking about an API. API first, in its name, it's a really great way to talk about, you think about API in the beginning of the process and obviously all throughout the project but if you're building a new website or you're building a new product, it could be a digital product, think API first. So that's a key way to describe what it means to go API first but at the outset it's more about how do you build a web service, decoupled enough that it will allow you to extend your platform. And in the context of Drupal, obviously we have to tie it back in, API first means making, and I think we pulled this out of the Drupal API first project mission statement is API first means making the data stored and managed by Drupal available for other applications. Again, a fairly simple mission statement. What it means is regardless of what you're building, plan ahead, regardless of what type of application you're using Drupal to Power could be an application for a fire department, I think they were presenting yesterday and it was a great story there how they were using Drupal 8. If you're using a true CMS and saying we'll use Drupal to Power are 10 websites. How can you go think API first to build a service that can expose data out of that website for the future? And of course that allows you to get a lot of benefits inherently. The first one that we've seen work really well so far is how quickly can we actually use those APIs and build new services on top of that? One of the great correlations you can make is for IT teams who in the past hosted and managed their own server infrastructure, had their own DBAs and so on and so forth in-house had to manage a lot of that infrastructure as a whole. And you can almost draw a correlation between infrastructure as a service, the IAAS, what it meant to the IT teams, the power that they were able to get as an enterprise. We consider APIs as a similar, if not greater set of freedom for a developer because you're interacting with an API which has potentially a set public contract. You have someone else managing the core of that API and the data that it may expose, but you're focusing on the service that you're building, you're focusing on the specific use case that you are trying to achieve. Right. And if I could add, the Drupal initiative has its own API first initiative which you can read more about on Drupal.org but to put it in perspective for those of you that have been in the Drupal community for a long time or have been site building or developing with Drupal a long time, if we reflect back to earlier versions of Drupal, the Drupal itself was very highly coupled and it took extra work to expose data and make it available to other IPAs. And as we look at what's going on with Drupal today, we see that Drupal is much easier to set up in this way to expose data to services and APIs. This API initiative describes what Drupal is doing in this way and there are now Drupal distributions such as reservoir which allow developers and companies to get set up with a decoupled sort of API first Drupal platform and to build out systems and applications in this way. Sure. And that was one of the key factors that as we set out to bring a brand new open source platform and we've adopted, we had adopted Drupal seven a few years ago, globally as Panasonic and also in North America and we were familiar with the Drupal community using it to build very custom applications. And then as part of that re-platforming journey which we'll talk about in a few minutes how we started that process, API first and being able to use APIs across the board, we were looking for the platform that in its DNA and had an initiative and having such an initiative and an open source community with over a million developers already adopting a certain way of building specific modules or applications with platform. That was a critical piece of that puzzle that we wanted to adopt as we started fresh. So someone may ask how do we transition to API first but also what does it mean for us? We are a traditional development team for example, how do we go API first? Here's a, I don't know if people in the back can read it but we wanted to be simple enough but have some facts out there. So here's a quick way to overlay in three dimensions and there may be hundreds more but we'll focus on top three. In a traditional development channel versus an API first channel. So API first development in its DNA, I would say is more of a strategy which is where you put the developer's interests first and then build the product on top of it. Think about it for a second. The typical life cycle of a project has been you get the business requirements, you know who your end customer is, you define the user story around it and you're building that application to meet that specific need. So that's your monolithic way, I'd probably call it a traditional way of building an application. Once you build the application you may choose to expose the API as an afterthought or at the outset of the project which is the kind of flip side where you say we'll think APIs first, we'll plan around the data that we need or the services that we need to build and then we build the product around it. Product in this case could be as simple as a website which could use completely decoupled architecture to power a truly digital experience or it could be a really good product that someone's using an open source technology around and building on top of it. So I think one of the things we've seen as a problem internally was these traditional ways of building applications resulted in really artificial APIs. That's a very broad term. Let me maybe be a bit more specific. So think of it as two channels. One, a web channel and a mobile channel, right? So for someone who's developing an application in a very traditional way you could either build for each channel or you could build an API service if you take that same situation and say we'll not build the whole application and then plan the API. Let's think API first where we say the development process for each of these elements of the application stack is a more synchronous way of delivering your application or your project. Once a new service or I'd say once a new feature is built or is in need for development you could have your product teams starting to work, write a prototype, once the prototype is done you have a ready set of users who could actually test your APIs. There's a good example that I wanna use today is primarily around API first, right? Is anyone familiar with an API management console or an API management platform? Okay, great. So one of the things that we've seen when trying to adopt primarily around MarTech, an API first approach was how do we build APIs? But also if we had to expose those specific APIs to other members of our company, how do we do that? And one of the key components, it may not be a must have but it's certainly a best practice in my view that out of experience is how do you utilize an API management platform with let's say a set contract which is an API contract where your team is building an API service with the view of exposing data. It could be a product database storing thousands of products or it could be some form of a transactional system with hundreds of data points. So once you build an API, how do you expose that to other development team members within IT, your third party agency supporting some form of the business team, so on and so forth. So one of the key aspects there is having some form of a console and some form of a platform that allows you to expose and allow other teams to innovate on top of a base API that you have built comes in fairly handy. And one of the key aspects I mentioned earlier is we're seeing governments and I recommend you take a look at this. This is the US government's, I believe it's called the GSA, General Services Administration. They have a team called 18F and they've fundamentally started rethinking how they actually offer services for parts of the government. And it's the same concept. Someone within the company is trying to be the accelerator to thinking and going into each functional area. Identifying areas or points that can be converted into API first or converted into a service that could be extended and other teams could essentially build on top of it. So I'll have the website up at the end. I think it's called 18F.gsa.gov. Certainly take a quick look. And they obviously publish a lot of really great material out there that could be used for private and obviously public sector companies. Let's jump on to the next one. Rohit, make a comment. We're talking today so much about the technical side of the conversation and as you framed it, putting the interest of the developers first in this API first approach. I think where this gets even more powerful is if you apply this more granular component-based approach, not only on the technical side, but on the design side. So for example, a design process like atomic design or a component-based design system where you're designing individual reusable components fits really well with this API first approach on the development side. Sure. Yeah, and again, this is just a quick mash-up on what it means. And we'll talk a little bit about with this context around API first, those are just a quick few blurbs around what we set out as part of our largest strategy and what we'll build next and what it means. So I'm gonna hand it over to Dave who's been a key part of the team as we engage with FFW and North America. So he'll share a bit about our journey and what it meant going Drupal 8. So I'm gonna hand it over to Dave. Thank you, Brogat. So where does Drupal 8 fit into an API first model? So as we've said, first of all, Drupal 8 itself is a huge leap forward in terms of previous versions of Drupal of working in this way. There are a number of modules which we won't get into in detail today, but for those of your interests, you can look up the JSON API for example, the services module for, which has been around for a long time. Tools that are available that allow you to use what Drupal is really good at, which is managing structured data and then exposing that structured data so that it can be consumed by other platforms and systems. This quote is right from Dries's blog. He said that I'm convinced that an API first approach will be a critical addition to Drupal's future. So if you're looking at adopting an API first approach in your own Drupal development practices with Drupal 8, here are several areas to focus in on. Number one, looking at where silos of customer data live. Part of the interest that's being driven by marketing needs is being able to get a more complete view of the customer and understand the customer data better and to be able to connect data that may exist in silos. And this API first approach is really helpful for being able to connect the data that exists in separate systems. The ability to scale marketing needs by being able to iterate quickly to develop new applications or new components because you have the data that you need to pull into the application as opposed to having to do development to gain access to that data. Couple other pieces, control over your own roadmap, just having more flexibility to make decisions and pivot quickly. Taking advantage of the open source community, not being tied into a specific platform or technology but being able to tie together a number of systems to create just the solution that you need. And of course data and personalization. As we start to expose data, connect data together and inform marketing about how customers are interacting with the brand, we can start to target and tailor the experience using that data to meet the individual customer's needs. The idea of a digital platform really is that a true digital platform will scale with the business's needs and the API first approach really puts you in the right position to be able to do that. So if we take a look back at how we worked with Panasonic on this particular project that we're talking about today, this slide summarizes at a high level what that process looked like. It began as most large scale projects do with an identification of needs, defining requirements. As we've said, thinking of the API first approach at that early stage of the game. And then buying into a specific approach or solution, in this case, Drupal 8. Creating a blueprint of what the requirements were for the overall project and how those align to the technical architecture and capabilities of Drupal 8. And then determining the strategy, thinking not only about the technical side and the API side, but the customer experience, the user experience, the digital strategy and how you're tying data together to best serve the customer. Of course, all of the site building, development, testing. And cut over and launch planning. This is an often underestimated area, particularly for a large enterprise organization who's embarking on a very large change like this, making sure that you've planned out all of the different systems that will be impacted by something as simple as a site relaunch or something much more complex in terms of the way that you're routing data from one location to another. And once of course it's all launched, having a plan in place to measure and optimize in a continual way and to measure consistently in that way. So we'll show the website experience in just a moment in terms of some outcomes of this experience. Number one, we leveraged a component-based design approach or an atomic design approach by designing reusable components that can be used across an experience or across other experiences. Number one, at number two, we created a custom Drupal 8 distribution for Panasonic so that not only are the individual components and elements of data reusable, but the whole platform itself is inherently reusable so that as other business units inside of the large enterprise organization start to move to Drupal 8 and adopt this platform that they can leverage and reuse the good work that's been done as part of this initiative. In this particular case, we used a progressive decoupling approach. For those of you who are not familiar what that is at a high level, if you think of a fully coupled experience might be in Drupal terminology, the idea of a theme that is tightly integrated with the backend, so any changes that you need to make to your website or web application, those two are tightly coupled together so you have to modify both. At the other end of the spectrum, decoupled might be, for example, using Drupal in a headless capacity where Drupal is serving feeds of data that get consumed and displayed by a separate application which could be done, for example, in Angular or another mobile framework, front end framework. We used a progressive decoupling approach, which again, if you're not familiar, is sort of in between those two. The idea is that Drupal and its theme serves the skeleton of the page and then individual front end components using, in this case, we used Angular, we'll then dynamically pull in additional data in that way. And then this way we start to decouple components of the site without having to have a complete separation of the front end and the backend. And that gives a development team a lot of flexibility on how to structure the page, not only from the API first perspective, but considering, for example, page load speeds and performance. Some other pieces, personalization, the site is enabled for personalization and collecting of customer data as they interact through the site, making sure the search feature is really strong and is tuned to help the customer get to the information they need. And that's a number of other things. We'd like to show the experience that was associated with this project. At the end of the project, we'll share a quote here from Lauren Salada, who's the chief marketing officer at Panasonic. She said, this was a strategic initiative and a catalyst for change as we embarked on our digital transformation journey. As we continue to transform the way we connect with customers, our new platform is truly an on-ramp to digital for our business in North America. In this case, this refers to the Drupal 8 platform. The platform, which you can visit yourself, just visit Panasonic.com is a responsive website and implements this progressive decoupling to pull in product data and other data from Panasonic systems. We have a video here, which I'll turn on, which just shows some of the site interactions. As I said, you can check this website out yourself just by typing in Panasonic.com. So dad, anything? I think the decoupling and the way APIs were used in this overall implementation was really interesting because in historical terms, we've had a lot of free platforms. We've brought in a lot of new and sometimes custom technologies powering our North American experience. One of the big challenges was obviously the timeline. We had a lot of sites to shut down, so on and so forth. Prior to bringing in Drupal 8 as a core North American web experience management platform, we had, this project was overall done in about six months. The actual implementation was about three to four months time frame. And part of the big, the push was obviously to meet a certain specific timeline, but as we leveraged the APIs, the biggest piece that we realized as we went along the way, both sides, was how quickly we could actually build a service and test it with a beta user group and see how it's actually working. That, in its own way, was we didn't have to build a brand new service to pull in about 2000 product data points. Those component-based design components that we adopted from a design UX standpoint, but also at the back end of the CMS itself where content editors had ways to actually taking action on a specific component, et cetera. The component was tightly coupled in the sense, or decoupled in the sense that it was not a specific area for template, but those were reusable and rearrangeable components, which could pull in data from an API from a system that's holding tons of data. So right now in the US side alone, we show about 3,000 plus products as a whole for North America, and we have other pieces of the puzzle which might carry larger portfolio aspects, but about 70 to 80% of those 3,000 pages are all powered through an API service that's pulling data from the Panasonic's backend system. So we are essentially tying the factory which is building the products, the product team that's essentially specking a product, a projector or a large display. So that whole life cycle of the bear specking by a product manager all the way down to the website is all completely driven through an API service where there's not a lot of copy pasting, which was the case previously. So, thinking APIs and the way to leverage these reusable components across in a site, which is again, this is an experience layer of the overall architecture, but that whole life cycle has immensely benefited just within a small group of teams. So we tested that with one of the business and then we obviously rolled this out across the board. And that's one example, and obviously this is a, almost served as a proof of concept with Drupal 8 where we ID8 and see how we can leverage APIs to power a large initiative within a really tight deadline, which is again about three to four months with thousands of pages and shutting down about 10 old platforms. So that was one of the key learnings from the journey, but also that is setting us up as where do we take the platform next? Part of the roadmap in Lawrence Court was very interesting around, this was more an on-ramp digital, so now we're finding ways to take Drupal 8 and how we leverage Drupal 8 as this content engine which is powerful in its own sense and use the power of APIs to extend to other channels and tie this whole journey in North America and of course expand that to other areas of Panasonic as well. So that's a bit about our journey and I'll let Dave close out. Yeah, but Rode, I'd love to ask you if you could share, one of the things that I noticed is as you move from the legacy platform that you were using to Drupal, platforms, platforms of course. I observed that as part of the training and onboarding and getting ready for Drupal 8, more of your team and those stakeholders in the different parts of the site were a little bit less disconnected from the web content and were able to become content publishers. Perhaps you could speak briefly to that. Yeah, definitely. I think that was an interesting turn of events. So historically we've had this centralized operational flow where a certain set of key users had the ability to, oh, sorry, left the left side, had the ability to publish information but also, let me put it this way, raise a ticket, some of you may be familiar with this approach where for you to actually change something on a page, you have to go through a strictly manual process, then it hits a development team, so on and so forth. That's parts of the platforms. Some platforms were smaller CMSs which allowed us to, those marketing users to publish changes. So when we moved to Drupal 8 and this specific API based approach was, we've decoupled that whole area of managing a specification table. So a single projector might carry about 1,000 specifications to make that one small product. And as a marketer, you may not want to manage that part, right? Yes, you might have an agency managing that whole process for you, send them a spreadsheet, they upload it. But there's inefficiency in parts of that process. So by automating portions of the website using completely componentized approach and giving marketers the ability to focus on the area they're obviously great at, which is the marketing messaging and so on and so forth, we were able to increase about five-fold the adoption of the overall system. Oh, there you go. And most importantly, we had users thinking about how can I leverage the platform as a whole and build a better service? So within the first two weeks we launched, we had a large group, I think it's one of the other projector groups, but came in and said, we want to actually extend this platform and sell something to our B2B community. That had never happened before because there was always this conception around how quickly can we actually test this or it's going to take us a long time doing something. So those are ways where we've actually, not only help the users adopt the platform quicker and obviously five-fold, but also they're starting to think where can they add value to their end user? Where can they add value from a customer experience standpoint? But also, again, in the context of the larger digital transformation, this is where it ties in, is how can I build a new business model within my existing business, which can be doing great, but now that I have this base platform taking care of most of my work, what else can I do to create a new business or a new revenue stream, so on and so forth? So that's been the fundamental shift around how the platform as such and Drupal 8 has been extremely critical in the last few months, but certainly we intend to extend that into these new areas where we see a lot of potential. Great. Well, that brings us towards the end of our presentation today. I'd like to thank Rohit for coming to DrupalCon to present his story and thank you all for attending today. We do have a few minutes to take any questions that you might have. Right here. Okay, we can repeat the question for the recording. So the first of your questions was how do you rationalize the investment from a marketing perspective? Is that right? Sure, simple question, complex answer. It's a process. We broke it down into a couple of areas. One, this initiative, this project, we call it the Lighthouse Project, and there's a reason for that. As part of our larger digital transformation initiative, we've identified core areas within our marketing and the digital organization where we can improve an existing experience, but also set it up so we can build new revenue streams and so on and so forth on that. So it was part of a larger initiative. So it's hard for me to say this particular project, but as I said, this was one of the key projects and for a reason we wanted to show the scale and the quick delivery that we could meet. ROI, it depends on how we calculated, but this levels of it, the API itself could be monetized at the end. There's a soft cost that on the time you're saving for a business. As I gave an example earlier, a marketer managing 2,000 pages versus letting the system do that highly manual part. If it's not the marketer managing this, someone else doing it. So there's a model which is based around the time invested, what's the outcome and so on and so forth. Did we get to the second part of your question? Tricky one. Okay. I'll tell you what, in the interest time, we'll take this question. You had a question in the back? Okay, for the recording, the question was why did we decide on progressive decoupling rather than fully decoupling in retrospect, would we change that decision? Sure. I know. No, you can take that first. From the perspective of the digital agency that was working with Panasonic, for one, it was a very large and complex project and a very compressed timeline. So as always with projects like this, you're making the most realistic decisions you can to ensure the best possible experience within the constraints of the project. So that's one factor that would be a part of that decision making. The other factor from my perspective is that in some cases, progressive decoupling is a step towards fully decoupling. And so I would personally look at it as that ways. Those are two factors that led to those decisions. Sure. From a technical standpoint, and also from a brand and governance standpoint, one of the challenges we had in the past was with many websites and many teams managing it, it was hard for someone to stipulate how you represent a brand. So the digital organization, my team primarily sits within CMO organization and that's for the reason, is part of the effort has been if you have to reach your customer and take this complex story of what we do as a brand, the first thing you need to focus on is tell your brand story well, but also how this kind of slides into the, I'd say the fluidity of an experience. So for example, if I'm interacting with Panasonic with 10 websites, the biggest challenge there, as a CMO, you would see is how difficult it is to manage that brand consistency, but also the messaging around it, the content, you can imagine. So part of the progressive decoupling approach was, we've certainly looked at fully decoupled of just building a hard-coded template. So we adopted a strategy called Free Fix Flexible, which was a way for us to say there's areas of every part of the site where there will be stricter brand guidelines. So it's almost like a blank slate with a branding on top of it. So there were areas on the site and as you interact, I invite you to, you may not actually realize that it's a completely, progressively decoupled part of the site, but the experience as a whole remains very similar. So that was one of the parts of the decision as to why we went progressive to implement that 3F strategy as we call it, and of course, minimize the amount of churn we have to have in the future. Fully decoupled is a scenario we are certainly looking at, but for different channel-based approaches, we've had parts of the organization try out fully decoupled to build a mobile service or a mobile application. So there are merits, but again, at the end of the day, as long as you have the core offering of an API which is able to expose data, that probably takes care of half of your work because you're focusing on the end product or your end experience as opposed to thinking about how do I get this data in a structured format so I can build my experience at 100. So we've tried to solve the bottom-most problem which is exposing the data first. And again, meeting the use case is critical because the whole team was about 100 people trying to understand where do we take this, their needs, so on and so forth. So yeah, it really sets your business need but also think about how do you take it forward. Any other questions right here? Sorry, can you repeat that again? Oh. I had a good time last night. I think the question was which API provider did we go with on the project? Correct, sure. I can talk to you offline, but as I mentioned early on in my talk, choosing an API management platform and a hybrid integration platform is critical. Not just to automate processes or just to simplify the way you set up contracts, allow someone to request access to an API, but also scale because in most of your API management platforms it's an IPass service, right? So I can talk to you about the brand and stuff like that, but again, I think it's a critical component of the overall platform. Drupal 8 is powering a key portion of our overall digital experience platform but there's other components that are purpose built or purposefully sourced to meet that need. Yeah. Any other questions? Okay, I think we're right at time. Thank you all again for coming. Thank you everyone. And if you don't mind, thank you. If you don't mind rating the session today, we'd certainly appreciate that. You can find the links to rate and provide your feedback about the Drupal con session on the screen today. Thanks again.