Frictionless Enterprise
A modern architecture to shred tech baggage and create perpetual momentum
Get good at change
As technology leaders, change is coming at us hard and fast. We’ve been through transformation after transformation: DevOps transformation, cloud adoption, modernization, automation, agile transformation, moving things off-shore, on-shore, near shore—the change is unrelenting.
We have to adopt and adapt to the new paradigm shifts or else we risk being disrupted.
That’s hard. It’s hard because technological change is really about changing behavior—the behavior of individuals and of organizations. We have built-in muscle memory we have to overcome.
When we adopt these paradigm shifts, it’s vital that we’re not just doing surface level adoption. You have to really dig in and understand: what’s the benefit of this shift? What’s the value I’m trying to get out of it? You have to capture that. If you don’t, you’ll go through all of the pain of changing without actually realizing the benefit.
That’s hard. It’s hard because technological change is really about changing behavior—the behavior of individuals and of organizations. We have built-in muscle memory we have to overcome.
When we adopt these paradigm shifts, it’s vital that we’re not just doing surface level adoption. You have to really dig in and understand: what’s the benefit of this shift? What’s the value I’m trying to get out of it? You have to capture that. If you don’t, you’ll go through all of the pain of changing without actually realizing the benefit.
Change causes stress in businesses. They get stuck when they don’t have enough time to adjust.
Frictionless Enterprise is about having a structure to be able to absorb change. Looking at your business itself as a platform is a mechanism that you can use to harness change as a driving force to power innovation.
Why it matters to different roles
Your Chief Architect, CIO, and Chief Product or Digital Officer care about different things. See how this framework helps each role, and why this way of thinking transcends the latest technology and disruption waves.
Take a closer look
Stop solving solved problems
Too often, businesses find themselves trying to resolve solved problems because of organizational muscle memory. A good example of a “last decade problem” is the story of Ford Lake.
Ford Lake
In 1932 Henry Ford was building a new auto plant in Ypsilanti, Michigan. He needed power for his plant, but in 1932, widespread power generation and distribution wasn’t available. So he commissioned the building of a hydroelectric dam. He dammed the river, created a man-made lake, and generated his own power.
Widespread power distribution became a solved problem...
and then a solved-problem-as-a-service—something you can just go get. And if you’re spending all of your good capital resolving solved problems, you’re not able to spend it on innovation.
Don’t mistake activity for progress
Your ability to tie into solved-problems-as-a-service is crucial. In 1932, Ford did have something he could tie into: the railroad. The railroad is a fantastic example of a platform. He could use the railroad to get raw materials into his factory and more importantly, to carry his new automobiles to markets all across the country. But that wasn’t always the case. In 1865, the difference in the railroad between the North and South was one of the contributing factors to the South losing the Civil War. The North was industrialized and truly had a rail platform because the gauges - the distance between the wheels of the cars - were all the same. The North could easily move goods, materials and people across the country.
In the South, each individual rail system had a different gauge. When it came time to leverage the railroad during the war to move things rapidly and frictionlessly, the North was able to lean in and do it. The South wasn’t. They had to spend a lot of time, activity, and effort getting things from one point to another where the gauge changed, unloading everything and reloading it onto the next set of cars, reloading and unloading at each juncture. It was a ton of activity, but it wasn’t meaningful activity. It was a lot of wasted effort.
We have to look out for false equivalence. On paper, the North and the South both had a railroad, but one was a true platform and the other was an integrated system. The key difference is taking all of the friction out of the process and leaning in on automation. If you’ve leaned in on cloud and devops but you still have a lot of manual processes built into your organization, then your product teams are still going to have a lot of lead time, churn, and manual processes to work through in order to build products.
In the South, each individual rail system had a different gauge. When it came time to leverage the railroad during the war to move things rapidly and frictionlessly, the North was able to lean in and do it. The South wasn’t. They had to spend a lot of time, activity, and effort getting things from one point to another where the gauge changed, unloading everything and reloading it onto the next set of cars, reloading and unloading at each juncture. It was a ton of activity, but it wasn’t meaningful activity. It was a lot of wasted effort.
We have to look out for false equivalence. On paper, the North and the South both had a railroad, but one was a true platform and the other was an integrated system. The key difference is taking all of the friction out of the process and leaning in on automation. If you’ve leaned in on cloud and devops but you still have a lot of manual processes built into your organization, then your product teams are still going to have a lot of lead time, churn, and manual processes to work through in order to build products.
Make sure then that you don’t just have a lot of activity built into your organization, but that you’re actually taking friction out and making it easier to work.
The power of the platform paradigm
The power of the business platform paradigm is thinking about your technology strategically in terms of your business, and not the other way around.
Your business itself can become a platform. The core capabilities that you have to run the business, as well as those special sauce pieces - that’s your magic. Those are things that you can expose as services to your product teams. But then, when you’re doing that, make sure that you’re exposing them in such a way that you’re taking all the friction out of the process. You’re focusing on self-service, you have solid contracts, and you have a lot of automation that they’re able to lean into and leverage.
Ex. What NOT to do
Lift & shift as your only strategy
False equivalence
Activity over outcomes
Re-solving solved problems
Moving existing operational model from data center to the cloud
Manually provisioned infrastructure instead of automation and devops
Rushing to get there without taking the time to go cloud native
Turning a capex problem into an opex problem
Don’t think of it as going fast
Fast will follow smooth
Everyone wants to go fast. But, instead of just thinking about going fast, we want you to think about it as smooth.
That’s really what you’re trying to do from a platform perspective, when you’re building a platform for your organization.
Think about any SaaS product that you’ve used. How many humans do you interact with? What do you need? An email address and a credit card. That’s it. And then you get charged.
Think about that same thing in your organization when you’re trying to do something. When you’re trying to use a service, or your product team is trying to get something going, can it be that simple for them? It should be that easy for teams if you’re sponsoring these innovative ideas, because that’s what you want them to be focused on and spending their time on.
Focus on smooth and fast will follow.
Think about any SaaS product that you’ve used. How many humans do you interact with? What do you need? An email address and a credit card. That’s it. And then you get charged.
Think about that same thing in your organization when you’re trying to do something. When you’re trying to use a service, or your product team is trying to get something going, can it be that simple for them? It should be that easy for teams if you’re sponsoring these innovative ideas, because that’s what you want them to be focused on and spending their time on.
Focus on smooth and fast will follow.
Fail fast?
This was a powerful model for startups. But it’s hard to run that startup motion inside of an enterprise. Failure isn’t tolerated in big enterprises. Big enough failure can be career ending, or if you’re not careful, can put the company in jeopardy. That whole process and cycle of the quarterly earnings calls and annual budgets and everything else - it’s hard to fit that model in.
And yet that’s the challenge that we face.
As technology leaders, we’re expected to be able to support all of these new initiatives and areas for growth. And we’ve got all of this other very real baggage associated with a lot of the technology. But if we’re able to structure it in a platform, then we can do something easier than failing fast and a lot more tolerable to the enterprise.
And yet that’s the challenge that we face.
As technology leaders, we’re expected to be able to support all of these new initiatives and areas for growth. And we’ve got all of this other very real baggage associated with a lot of the technology. But if we’re able to structure it in a platform, then we can do something easier than failing fast and a lot more tolerable to the enterprise.
Failure isn’t tolerated in big enterprises.
Fail fast?
Fail small
When you think of your business and technology landscape as a platform and build as such, you're able to fail much smaller.
You can make smaller bets because you’ve amortized the cost of all the construction of all the foundational stuff. You can make a small bet on an idea, build it without a lot of friction, get it out on the market, test it and get data back. And you can also give it time - the time that it needs - to cross the chasm, and make those pivots that you need.
It’s not easy. None of this is easy. Organizational change isn’t easy. Overcoming behavior, building in the patterns of platforms, it’s not easy. So why do we do it?
We do it for times exactly like this. We are at an inflection point. Getting good at change allows you to be bold and run toward the storm.
It’s not easy. None of this is easy. Organizational change isn’t easy. Overcoming behavior, building in the patterns of platforms, it’s not easy. So why do we do it?
We do it for times exactly like this. We are at an inflection point. Getting good at change allows you to be bold and run toward the storm.
.jpg)
