Management of variation in layers

In your Center-out™ business architecture, you've defined your logic which connects customers to outcomes centrally. You've connected it up into your channels in such a way that it isn't embedded in your channels, but your channels can dynamically respond to changes in the central logic. You've connected it down into your systems and your data in a way that the complexity of those systems is insulated from the business logic in the center, but the last thing that that business architecture needs to do is actually organize your business into layers.

Why is this important? Well, when I talk to a lot of clients, I'm often told that we have one thousand business processes, and that leads to a lot of complexity in our business. But when you step back and look at it, a lot of times, you don't have one thousand different business processes; you have twenty. Maybe fifty, but each of those processes have variations, have differences that you have to do in one area of the world or for one product, or for one specific customer segment. And historically, we've managed those variations by building different systems, which lead to silos and lots of duplicated effort. Or we split our Salesforce deployment into multiple orgs so that we can manage all of that stuff separately, and it becomes really expensive over time.

If you think in layers, layers that start all the way in your channels, go through your business logic and reach all the way down into your systems, you can actually manage that complexity much more effectively. We do this in Pega with a capability we call the situational layer cake. And the layer cake allows you to define layers of things that you want to be common across the enterprise, maybe common process elements, security data integrations that you need to do. And then introduce just the deltas, the differences, the things that need to be specialized by key dimensions such as the geography or jurisdiction, like the US versus EMEA. Or maybe differences by line of business or product? Or differences that may exist because of the customer? Or the particular channel that you're dealing with.

And as you go up this layer cake, I'm not duplicating the logic that lies below. I'm simply defining the differences, the variations so that if I need to change something that's common, I change it in one place, and it's instantly reflected everywhere. But if I'm a customer or a user working for a particular product in a particular channel in a particular region, I come in, and I get a slice of that cake that is unique to me that reflects the variations in the specializations that I need to see. This approach allows you to start small with a single process may be running in a single area, get a really quick result in weeks or even days, but then use that as the foundation to scale to a much more global and company-wide transformation.

SO is the agency inside the Swedish government that manages all of their unemployment funds. And in fact, they're twenty-eight unemployment funds that SO manages. And up to a few years ago, they had twenty-eight different systems to manage the variations in those funds, which meant every time a new legislative change came out, they had to go into twenty-eight different systems and make that change. Using this layered approach, they were able to take those twenty-eight different systems down to one. Less maintenance effort, easier to make changes. And because they didn't have to manage change in twenty-eight different places, they were able to really focus on the business process, reduce the amount of time that it takes to complete an unemployment claim from weeks to seconds. So they were able to drive a much more coherent architecture, a much faster time to change, and a lower cost of ownership for their systems while at the same time delivering a much better experience to the constituents on the other end.

That's the power of a Center-out business architecture that is built in layers.

You have reached the end of this video.