Vai direttamente al contenuto principale

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice

PegaWorld | 35:40

PegaWorld iNspire 2023: Pega Solutions Built by Google: How Google built their Solid Foundation to Scale Quickly Across Alphabet

Google is changing business as usual -- again. Using a hybrid-cloud approach, Google is delivering solutions that scale. A centralized approach solves for consistent Privacy, Security and Accessibility across the Alphabet portfolio.

Join Kendall Lin, Program Lead, Corp Engineering Journey Orchestration to learn about their journey and what is next with Pega. Shaena Heintz, Director, Google Cloud joins for an exciting announcement that you will not want to miss!


Transcript:

- I wanna thank everyone for attending. I know we are the last session of the conference, so a lot more stuff going on this evening. My name's Oliver Boman, and I'm the client director for Google working for Pega, and I have the distinct honor of introducing Shayna and Kendall who are going to be talking about some pretty interesting stuff that Google's doing. Did everyone see the press release this morning? Yes. So those of you going, wait, what press release? It is Pega Cloud is now officially available running on Google Cloud. So Pega Cloud on GCP is generally available, and we have our first customer, of course, Google is now developing on Pega Cloud, GCP. Without further ado, Jayna.

- Thank you Oliver. Good afternoon everyone. How's everybody hanging in on the last day of PegaWorld? I think it's been an extraordinary event so far, and thank you Pega for hosting us at this event. My name is Shayna Heinz and I'm the director of Google Cloud and I'm excited to be here today to talk about our partnership with Pega Systems. And so together we are launching Pega Cloud on GCP and we hope that everyone leaving here today will understand what a game changer that actually is. And so imagine the possibilities when you combine the power of Pega with the innovations of Google and having all the Google tools. such as natural language processing, machine learning, and computer vision as an all in one package. In fact, Pega Cloud on GCP is a fully managed service that will provide customers with the best of both worlds, Pega's industry leading software and Google Cloud's globally owned and operated infrastructure. Pega Cloud on GCP ushers in a new era of cloud possibilities by harnessing the power of Google industry specific use cases, such as the much anticipated integration between BigQuery and Pega CDH for marketing analytics and subscriber activation and claims pre-authorization for healthcare. And this will allow us to quickly and easily deploy Pega Systems solutions to address obviously specific business needs. And I'm also super excited today to introduce to you Kendall Lin. Kendall is the corporate eng journey orchestration lead at Google. And so the corporate orchestration team is responsible for accelerating the transformation of business critical processes at Alphabet. And that of course includes the magic of Pega. Kendall will talk about how journey orchestration teams early success with Pega as a workflow automation platform really inspired them to start their own journey. This journey led to the extreme acceleration of the team's alphabet side services and solutions. And this is including implementing a Google privacy compliant review app and internal self-service options for many, for any Google, pardon me, that wants to build on the platform. So Kendall will also share how their team was able to solve for privacy, security and accessibility in a way we would not have been able to do with other software solutions. And so I hope you enjoy the rest of the event. And I also wanted to just extend an invitation for those in the room today that would like to learn a little bit more about the Google Cloud and Pega Cloud collaboration and partnership, we'll be hosting a happy hour at Wolfgang Pluck this evening from five to 7:00 PM. So if you're still available and if you still have an ounce of energy, we would really love to see you there. So Kendall, I will give the floor to you and thank you.

- Thank you very much. Okay, that's on. Alright, so thank you Shannon for the introduction. Thank you all for coming to attend. Really excited to have, this is my first PegaWorld experience. Google's been at PegaWorld at least three times, the first time in 2019. I'll do a quick summary of what we talked about then, but since that, the last time we were at a PegaWorld in person, we've had an interesting journey, right? So I have a story to tell, right? And that story is about journey orchestration's journey. But before we talk about that, let's introduce the characters, right? So with me here is a couple of folks on my team. So Andy Kiepe. Andy, could you stand up and just wave? So Andy runs our data analytics and reporting service and also helps deliver our process analysis and design service. Also here today is Hemanth Tammareddi. So Hemanth is our tactical lead. He also, you know, is responsible for our infrastructure and our self-service capability. So he's helping enable other creators at Google. Someone who couldn't be here with us is Bart. He runs our automation solution delivery function. Unfortunately yesterday was his first day of a three week vacation. He's based in Europe, so that's just a short vacation for him I think. But so a little bit about each of the players on the team. There's some fun facts here. Andy just recently got married so if you see him later at the happy hour, you can either congratulate or commiserate, depending on which side of the fence you are on that one. Hemanth was brave enough to bring his family here, which includes a two year, oh no, a 3-year-old, almost a 3-year-old. So again, kind of give him some courage later. So a little bit about my origin story and why I'm talking to you, right? So I started as a software engineer, right? I was building middleware solutions that automated financial transactions for investment banks and these were on the scale of a hundred million dollars a day were was being traded in six second increments, right? This is in the late 90s, early 2000s. So I know what you're thinking, like I can't possibly be that old, right? So I know people get like middle, you know, midlife crisis cars. I went with the midlife crisis haircut and I'm seeing how long this will take. But so in the late 90s, early 2000s, if you're old enough to remember, we spent a lot of money on stuff. Like the internet bubble was still around, right? Y2K was supposed to be the big bad wolf that blew down everyone's house. So we spent a lot of money on technology and sometimes that technology wasn't the right fit or we did something that actually had the opposite effect, you know, all the way back then. I guess not much has changed, right? But you know, I was certainly kind of guilty of building solutions that actually didn't have business value, right? So when the internet bubble burst and I had a chance to kind of think about what I wanted to do, I spent the better part of the next 20 years trying to right some of those wrongs, right? First as a process analyst consultant, then as an enterprise architecture consultant. And then finally moving into a company sort of like Pega with an automation platform and leading engagements there. I moved into a more of a PMO space and all of those experiences, good, bad and ugly kind of led me to Google, right? And got me ready for my life at Google. And my life at Google is what, right? So we have our mission statement up there and each of those words, we spend a lot of time thinking about what we're trying to do. And so we are trying to empower Googlers to measurably accelerate transformation to best serve our customers both internally and externally. And underneath that are the four values that everything that we do and every service that we deliver has to have these key components. We are a trusted partner. We are not just someone that delivers services and walks away. Safety and security, like everything at Google is paramount. We really care about time to value, right? The business changes so fast, we do not think about taking a long time to solve a business problem because by the time, if it's too long, you have a new business problem. And then ultimately scalability, Google has a very large scale and it's only growing. So those are the four key components of the services we deliver and why. So I said I had a story, right? So journey orchestrations journey, and I talked a little bit about my origin story. I will quickly go through the origin story of the team, right? We weren't always journey orchestration. Journey orchestration wasn't a thing. But before I start the story, every story needs an obstacle, right? Something that our heroes, if I can call ourselves that, needs to overcome 'cause otherwise it's not very compelling, right? So I don't know why my name's on this. Like I guess I was quoted as saying this and it's come back to bite me in the butt a couple times because sometimes we unveil like a real truth. The biggest challenge for us, is to getting Google to trust a third party platform to run business critical solutions across all of the enterprise, right? I'll revisit this a little bit later to talk about what those situations are. And you know, I've had like eight to 10 meetings with other companies that are using Pega. And I think our problems are very similar, right? So the origin story of the team. So we have a very large global network, right? I think you can imagine Google has many, many locations and data centers where we have Google equipment that runs our production network. Now getting people in and out of those secure locations to say, take a look at one optical line that may have gone out to do some maintenance and repair, and having the materials there at the right time so that they can do their work across the globe is no small feat, right? So in comes what was known as the net deploy business operations team. That was the first team that I joined when I came to Google, that team was led by James Daropolis who is also here. So ask him to stand up, please. So James did the presentation in 2019, I believe, where we talked about this use case at length, which I'm gonna shorten down into like five minutes. He's since gone on to greener pastures, but he's here for moral support, I think. So part of the mission of that team was to measure, analyze, and design and build, right, a field services and repair solution, right? Well, we had some challenges, right? To get from the side yard over to the playground onto a roof, there was a lot of meandering, right, that we had to kind of cut through. And again, I think some of these apply not to just us or this specific point in time solution, but it highlights why we chose Pega to solve that problem. When you're deploying a solution across the globe with different variations of the same process, right, there are are different ways to design the solution and Pega allowed us to do that in a really quick manner. Dynamic decisioning. So we deployed the solution in 2019, thank God we were able to change the business rules on the fly because sometimes when you're getting people in and out of locations, those business rules need to change because of, you know, external system-wide global impacts like a, you know, 100 year global pandemic per se. So we were able to change our business rules on the fly and not impact the service of this solution that I'll talk about in a second. And that was a big component around realizing the value of the platform. The other challenge we had was lack of dedicated engineering support. So I think like other companies that support a lot of software engineers, those software engineers are building things that may not be involved around operations and case management, right? Our software engineers for example, we're focused on building the next gen optical engineering frameworks, network monitoring tools, things that are very, very important that are very first party, right, not operational accelerators. So what did we do? We implemented a solution that we affectionately called Moose. The previous solution was called Hairspray. We decided to follow along with the naming convention and this we landed. I actually used hair wax, that might be in the next version name, I'm not sure. What you're seeing is kind of the results. And we like to kind of show this because for process engineers, this is a very compelling story. On the left hand side inside the red brackets is the performance of the process when it was completely manually driven. The green line represents average, the yellow line represents medium, duration of a service request. You can see on the green side, when we implemented the solution, there's a couple of things that I'll note right? Immediately you'll see the green line and the yellow lines start to get smaller. So everything took a lot less time. You'll also see the gray bars, which represent the number of requests. The green lines and yellow lines don't jump up or go down based on the volume. But on the left hand side, in the red brackets, whenever you see a spike in the gray bar to show that we had increased requests, the average duration time went up. And consequently, if those gray bars go down, the duration went down. So anyone that's familiar with Six Sigma or kind of processing engineering science would say what we did on the right hand side was we removed variants, right? We tightened the upper control and lower control limits for the process. Now all of a sudden we could figure out what are the little tweaks and knobs that we can turn or levers that we could pull that would have a measurable impact. This was a really big success for us and it led within this Google Global network space to the following key results. We now expanded that one use case and I think two case flows on one application. We built 17 unique case flows across five applications. We had a hundred thousand transactions a year. We were able to reduce the amount of time it took someone to request access to our sites by 90% on average. And a staggering 75% of the transactions became fully automated. No human intervention was ever needed. One of the first programs that I dealt with was our RMA process, and we were able to reduce the repair process delays by 57%, which is one of the most complex use cases within our data, global data centers. So what do they say? Sometimes you're a victim of your own success. We did a really good job. I think we made James proud, right? So much so that they asked James and myself, can you do it for Alphabet? And I don't know what we had that night. We might've been drinking something, but we said yes, right? And we decided to, we could handle this new challenge. Now TI and the Google global network, I said it was a really large network, right? And it's true, but you're only servicing 12,000 users. Google as a company including FTEs and TBCs, numbers over 300,000. By the way, it was just the two of us to start. We had a much larger team before we moved into the enterprise space. So I'll talk a little bit about this quote again, and I mentioned earlier I'd say, you know, what are the challenges I think all of us feel right? And then I'll talk a little bit about what we did. So software engineer, resource motivation, as I mentioned, I think Google's got some of the best software engineers in the world. I truly do, right? We've built things like ads, search, Android, they build game changing tools. and we also contribute to open source things, right? We do things like Kubernetes, Golan, material design. So they're focused on the next big thing. And guess what? They get promoted for that, right? What they don't get promoted for or what they're not motivated by is maintaining a platform. They're great at creating stuff, but that stuff needs to be maintained and nurtured and improved. But in a performance cycle for a software engineer at Google, that's not something that they typically get measured on. While those things are changing, we're still not there. UI UX requirements, right? If you're gonna build for Alphabet, I'm if guilty as anyone that works at Google, we get used to our tools, we get used to our user interfaces. Google has spent a lot of time giving the world our viewpoint of what is the best user experience and what are really accessible UIs. And we make those requirements internal as well. So we make them available to consumers, we make sure that we have those internally as well. So when you're delivering for Alphabet, you have to comply to those. Security, privacy and accessibility, right? So Google's mission to organize the world's information and make it universally accessible and useful, requires us to sift through an almost incalculable amount of data. And I know there's a lot of people that worry about how much data that Google is able to sift through, but I will tell you that we have a very, very almost sacred responsibility on how we manage that data. And we take that very seriously. And integrations, integrations, integrations. I think we did like an internal survey and I don't think it's news, but the number of tools that Google uses on a year to year basis increases by a double digit percentage. So we're quickly having a portfolio of tooling that we need to integrate, and it gets bigger and bigger every year. And if it takes you a long time to do those integrations, you're way behind the eight ball. So how did we solve these problems? After we moved into CorpEng, we focused on two key areas. There's process and methodology and then there's technology, right? So we developed a couple of things. We stood up a center of excellence. That center of excellence was, main goal was to define services and solutions and to define the methodologies in which we would deliver those services and solutions. And we didn't end at just automation through Pega, right? We also realized there were other services that were complimentary to process automation that would be a force multiplier to the value. So in partnership with our friends at Cognizant, we also stood up a standard delivery team that would take work from all across Alphabet, right? And work to a standard delivery methodology that we could prioritize work as it came in. I'll talk a little bit more about that in the third box. With our partners like Accenture, we expanded our production support to be 24/7. And we also built into our methodology a formal handover. For solutions built on the Pega platform by us, by citizen creators or anyone else at Google. there is a handoff process to the production support team so that the production support team then own the solution and the person that built that solution would own the roadmap of that solution moving forward. We use GCP automation tooling, first party and third party that allowed us to automate the infrastructure spin up. Before we had done it manually because we didn't actually, those automation tools didn't exist when we first started this. Luckily by the time we moved into CorpEng, we had made a lot of progress on the GCP side and now it became a lot easier for us to expand and scale. And so I'll get to the part where I'm personally very passionate about, mountaineering. So there was a geographic presence of the team in Colorado, which is where I live. So we had themed a lot of our services around this idea of mountaineering or ascending a peak. The mountaineering solution is an end-to-end demand intake, opportunity assessment and solution estimation and reporting platform that we utilize to manage our work. And some people have asked me, well where did you build it on? Well, if I'm a workflow management team that can't build a workflow management tool on the platform that I'm trying to deliver to other people at Alphabet, then I'm probably not the right person to be running the team, right? So we have a history of eating our own dog food. I think Google dog fooding is a term that people are aware of. That's what we did. We manage our work through a workflow that we built on the platform that we deliver on. Alright, cool. I didn't think that was where I was gonna get the woo, I was hoping it was the haircut. The other thing we decided, you know, to accelerate, here's the thing, the team isn't growing in size anytime soon. I think we all have an idea of kind of why that is, the economic reality we're in. So how do I get adoption and accelerate use of the platform, which we can solve real business problems? Well, we took Pega's app store concept and we extended it and added our kind of little magic to it. I think Hemanth led this effort so that other Google teams can ask for a sandbox, hit a button and they will get their own provisioned environment within 36 hours. They can build whatever they want in that sandbox and when they want to deploy it, guess what? They have to come back to us, back onto the platform and we built our release and deployment process on the Pega platform. All of those things are controlled so we can ensure best practices and then privacy and security is the next step. Andy who led this effort, spent many months and many meetings going over and over again, why we think Pega is secure as a platform, but as with dealing with most security engineers, if you've had the pleasure of doing so, they don't trust anybody, right? So as personable as Andy is, it took a lot of time, but we built an application on the platform that complied to Google's privacy and security process. So any application that is even a candidate for deployment into production, we annotate every single data field within the application. We make it easy to do through a case flow. We make sure that there's time to live requirements built on every single field. We determine depending on what type of data there is, whether we can obfuscate it, we can wipe it out, or we can retain it based on an API call. And that allowed security to certify the platform for use at Google with Google's data. I talked about some of the complimentary services that we think our force multipliers. And again, from my background as a process analyst and you know, Six Sigma and stuff like that, I realized, and I'll call back to the mistake of throwing money at a problem and building a solution that might not be a fit for it. So I was very passionate about setting up a process analysis and design service, right? So we use our partners at Accenture to help businesses understand what issues they actually have, model them out and then the output of that could be used for an automation effort with us or they can use that with somebody else. And the reason we're able to do that is because within the mountaineering solution that we built, we also built a fit assessment module. So walking through, taking information about a business problem, we're able to score that business problems suitability for different technologies that we use at Google. Pega being one of them. But there's author automation tools at Google. And I worked with those technical leads to come up with a solutioning rubric that we apply to business problems that come in through the front door and we decide which solutions fit for which business problem. And once you deploy a solution, how do you know it's useful, right? Well we wanna make sure that we have reporting on that operational process on day one. So Andy leads a team that early on in the development cycle and in the design cycle determines what are the key metrics you care about? How do we make sure that we're designing the system to capture them at the right points in time? And after the solution is deployed, how do we visualize that in a meaningful way? And by the way, I don't want you to go to another tool or swivel chair into another special reporting tool. So we use Pega's capability to pull in reporting and now all of the reporting is done through a Google technology called Looker Studio and is done within the platform and you never even know that you're actually looking at another report. We're also using Google Analytics to measure and understand how users are using our solutions. What time they're saving and what time, how much time they're spending within a certain process. And lastly the user experience, right? So Pega's flexibility with skins allowed us to take every single component on a UI screen and apply a material design look and feel. So I've sat with customers showing them this mountaineering solution I was telling you about and walking through the intake process and it looks like a Google tool. It interacts like a Google tool. Most of the Googlers that I'm walking through this process with say, Hey, I've never seen this application that you're walking me through before. What is this? Oh well that's actually Pega. That's actually something that we're proposing to build a solution for Elon. And this is very unusual at Google, right? Google does use other third party tools, but those third party tools don't look and feel and integrate with Google. Here's another quote that I'm somewhat infamous for. I called Pega the most Googley third party platform at Google. There were some eyebrows raised in my leadership team and they were like sort of like really? You had say that and let Pega quote that at their conference. Well, it's out there. But I feel like I can justify it, right? I've integrated the platform to tools that Googlers use and almost billions of people use right, across the world. So all of our G Suite tools are integrated into the platform. Content management on our platform is handled by Google Drive. Scheduling is handled by Google Calendar, but it's all done synchronously with the platform and our workflows that we design. I mentioned before how secure the platform is. I remember when I accepted an offer at Google and I think I posted on LinkedIn that I had accepted the offer, one of the first responses was from a very good friend of mine that said, enjoy reading my emails, right? That's not what we do. And we've built the platform to ensure that we don't do that. We want you to trust that, right? I talked about the UI and UX. And then finally the ability to use Pega headlessly, right? So we are in the midst of figuring out how to leverage the Pega business rules engine on the backend and call it as a service so that Google software engineers who are not really motivated to learn how to develop on a low code platform, well I'll just kind of give them a rest endpoint, a service catalog and tell them, oh you're just calling a microservice but we'll handle a lot of the heavy lifting, right? So that's the end of the second act of the story. That's where we are today, right? What we're looking to do as we move forward. Currently we're on Pega Cloud on GCPE, most of it is on GCE. So Google compute engine VMs. We're doing a migration to GKE, so we're gonna take advantage of the auto-scaling, the ability to have multiple clusters and name spaces, all of which I'm just saying words, you can talk to Hemanth about this 'cause he understands it much better than I do. We're adding new platform capabilities. So this past Friday, we just deployed a solution for our legal team in which we're using OCR technology, NLP technology and Google Translation technology all available on GCP to read all of the posts that comes in to our mail centers that are scanned, to language processing and keyword clustering to figure out what type of legal document it is. Oh by the way, they're in seven different languages. So we use translation to translate into English, then do clustering. And then based on that clustering we figure out, who should be sent this information. This actually used to be managed through a Google sheet, an email. So we are very excited to release that on Friday and add two new capabilities to the platform. We're actively looking at process mining and machine learning and applying those frameworks to solutions that we've already built. But any new solutions. There's this thing called generative AI. I don't know if you've heard of it. I don't know if it's been mentioned. If you're playing the drinking game, go ahead and take a shot. We're already talking to a lot of people about how do we leverage generative AI within our ecosystem. And then finally, like we announced, the externalization of Google workflow access. We signed an agreement recently in which we have an external, everything is hosted internally. We are now building workflows on an external environment with an agreement with Pega and we're working through how to leverage that in the best way possible. So that's the end of our story. I dunno, the time's over there. So I think we have time for questions. Thank you.

- moving voice.

- There we go.

- Yeah, I can't see very well. So you'll just have to start talking and then I'll try to answer.

- [Guest] Can you hear me?

- Yes.

- [Guest] - Okay. So in your third bullet point you told Pega's out of the box UI, you are using it to make it like, look and feel similar to Google? So which technology you are using? You are using DX API or it's interacting with Cosmos engine. So how you built it? Because I'm from Toyota, so we are also want to build using Pega, but as a headless, not like a complete Pega. We want to use it Pega only for workflow engine. And the backend as a rule engine, not a complete solution, as a part of our solution but not a complete picture. So we tried using DX APIs but we don't want to use Cosmos Constellation. So we kind of like tried it. So I want to just to know like how Google implemented it.

- So we're actually taking two approaches to it. So we use Pega Skin's capability, and keep me honest here, is it on Constellation or Cosmos right now? So we're using Cosmos, and the ability to skin Cosmos to build material UI UX components, that gets us to like 95% material design compliance, right? So we've worked with an internal team around what material design is and how it should interact down to the pixel, right? So we're 95% compliant. We are partnering with Pega. They're going to extend their Angular SDK and work with us to build from our open source material design framework, a library of components of material SDK. So they're currently building that and we're partnering with them to help them where we can. So eventually you can use what the SDK and it should be closer to a hundred percent compliant. Does that help? Cool.

- [Guest] Thank you.

- Everyone ready to jump on a flight or go to the happy hour? Any other questions?

- Or I did just a standup job explaining it and there's really, it's just super clear. All right. Thanks for coming. Appreciate it and I look forward to talking to you again.

Related Resource

Prodotto

La progettazione delle app, rivoluzionata

Ottimizza la progettazione dei flussi di lavoro, in modo rapido, con la potenza di Pega GenAI Blueprint™. Imposta la tua visione e assisti alle creazione istantanea del tuo flusso di lavoro.

Condividi questa pagina Share via X Share via LinkedIn Copying...