[Music] [Jeff Hall] Well, welcome, everyone. Thank you so much for joining us today. My name is Jeff Hall. I'm with EY, I am in an enterprise technology organization, and I am responsible for our Adobe and our CRM platform. I'm excited to be here today to talk to you a little bit about what we've done with our enterprise, our EY experience platform. But first, let's introduce the speakers today, in addition to myself, this is Barb Dombrowski. [Barb Dombrowski] Hi, everyone. Barb Dombrowski. I'm the Product and Platform Lead for the Adobe products with inside EY. So I was a little jealous last year with the room before us had music. So we wanted to up the game, and so we brought a video this year.
[Akshat Sharma] Hi, everyone. I'm Akshat Sharma. I work as Principal Architect with the Adobe professional services team.
All right. Perfect. Yeah. So, you can go on to the-- There we go. Yeah. So first, before we get started, a little bit about EY just for those of you that don't know us. We are a global assurance tax strategy, transactions, consulting services organization in over 150 countries, 400,000 employees plus. So we're a large global organization that has a lot of innovative and creative employees across the globe that we're working with and trying to support every day. So with that, maybe let's go on to the next slide here. So talk a little bit about the Experience Platform, and I'll kinda get into the genesis of the idea and our journey to where we are today. So about three years ago, we were looking at our .com and discussing some of the enhancements and improvements we wanted to make across the platform. And we were working closely with Adobe at that time. And from an IT perspective, we started to hear a lot of consistent themes and requests, not just from the MarTech team and the and the marketing organization but across the enterprise. So we started seeing a lot of themes and concepts around building digital experiences that started to parlay. So whether you were in our marketing organization, whether you were in some of our client facing organizations, whether you were in our internal teams that may be just trying to engage employees, trying to engage our alumni, whatever it may be, people were very concerned with how do I build experiences that will capture their attention, personalize their content, and hold their attention span to be able to get them to engage with in a way that we want. So we started to look at, well, how can we leverage beyond a point solution for our marketing organization and our .com? How could we leverage some of these capabilities that we have within the Adobe platform to be able to create a micro service construct that we could reuse, repurpose, to help us get to market faster, simplify and consolidate some of our operations, and to be able to help manage cost. Hopefully, reduce cost, right? As we go on this journey, such that rather than building 15 different point solutions for 15 different use cases. We're building a platform and then the fundamental concept of that platform is it has certain Adobe capabilities and services that can be reused and repurposed over and over again. So around that, it has some principles around insights, journeys, experiences, and processes. We'll talk a little bit more about that and how we've built that going forward. And the way we're going to spend some time today with you today, kind of Barb will talk a little bit about what we've built. And Akshat will talk about how it was architected. And at the end, we'll kind of give you some demonstrations or kind of walkthrough of what it looks like and how it works. Okay? Next slide. So a little bit about why adapting this and some of our objectives as we went through this today in our original journey. We were looking at cost reduction, right? So budgets are tight, funding is limited. How do we get the absolute most out of this Adobe investment? How do we start to parlay that investment that we're making and the licensing that we're procuring to be able to be able to use this across as many systems and applications and use cases as possible. So, the other benefit was this is we started to see an opportunity to centralize our management and operations of the Adobe platform. So it allows us to centralize some of our security controls, allow us to kind of create operationally a centralized team to be able to operate and manage the Adobe shared platform, in essence. So rather than having support teams supporting the .com and the intranet, and some of our other custom applications that we're building across the enterprise, we have one team that's working at the center to support all. Creates a lot more efficiency, a lot better control and governance around our security, and allows for faster deployment. So we're able to move quicker, spinning up any infrastructure, being able to control and manage deployment activities, and being able to continue to reduce cost. And then finally, allows for better collaborations, right? So teams are able to work on different applications, and we're able to move resources to share those resources across multiple projects. So I'm not having to spin up resources for a project, spin them down. Spin up resources, spin them down. With having this central core team that is operating and running the platform, we have projects, I'm able to move resources to be able to support, keeping them fully utilized as we continue to support different use cases and project requests. And then, finally, scalability. We're able to really work with the infrastructure and the investment we have, able to spin up and scale the infrastructure very quickly, accommodate changes the application needs, and does it require significant re-architecture or rebuild or rethink of the infrastructure that we have in place.
I mentioned this briefly, but reducing some of our operate costs, reducing maintenance. Again, we're maintaining and running one infrastructure, one platform on which these applications are built on top of.
We have standardized practices, so governance is key to this process. So trying to standardize how we do our operations and our governance of the platform, making sure that we have uniform development practices, consistent maintenance and operational practices, streamline as much as we can to be able to kind of reduce costs around the operate, automate wherever possible, and then finally, reduce the complexity of adhering to multiple regulatory compliances, minimize the risk of noncompliance penalties and other things as well. So hopefully, that makes sense about some of the goals and objectives that we have. I'll turn it over to Barb here to talk a little bit about what we've built. Thanks, Jeff. So as we started looking at the platform and we started bringing it together, some of the things that we really need to pay attention to was the optimization and the scalability. So how do we meet the business needs but not adding more of that cost? So with the centralized data platform, so we've started looking at the AEP. So we already have that in place. We actually have two today. So how do we bring that together to actually start scaling it even further to enrich those profiles? The services package, process automation. We did a project for our US Creative Services, where we built out their entire process flow using Adobe Workfront and Fusion and adding all the process automation in place. And then some of our other teams, we just take the same exact workflow, we copy it into another workspace within Workfront. And we make modifications to it to meet their needs. So we don't build it from scratch. So it's a lot easier, a lot faster. So it gets to the market faster. The platform scalability. I have one Workfront instance for 400,000 people. And so it scales up to ensure that we don't have to do dual license. So I don't have to pay a license for creative services, and a license for VMC, and a license for some of our global knowledge team. It's one person. So it's one license. And depending on their permissions, that's how they get in there.
That one's content management and then feature readiness. We really look at how do we take it a little bit further. So instead of having a development team to build stuff for you, how do we give you a catalog? You choose what you want. We implement it. You're done. We don't have to have a full development team to do so.
We use Agile. So we actually look very hard at how do we create, integrate, preview, approve, and just keep going in that cycle. So we talked a lot just recently about how do we scale to get the speed to market. So this is one of our products that we put in place with our first flagship product on the team was called Discover. It's our internal knowledge platform. So we actually used Workfront, AEM, Marketo, Analytics, Target, and then some third-party applications, Elastic, Pool Party. And to bring those all together to actually meet the needs of the whole content management lifecycle, to ensure that it gets through the lifecycle into AEM as a store and then re-shareable to our EY community.
We use the audience segments and the content collide.
Of course, with AEP, we make sure that we have all the attributes that we need to enrich those profiles, use an audience with Target to target our resources to make sure they get that personalized experience. And we'll talk a little bit about that in a bit.
Thank you, Barb and Jeff. I'll talk a little bit about the architecture that we planned for this implementation. And what we did was we took an approach of shared services model with a hub and spoke an architecture. And how that evolved as a project was we decided to put certain common services in what we call a hub. And the hub was, again, with various capabilities. So what we said is maybe one hub will not be enough. We might have to put a differentiation between what other services that we're going to provide from hub starting with the digital hub. In the digital hub, we said, let's get all the data related items here. Let's get all the digital assets related items here. Let's get all the campaigns over here because these are some common services that the organization can utilize across the departments, right? So what this also gave us was the flexibility that keep all the data sources connected into one place. So the advantage was in the AEP model, what you say is that, hey, let's bring all the various data sources, club them together into one place without impacting how you are managing the source data. So source data continues to evolve, continues to grow the way it is, but we collect all that data, put that in the middle, and then we build what is called a unified platform. And in this unified platform, you'll see the unified profiles for your individuals. The unified profiles is something which is then going to drive lot of different activities for your web applications, right? So here, EY started collecting all the data sources including the warehouse data, including the analytics data coming directly from web, so events driven data, all that coming into one place. What we did was we said service lines which are running outside as an application, they start connecting to the hub to provide that data. So initially, we build the hub with whatever information is available, and we tap into all the resources which are available within the organization. So we build that environment. But then that is not good enough because what happens is at some point in time, you want freshness in that. You want the data to be continuously enhanced. And to do that, we say that all the service lines, which are business units, they have their web applications running. They should continuously pump data into my hub so that hub is continuously nurtured, right? And this gave us that flexibility that, look, service lines, you can do what you need to do with your application. How you want to present the content is up to you. But give us the data stream back into the common source here, which is what is going to then drive the segments for you. So now the benefit to the service line is that they don't have to worry about managing this audience segments creation or how do we enhance the segments creation or how do we stream the segments creation. Hub is providing that as a service. In return, hub is getting all the data back into the hub so that hub can continue to grow. Now the other advantage of this would be you look at the service line, it is one. But what if there are many? So in case of EY, there are actually many service lines working together. So to do that, they have one hub. All service lines are providing data back into it. Because now it is a bigger set of data and a better set of data, all service lines are getting equal treatment or getting better segments out. So they can do personalizations, they can do campaigns targeted to individuals, how they want to manage that. In addition to doing this, in addition to the digital hub, there was one common requirement that came across from various service lines. They said, we want to be up and running on this model quickly. We don't have resources, we don't have time, and we don't want to go through severe amount of coding and re-platforming. How do we do that? So we said, let's create a mini hub within that, which is configuration hub. This configuration hub is sort of like service packages. Now we are saying that, hey, service line, you don't need to be master at this technology. What you can do is we will provide you these services so you can start connecting promptly, right? So service lines could come in and say that, hey, I'm looking for just analytics. I don't have time to learn analytics, how it is maintained, how it is configured, how it is run, how the schema is developed, how the data layer is configured. I don't have time for that. But I just want to enable that on my pages. Here we go. You connect through the data layer. We'll give you piece of code that you place on your site. And as soon as that is done, you start pumping in data into our hub. So this whole circle that we have created here is service lines use hub through capabilities, but they also become contributor to the hub. The second advantage of this was not only are we getting all the data, in the hub and we are growing the data, but the bigger advantage here is we are also getting all their configurations and their new components and applications that they're building so that a new service line or an additional service line can start taking benefit of that code. So if one service line has implemented, let's say, a search technology, that is now part of hub, which can be given to another service line as a service. So hub is sitting in the middle orchestrating the code and configuration demands as well for the organization. That was a bigger benefit we saw there.
Obviously, the question came after that that how does it work where service line has resources to manage their own presentation, manage their own content, manage their own targeting, but they want only services from the hub. So we said, let's create a boundary here where within the hub, you have all the capabilities listed, but service lines can connect to the hub for specific activities, right? And now in this case, they don't have to worry about which data source and how do I go to that data source. And it's not just about connecting to the data source. It is also about getting compliance for connecting to the data sources, right? In case of EY, they had to go through severe security clearances before they could even tap into the data sources. And there are some geographical reasons as well. Like, where does the content reside? Where does the data reside? So all those items which are surrounding the need for collecting the data in one place, that is the headache of hub. Hub has taken care of that on the side. But service lines are connecting to it for services. Now these are the service lines which say that we have resources and time and money to manage our own content. Sure. They can continue doing it, connect to hub. But then there are some business units which say that we don't even have all that. We just want some services where we want to even manage content within the hub. So for those service lines, it is purely everything from hub. You have the content management also sitting in the hub, you have work management sitting in the hub, you have personalization sitting in the hub. So they don't even have to set up their own environment unless they want it, okay? To take this further, now the problem was that, hey, we have created all this, we have created an architecture, we are putting this into a hub and spokes model, and we feel that, wow, this is very confident model where it's going to self sustain. You give me something as a hub, and I'll give you something back as a service line. Now if that works, then how do I get you on boarded to that? To do that, we said, because the hub is sitting in the middle with all the prepackaged services, how about we collect all the service lines into this as service offerings? Now service lines can come and say that, hey, I do not care about, let's say, digital asset or I do not care about campaigns. I do not care about data management, but I want to enable analytics. So we said, here is your a la carte menu of service offerings that we have created. You want personalization? Here you go. Let's start connecting you to that. In this case, you give me the data connection, we will give you the segments, you start running your campaigns for personalization. If the service line comes and says that, hey, I want to use some content that you already have in your system. It could be some articles that you have created. It could be some globally distributed content that we want to utilize. I don't want to keep creating that again and again. So all I want is a stream coming from the hub and give me that. Next could be analytics. I could say that purely analytics, I just want to look at the web traffic. I want to analyze who's on the page, what are they doing on the page, and get some reports at the end where I can take some actions. The next service offering here was templatized web pages. Quickly coming up to speed on how to build web pages using these modern technologies. They don't have to deploy any additional code, they don't have to deploy any additional services. They basically take prepackaged templates and components, start using them, right? Idea I'm trying to throw here is that there are many of these that we created, 1 to 10, and it is further growing. But the main idea here was, how do we make it easy and convenient for service lines to say, I want to be on the hub. And to do that, the service packages gives them, A, the autonomy of how they want to interact with hub. It's not one-size-fits-all. So basically they can pick and choose what option do they want to connect to. B, they can prioritize this connection to the hub. They can say that, you know what, Analytics is the easier piece. Let's enable that first. And now I want to worry about work management. This is where I want to draw my own workflows. This is where I want to do my own approval processes or integrations or any other customization. But that's going to take time. So let that run in the parallel while personalization analytics are already running. So they have this option of pick and choose which one they want to use first versus later. If they want to use all of them, great. If they want to use one of them, that's also great. At the end, they are saving on time to deploy, and we are giving them the efficiencies of how to run this. Jeff, do you want to add some more information about how EY is then utilizing this model into, the framework? Yeah. So from an EY perspective, it was the vision and design of this as we kind of evolved over the last few years in developing the capabilities and these services construct, we've created kind of a service catalog that allows almost a menu for people to be able to look from and choose what service, microservice that they want to plug into. And we started out seeing a lot of analytics. I'm interested in analytics. Let me try to get more analytics in your system. And so as they started to engage and leverage that analytics as a service, they then started to ask questions and engage with us to look at, well, what about personalization? How does that work? How can I start to leverage some of this data that I'm collecting from analytics plus the data that you have from and the profiles that you're maintaining within the hub? How can I use that to start to drive more personalized content? So we started to see the adoption start to evolve, the people to start to leverage more and more of the capabilities. We started to having richer conversations with them around taxonomy and around standardization and around all of this to be able to create more unified experiences. And some of the benefits that we really started to see is where the light bulbs started to go off is being able to share content across the enterprise, and being able to drive personalization across the enterprise at scale and headlessly. So that was really important to people and started to open up a lot of eyes when we were able to sit down with the folks and say you don't have to recreate that content anymore. It's in the hub, it's in this experience platform, right? It's in what we've built. So if another application that's connected to us in the center, and for example, we have our knowledge platform, and it has a whole series of knowledge assets that have been created and is used. Well, if your application wants to drive personalization that incorporates knowledge, assets, and material, you don't have to recreate that. You can simply integrate to the hub and you're pulling directly from the knowledge content that's already been authored and published and is being groomed and maintained. So as that content and its life cycle management evolves, as that content refreshes, as that content improves, you're getting all of the benefits. And similarly, search enhancement, taxonomy enhancements, as we make improvements in the center, everybody gets them. So we're seeing a lot of efficiency, a lot of cost effectiveness, and things like you take our internet, we're able to move much faster to be able to re-platform our legacy internet. And how fast, Barb? - What is it? - Sixteen weeks. Sixteen weeks completely rebuild, re-architect, and redeploy our internet at a fraction of the cost of what it originally took to build. So because we're reusing all of these templates, reusing all of these services, we're able to move much faster to be able to go to market. And Barb has a few examples as well of how we've kind of implemented some of these capabilities and what it looks like within the applications. Yeah, so when we started, the first thing we did is our knowledge platform. And it was basically looking across the stack. What are those products that we need first? Because I'm a firm believer, don't put the square peg in a round hole, let's use the right technology to solve the issue. So we created the knowledge platform. As you get, this is actually a view of the home page. And we started looking at those products like Elastic and the Pool Party, which is called Graphwise today, which is the taxonomy management. How do we bring that all together? So as we started building it, we also started looking at, well, how do we personalize. So how do we get when a client server comes to the home page, how do we get them the right content? So we started using the personalization with Target and Analytics to say, oh, your client's serving. You're sitting in this service line and also in this sector. This is of interest to you. So we start pushing a little more content through the home page opposed to them having to look for it. So we definitely want to evolve from that. But we actually started there. So let's go to the next page. So when we first started, this is the view of the first home page and the first home page on the Adobe platform. And we started actually growing after it. Now we've personalized it. So these top ones highlighted in yellow are all targeted to you based on who you are, where you are, and the sector and service line you're in. And then at the bottom, you'll see suggested for you. Those suggested for you are the ones that other teams, like our strategy and transaction team, say, hey, I want the strategy and transaction content shown on my home page that's not in Adobe. But today, they were copying the data. So they literally would download it and reupload it, or they'd copy a link. And then the data gets archived. Well, when the data gets archived, the links break. So we said don't do that. Here, this is how you do it through Target. You'll actually just pull the content. It'll show it. And then if it's archived, it changes constantly because your personalization experience. That was the whole big use case for that reuse of that content that really is starting to move faster in the market or in the EY market. The other thing that we've done is, in the past, we'd have insights or knowledge documents that would also be used in our EY com, in the internet, and also in our knowledge platform. So the goal is not to create it three times. Use the same piece of content, just display it in the system. So the internet is now coming on to the same exact platform. They're using the same exact search. They're using a lot of the templates and components. They're using Marketo. They're also using AEP to help drive some personalized experience. And a lot of it's already built for them. So hence, the 16 weeks. Let's get them out there and get them moving. So that is happening as we speak.
That's a little bit about our platform, our EY experience platform. We wanted to save some time for Q&A to see if you guys had any questions for us. We're very proud of it. We're really excited about our journey and where it's taken us. So with that, we'll open it up to you guys to see if you have any questions for us and anything we can help with.
- Thanks. - Thank you. Thank you.
[Music]
