Courtesy of Red Hat's Jabe Bloom, below is a transcript of his speaking session on 'Efficiency without sacrificing efficacy: The Three Economies Model' to Build a Thriving Enterprise that took place at BTOES Enterprise Architecture Live Virtual Conference.
Current ways of thinking about software development tend to suggest a (false) dichotomy between Development and Operations. Many organizations are trapped in a pattern that imagines you can either be efficient or effective. However, if efficiency and effectiveness are considered mutually exclusive (that is, you cannot drive both at the same time), it is extremely difficult to drive differentiation and therefore, unique competitive advantage. So how do you accelerate differentiation, while creating resilience and driving scale? The problem isn’t choosing between these initial logics, but instead expanding the way we understand IT works with a third economy: scope.
During this session, Jabe Bloom from Red Hat’s Global Transformation Office will discuss the Three Economies model. Through the three economies - differentiation, scale, and scope - this efficiency and effectiveness paradox needn’t be paradoxical. Organizations can pursue both forms of value (differentiation and scale), by extending their economic decision making to include a third way of thinking about value (scope). You’ll walk away with an understanding of how to adopt the Three Economies model in order to transform your organization.
Our next session is a great leader, and global transformation officer for Red Hat J Bloom, has been working to eliminate and improve the complex interactions between design development and operational excellence in organizations. For more than 20 years. He's an experienced executive leader of software in product development companies, serving in numerous executive roles, including, Chief, Architect Principal, Technical Director, Chief, Technical Officer, and Chief Social Technical Officer. .... Is a part of the Red Hat, Global Transformation Office, a consultancy focused on applying scientific and design design research methodologies to enable exploration, increase, flow, improve, software engineering, and enable operational excellence. J, Please, join us, turn on your camera, join us. We're excited to have you here. Hi there.
Hello. How are you? Today is good honored to have you here. I'm going to exit now, let you share your presentation and guide you through this journey. Thank you very much.
Great, Thank you.
Cool, and hello, everybody. I'd like to talk to you today about what I call the three common model, the way of working in an organization to enable efficiency without impacting or efficacy in the marketplace. Just really quickly, I work at, but at the global transformation office, I'm getting a PHD at Carnegie Mellon. The research that I do at Carnegie Mellon and Forms along the work at the type of research I do there is called Action Research Talk, more about that future.
Is there a reason this is caused?
I don't think you're next in presentation mode, yes. Now, now it looks like you may have moved. Thank you.
Every time I go into presentation mode, it says pause, OK?
Just one second. Sorry, folks.
OK, so these are my co-workers at Red Hat and Shaffer. Kevin Bear.
John Willis: We started about eight months ago, uh, group of people to my left and the picture, Hibell, written a bunch of books together, and published extensively.
Oh my goodness, it's frustrating.
It looks good, I got it, I got it. Yep, thanks. Erin Andrews. The head of the global transformation office, he is widely recognized as being one of the people who started the DevOps movement, focusing on the DevOps days. John Lewis: I think it's books more DevOps days than any any person on the planet. Great guy wrote, the work on the, on the Phoenix Project, wrote DevOps Handbook, there was co-author of Peace Project, and I had the luck of working with him for about the last eight years at a company called Praxis will be started.
So let's get into the presentation really quickly.
What is an economy coating?
It really is just just the idea, that we have some sort of limited set of resources, and we want to distribute those resources across an organization in order to maximize the value of them.
So, the question is, with an economy, is, simply, given what we have, how do we maximize the value of having it, or selling it in the marketplace?
You will note that I have said economies. There's 20 economies in this presentation. So, one of the ways to think about that is that most people tend to think of the economy, then, like, the marketplace in this presentation.
What we're talking about is kind of the logics of how you might deploy resources.
The point of the presentation in a large way, is to say there's actually three separate types of logic that you might use to deploy those resources in front of an organization. And the question has of being how to be maximized value. if we use three different forms of economic theory as a single economic theory. So let's let's explore. Really quickly why this is important. I think most people will recognize this basic problem in most organizations we have kind of like one side of the house, which might you might call kind of development product development and what they want to do is accelerate defray in differentiation and they really, really want to concentrate on the creation of new value. That's their primary focus.
On the other side of the house, we often have some focus on operational excellence. So, maximizing the value of things that we own or can deploy in a marketplace and focus on efficiency.
So, constantly trying to create more value out of the assets we already have by reducing the cost of maintaining them.
So we get these kind of basic structures inside of organizations, a lot of organizations will we see kind of thing, a bifurcation, middle of the organization between central IT, some sort of centralized governance body running all sorts of kind of methodologies and different processes for controlling consumption. And you know, making best practices available and really focused on doing the same thing over and over and over and over again, but being able to really maximize the value of having a repeatable process there. On the other side of the house, we often have multiple business Longings product lines or agile teams.
And their primary focus is almost always on getting more customers. And now, we just getting more customers, but getting into new markets, addressing new types of customers. And so, the fact that they're trying to constantly kind of niche themselves into new parts of the market, find new ways of being in the market, means that they're always trying to do things differently. So, you can see here I've already this kind of schism forming between the two parts of the organization.
And the same paradox could be shown even more deeply if we don't look at the actual monetization of these things.
So, we look at what's happening inside of your development side. Of the house. You're trying to do is increase revenue. You really trying to increase conversion, create, new markets, pricing. All these types of things. And that means that we're trying to constantly create new features, new, versions, new, projects, new products, and constantly, increasing variety.
On the other side of the house, we have kind of operational, large improvement. So, really, how do we get more value from the things that we already have, how to get more value from the customers we serve? How do we serve our customers with less cost to us, and lower the cost them in order to stay competitive in the market?
We're looking at here is more about asset efficiency and CapEx to OpEx, and the number of parties involved, all sorts of things, end up being what's focused on. And the normal way of kind of thinking that is what we need to do is decrease variation in the system. We need to, like, minimize the number of different types of Linux That we're running, or number of, different installations that we have, in order to really maximize the value of the reproducibility of the system.
In DevOps, this kind of traditional way of thinking of this problem, We call the confusion. and the confusion is a traditional way of kind of thinking through how to solve these two economy is the, the change, that the conflict that's happening here.
And the way that most organizations solve that is that they create a policy.
They create a significant set of governing policies and processes that prevent the change that's being generated on the development side of the house, from arriving on the operational side. Of course, What is happening here is that the organization kind of slows down. And because of the two economic logic both actually makes sense to them to the people who are being incented by them.
There's also like, a sense in which both sides of the house don't really understand each other. They don't understand what they're trying to achieve.
Because the mathematical logic that's driving their behavior, efficiency versus effect efficacy is actually opposed to it to themselves. They cannot be resolved directly, right.
So, what we end up with is this idea to different economy, that there are two, economic logic at play. We have one side, and Economic Logic, that is trying to create value by increasing market address billing, would call that, the economy, the economy of differentiation. And on the other side, we have the economy of scale traditional scale economy theory, which is focused on the idea that value is created by efficiency. Deficient value is created by efficiency of the purchasing and deployment of infrastructure, and other ideas like that.
two sides of the same organization. That we're kind of cone shaped back there, has to do with the way in which variation changes across the organization so that we can see that there's a, there's a high value and variation in the differentiation economy and a low value of variation in the scale the company.
Just keep it in mind, as you see, in these different pictures.
So, we might think about paradoxes like this, is that they allow us to start having conversation inside of our organizations about how to solve for this.
In the traditional, to call me, framing efficiency versus efficacy argument ends up happening is what one side has to lose. It's a zero-sum game, There's, there's only one side can win because of the way the arguments framed around differentiation or similarity and Rebecca, variation.
So the question is, can we kind of come up with a way of playing out, that this paradox isn't truly paradoxical.
And in fact, there's a way in which we can create a win-win in which organizations can develop and have both an ability to accelerate market differentiation and an ability to efficiently create and maintain the infrastructure that they own done.
That's where the three counties law comes in.
We're going to add, is this, is this idea of what's called the economies of scope. And we'll talk a lot about it this afternoon. Or this morning, depending on where you are. The main difference here, the thing to be really kind of focused on is that the difference between scale and scope, which is often confused, so the way that we use these theories.
Scale is a scale, applies to theories. Scale applies to the management of resources that can be consumed.
So I don't think any of that. In ITV, there are certain resources that can be consumed things like your CPU pool, your network, your storage, all these physical devices. In your organization, or your leasing, or renting from another organization, by some sort of cloud provider. All those things can be overused, and, therefore, they require a certain set of governing processes in order to prevent their overuse and to plan for their future, so how much are we going to need next year's growth? And resource planning problems. Look, those types of resources require that type of governance, because if they're just kind of given out to your organization ***** nilly, they will impact the organization.
Clearly, when the system goes out And kind of critically, really, Another kind of important part of what's happening currently is that, it used to be that you, you, your team, would get an individual server and maybe the network could be overloaded. But, really, if you did something bad, you overused your resources that the only people who would be impacted would be, you, know. Your server would be impacted.
But now, when we talk about, kind of, cloud, native, liquid, markets of CPU, compute, where, if we overuse the compute pool, it affects everyone.
It's not just your, your particular application that will go down. So Auto scaling, and things like this could impact not just you, the entire organization. So the governance of those kind of critical consumable resources is really important. On the other hand, there's a whole set of resources that any organization has been, are not consumed in use. And this is the importance of the scope economy. So what do, I mean by that? Well, if you have, for instance, 20, different developmental, all of them are kind of developing, either variations are different applications, and they all have kind of data silos so they all have their own customer record. Well. If you want to know, like, how many customers to your enterprise have, as opposed to how many customers does this application have?
You have to figure out how to get the customer record out of those data silos consolidated, de dupe it, and clean it up In order to be able to make a report.
Let's say I'm customers. You actually have unique.
So, this, in many organizations, ends up being like a batch process, and it is used primarily for reporting purposes. On the other hand, if you if you somehow created a place in which that customer record was shared amongst the 20 teams, not kind of Data Silo into 20 teams so that they could update and consume that shared resource. They would benefit from it and all that.
But the more teams that use that, that centralized shared resource, the more people that use that customer record, the more valuable it would become, both to the organization and to the end customer himself.
So, school economies have to deal with maximizing the use of resources that are not consumed and those things. Or include things like data, structures, well formed functions. So, you can think of like microservices.
Or serverless functions. And patterns of utilization and consumption, so that you can think about things like cloud native patterns, the way in which your platform is consumed, in your business, things like that.
All those things are examples of resources your organization has that would be sub optimally deployed if they were deployed and using scale style governance. Because governance is beside it. Sidedly designed to prevent people from using things, and in this case, the whole point of the things is that the more people that use them, the better they are for people that are involved.
What we end up with is kind of like three economies that are based on these three high level ideas, like creating marbling, creating more shared resources there.
Increase in value with use, and creating efficiency of consumable resource. So differentiation, scope, scale.
We can see that this means that we end up having kind of different focuses of our, our development efforts.
In these three different places, your development teams, your software, or your product development teams, are really heavily focused on novel value creation to the extent that those development teams end up developing things that should be scope academy.
In other words, they're developing re-usable components that then maybe are consumed by other development teams. They are actually distracted from the creation of novel value.
Because what they end up doing is maintaining the the libraries and functions and operations of a shared resource.
And that distracts them from this kind of really raise your focus on what customers want.
The scope economy, what we're trying to do is create an enabling experience.
So, this is an idea that if we do still variation in the system, we can increase the variety of the output of the system, which is kind of a tricky way to say that. like, if you can stay in control of the development process, you can actually create more different options to deploy into the marketplace. To the extent that you you are out of control. Your system has low quality, or has high variability. You, also, at the same time, limit the number of options you can deploy in the market, just because it costs so much to maintain these various systems. And also, you want this kind of focus on self-service, so.
So, the teams should be able to both kind of submit patches to be put into a system of shared system. So, using some sort of inner source theory or be able to access infrastructure and infrastructural components.
Um, finally, we get the scale economy and the scale economy is really focused on kind of that reliable compute network and storage produce. So, really focused on managing a set of economic requirements that actually extend outside of your organization.
So, for instance, there's almost no organization in the world other than maybe Apple or Google who are going to define the economics of Moore's Law or define when to update your network for it, like from four G to five G or define the cost of compute or the speed of network storage, right? All those things are that such a large scale that your organization is primarily kind of saddled with managing vendor relationships and making sure that you're efficiently acquiring and deploying those types of resources. So that's your scale.
Again, we kinda get this idea of flexibility, adaptability, and standardization.
And when we look at the scope of Kali really try to focus on Is this kind of increase in resilience and use of something called recombinant? So what, what is, what is recovery?
What do we, what do, we, what do, I mean, when I say ..., So one of the things that we see in a lot of organizations, if they don't have a concept of free economy, is if they don't have a concept of the scope economy.
That means that the resources that they have been developing, well, purchasing, are deployed into only one of the two economic theories that they currently have.
The result of that is that when we go in, and we try to talk to people about the importance of scope, Kami, is that we end up having to point out to them. That often the resources and if they already deploy are probably being sub optimally managed by the wrong economic theory. So they're actually using the wrong economic idea to manage the resource. And what I mean wrong, what I mean, is that they're not the economics, or they're using is not optimized for what they want to get out of the system, right?
And so, for instance, in differentiation, I kind of gave an example already, of a team that might create a resource, data structure, or some sort of function, that then other teams in the organization want to have access to. And so then that team ends up being saddled with not only focusing on the customer, but also focusing on servicing other parts of the organization or other teams in the organization.
And so, the economic theory of accelerate differentiation and really focus on customer model needs ends up being difficult to do, because the teams now being split with their focus, Right. So in that case, we would want to move or re common those, those types of resources into this scope economy.
And the second one would be parts of the organization, or our things inside the organization that have been moved into the scale economy.
Often, I see this, frankly, as people who try to do things like master data or things like that, where they want to really heavily govern the data structures or or access to patterns. So again, a really strict utilization of reference architectures without any attempt to kind of negotiate or understand the value of differentiation.
So, these things end up being, instead of manage the scope style, End up being managed in the scale style, And the result of that tends to be, that organization to adopt a push mechanism, as opposed to a pull mechanism, in order to get them into place. So. your enterprise architects, pushing reference architecture, John plans, as opposed to negotiating the best outcome, using something like out of scope. So again, the recombinant here would be to determine which parts of the organization, which, which parts, which things, which resources inside the organization, have been kinda put into a scale based economic theory. and move them back into a scope based economic theory.
Recombinant really is kind of three steps, understand the nature of the different resources, understand the difference between consumer ability, reproducibility, and differentiation. Really, kind of be able to understand why each of these economic theories optimizes person for the nature of the resources being managed, as opposed to some other theory.
Determining the appropriate economic rationality. So figure out which economy to put them in, and then actually, kind of governing and negotiating the movement of the resources from one of these economies to another.
So transformation to X: Your digital transformation is should evolve, recognizing, and realigning around the tree economic frames and then ... your misplaced resources. So that's great, and everybody's gonna run away from this and it's going to be great! They'll all have instant success with transformation. Right?
Well, 30% of all digital transformation scale. This is just a big, super common thing that transformations are not being successful.
And there's huge amounts of resources being deployed in order to get these things to work.
And what we see when we look at this, we see there's five primary sources of building around these transformations: leadership preventing change, product, not building things, not listening customers well enough, not having that feedback loop, not being able to see what the customers want. Development, building the wrong things, architecture. Building things wrong.
And, finally, operations, overly focused on incidents and out outages.
So, we can turn that upside down and say what we want to have happen during a transformation. A transformation really requires these five elements to be in place, or to be successful. We need executive sponsorship, and, kind of the, the ability for leadership to create the space for the transformation to occur. We need product really understand strategic requirements, so to understand, not only kind of the rapid, rapid fire kind of feature, we're theory of product development, but actually be able to extend their kind of timeframe to understand, strategy and deploy strategically.
Development needs to deliver the right features at the right time.
Architecture needs to really make it make doing the right thing with the architecture easy.
So, again, less of the push system, more of the whole system, really getting developers, product operations to understand the value, the architecture. And finally, operations needs to focus on keeping those systems running smoothly, so that people who are consuming the resources that operations provides, assume, by default, that the system will be kind of continuously available. Even even though behind the curtains often operations, it's constantly working to make those things available.
It's really critical when you, when you think for this part, to understand that these aren't roles, right?
These are capabilities the organization is to have. Having someone in the architecture role does not mean you have architecture. So most organizations have these kind of roles in house. They think they have people are assigned to these five different areas. But many organizations still do not have these capabilities.
And so, one of the things we think about this is that part of why they don't develop these kind of, these kind of capability as well, is because there's a missing balance between the investment in various areas. So, it's kind of a really quick version of this would be.
Transformation often occurs by first hiring an Agile Agile group to come in and help your development team develop stuff faster, right? By need more features faster, more agile, more responsive to my customers. Better feedback loops with my customer. That happens.
And you're on your development.
Teams actually produce software significantly quicker, faster, often of higher quality. But then the operations team with that walls confusion theory becomes overwhelmed by the rate of change, the width, the practices that they had for managing occasional deployments do not work well with frequent deployments. And so then you kind of have that DevOps moment where you kind of try to balance the developers of the operations people. At some point during your development.
During your DevOps journey, you've come to recognize that the architecture, the way that you architect your systems, as you move to the cloud, as you move towards a platform based, container based system, it's not architected a way that allows you to accelerate both development operations at the same time.
So, now, now, we have like, a third kind of challenge to overcome, which is kind of the architecture being, kind of brought in and made to work in a way that allows this New Way of working.
And then, finally, if you get all three of those things aligned, then product needs to actually recognize that they've made is a faster gatling gun. But they, then, they need to put a good scope on it, and make sure that they're focused on kind of, grabbing the most value out of the market as possible without just kind of ***** nilly, firing, bullets down downstream.
one of the things to say is that, like, this, five element theory need to balance things correctly. The other is to say that those three different or four different transition, those four different kinds of challenges, are highly predictable. And one of the ways to lower the cost, lower the cost of moving through those transitions, is to know that they're going to occur and balance your investment across all five of these areas from the beginning. So, don't wait until the challenge occurs. But instead, bringing people along for the journey the hallway.
So, create the conditions that make the transformation possible, and create the conditions that makes the transformation inevitable.
And so, that, that means that these five elements, pieces, right, which are about kind of social practice, and the way that we work together, needs to be overlaid with the technical economic theory that we had in the beginning, right?
What we need is the ability for organizations to understand how these five elements or are applied across these three economic theories in order to create value faster.
And what we call this is kinda platform is interface.
And the idea is to replace the wall confusion with a platform. And so, doctor ... says, the platforms can be understood as a way of redefining binary relationships to create a middleman. And thus, we can re common resource management through negotiation. So, again, the use of the scope economy is the place in which the balance of those different pieces becomes negotiated as opposed to becoming a zero-sum game.
So one example of this would be to adopt something like OpenShift and understand the value of things like continuous compliance. And Kubernetes, as a way of creating a set of enabling constraints that accelerate the development of differentiation, well isolating the efficiencies that is required on the other side. And then the second step might be recombination different pieces of your organization's resources into your platform.
So, to finish up, when we think about the three economies, we're trying to manage for different value, or trying to enable the management of different value inside the same organization, When we're looking at scope economies, we really want to do is be really thin. We want them, like, not create huge amounts of code. Because we want a lot of it to be disposable. things that don't work should be killed quickly.
And as an organization, where you can product development, you should be able to pay to learn, But you do need to be able to kill things quickly.
So that pile of proof of concepts that's running still, this is a sign that you, you aren't able to manage that economy yet. We need to really kill off things that aren't effective.
Look at the scope currently, though, we're looking at accelerating at the option. Really, we're creating profits here by increasing the value of a re-usable components by making them more accessible. And increasingly, adoption of those things across your organization. And finally, when we look at scope economy, we're really focusing on that efficiency, based on the theory that the top line or the marginal cost of your resources is not something that can be changed. But the management of those resources is something that can be changed and, therefore, you can create a friction. And, that is my presentation. And thank you, guys, for having me.
Fantastic, fantastic. Thank you so much CCR able to get to the share button on the interface and the stop sharing the presentation so that they can see us on the, on the big screen. There you go. You got it, thank you very much. So, as you are presenting, we had a number of questions come in and I will pose them to right now.
the first one, let me get to questions on my main screen here. The first one came from.
From Tonya or Keys and Tanya says hello Js, I believe that the pandemic is forcing a tradeoff between the two economies in order to achieve resilience. I appreciate your thoughts as to whether organizations will accelerate the resolution of such a tradeoff.
I do, I think, I think you said a lot of good terms there. I think one of the things that I like to talk about is that your scale based economies can only ever produce reliability. They can't produce resilience. Resilience is a process, or a way of being that that is created by human beings interacting with technology. And so the resilience actually comes from people being able to kind of cope with change. So, reliability has to do with purely kind of mechanical mechanistic, probabilistic theories of how, how reliable system will be resilience. The ability to adapt to and absorb changed. That's something you can only get from a development of a scope economy in my opinion.
So to the extent that we have kind of these big impacts that are coming from change right now.
And the really accelerated impact is something why Corbett is. Where is it highlighting the organization that developed kind of the ability to be resilient?
Most of the organizations would be most most the most successful. The organizations that have failed to become resilience are the ones that are having the hardest time right now.
So to the extent that you're interested in those things, what my studies, which show is that the development of these kind of platforms where platform isn't just the technology, but the combination of human negotiations, of need, and technology together, in order to create a common set of resources.
That's the way that people are going to be able to accelerate out of this, into, into the new normal that we get afterwards.
Very good, very good. Mercedes poses has some commentary about capabilities and. She says that most companies have roles, but not always have the needed capabilities, and she, she, she has a bit of commentary on that. And the question is, how do you assure that you get both, you know, just capabilities and the roles at the companies to carry forward? This is the sort of transformation.
When you look at organizations, one of the things that, I see, what that, when organizations come, heavily role based is, that they assign responsibility for specific functions in the organization. Specific people from the things that we've tried to point out. Things like product management development, architecture and operations are not things that one person can do by themselves, not, even a team of people can do it by themselves. It is across the organization that something like architecture occurred.
So, you, an architect cannot do architecture architecture. The development team and the operation team are required to be involved in creating the actual end result by the architecture that actually exist. So when I usually think about this, there's two things that I tell people that I think are critical. one is to take what's what I call a crew based theory, which is, whenever you're designing a role, designer roles relationship to other roles. Who will you be responsible? Not just for kind of telling what to do, but instead, who are you responsible for negotiating the thing that you're responsible for, width.
And the second thing is, just to say, so that's the current base There is.
The second thing is just when you're measuring your transformation, as a manager of those people, measure the number of pure wise conversations that are occurring at multiple layers inside your organization. The more you see peers talking to each other. And kind of discussing what needs to happen, discussing strategy and tactics together. Especially if those peers report up into different parts of the organization, the more likely your transformation is going to be successful.
And that's just simply because the lower down in your organization, you go the minute a conflict starts, and they can't resolve it themselves. The conflict will bubble up in the organization until you hit the joint point in the organization where those two tools kind of come together on the org chart. And that person will be asked to resolve the conflict and often, they simply don't have the information required to make a good decision. So, by, by, by increasing ... communications and increasingly ability to have productive conflict and productive, negotiation, slower in the organization, not only increase and distribute, making, but you increase the ability to make good decisions.
Very good. Very good. The next comment and question is related to a very powerful statement You made that that that you have to create the conditions that make the transformation in answerable. Question is: how do you create those conditions?
So I think this is a good question. It's a challenge question. The first thing I would say is that in most organizations that I work with, there's already a set of conditions in place. So, you could think of like conditions can include things like the way that your current service now works, the processes that you have in place, the kind of the policies and theories that are inside your organization. And I like to point out to people that all those things are usually put in place to prevent people from doing things that would be dangerous to the organization. And part of the idea of adopting new technology and trying to advance the organization to IT, is, is in theory, to create new possibilities that are safe. So there's a conflict. Here, you get a set of policies that are designed to stop you from doing things, and you adopt instead of technologies that are supposed to enable you to do new things.
And when these things come in conflict, you get a, feel, this kind of lack of ability for the organization to respond to the change. So, a really simple version of it. How many organizations had a set of policy for managing rack and stack servers? Then apply that same policy to VMs. And is now applying those same policies to containers. Even though the technologies are radically different and actually are trying to enable completely different behaviors. So, the first thing is to really understand that there already are a set of conditions inside your organization, the tools, and policies that you enable your organization to have. Those conditions are what create culture and things like that new organization. So, part of it is to really re-examine as you adopt new technology, those previous policies, those previous ways of operating processes to make sure that they're in alignment with the new technology adopted.
The same thing is to really, obviously recognize that if you imagine your IT organization being fang, like in any way being kind of one of the big kind of Facebook, Apple, Google people need to recognize that all of them have this scope, a colony, as an internal platform where these things get negotiated. And that is a huge, huge benefit for those organizations. So really adopting an ability to manage across these three technology things is part of making sure that these conditions are in play. And that means adopting I think, technologies and processes, so alignment with that scope.
I have to say that the code that you had about progress and paradox is very powerful. On our own experience working with hundreds of organizations, we have found that the Great Enduring organizations of our time, they are masters of contradictions where we had discourses, bullying very different directions. And we often say that the world of greatness isn't and the world not on our world because about how you bring this contradictions together, and you have done a really good job of showing that in the context of the free economies. Now, very last question here, there's a very practical question, is, Is more of a practitioner's perspective. What technology is right now you see are ready for prime time. They are really accelerating digital transformation and creating disproportional value today.
So, um, know, I work for a technology provider. So, I know, I think OpenShift is providing huge value for organizations that are adopting it. Well, I think along with that, things like SRE and DevOps practices aligned with those technologies are the things that are really unleashing things for people right now.
What am I still organizations right now, is that a lot a lot of organizations have spent a good deal of time and money over the last 20 years, investing in Agile. And they're frustrated that they aren't getting the returns that they expected aren't they're not getting that explosive differentiation that they were expecting. And one of the things I point out is that by adopting these kind of platforms and these platform teams and platform practices, you literally unleashing the investment that you had an agile, because now you can actually do the thing that Agile describes, which is small, lightweight team pursuing a specific market for a specific customer while unleashing them from the maintenance of common resources that the organization needs to have in order to do those things.
So, I think that's that, to me, really understanding that, and the nature of kind of like infrastructure, platform, and an application operation, That is the thing that I think is really causing the most kind of impact right now. I think, I think Kubernetes is a generational impact, technology, that is going to have a huge impact on work.
Jay, thank you so much for joining us today, Sharing and thought leadership, and also provided is very practical perspective, about technology in the digital transformation context. So, thank you very much for being with us.
Thank you for that. Thank you for having me.
All right, ladies and gentlemen, This concludes our segment, and that in our next segment at the top of the hour, we are going to meet with doctor ..., and he's going to talk about process led to digital transformation, from priority to value, Not want to miss a session, Wraps up the day with a with a wonderful journey on to value creation and understanding what a process lead this transformation, truly looks like from a global expert. So, look forward to seeing you at the top of the hour, and bye for now.
Global Transformation Office,
Jabe Bloom has led teams and companies and developed software and products for almost 20 years. He has served as a Chief Architect, Principal Technical Director and Chief Technical Officer. In each of these roles his focus has been on connecting creative, ideation processes with software engineering and operational excellence.
Jabe’s deep practical experience, constant experimentation, and extensive theoretical investigations and readings inform his public speaking and provide a foundation for his active mentorship to colleagues, clients and entrepreneurs. As a consultant, public speaker and writer, he works with a diverse clientele. He advises and trains clients on innovation and flow thinking through a series of lectures, workshops, classes and consulting.
Jabe has been a guest lecturer on Abductive Thinking and Creativity at NYU’s Berkley Center for Entrepreneurship & Innovation. He is an internationally recognized keynote speaker, addressing topics such as Lean Systems, LeanUX, Complexity Theory, Psychology and Sociology, Management as Design and Design Thinking.
He is currently the Chief Flow Officer at PraxisFlow, a consultancy that helps organizations take a systems level view of their work. Mr. Bloom holds a bachelor’s degree in Photography & Philosophy from Bard College (NY) and is currently pursuing a PhD in Design Studies at Carnegie Mellon University.
Jabe can be found with wife and his children in Pittsburgh, when he is not, in a classroom, on a plane or reading in a hotel room.
I try to collect and tell interesting stories about the future…. Sometimes, when people find the stories compelling enough, they use them to make useful things.
Watch On-Demand Recording - Access all sessions from progressive thought leaders free of charge from our industry leading virtual conferences.Watch On-Demand Recordings For Free
November 3-4, 2020
Courtesy of SAP's Aura Bhattacharjee, below is a transcript of his speaking session on 'Enterprise Architecture in Mondelēz, one of the largest snack ...
Read this article about HP, Best Achievement in Operational Excellence to deliver Digital Transformation, selected by the independent judging panel, ...
Read this article about BMO Financial Group, one of our finalists, in the category Best Achievement in Operational Excellence to deliver Digital ...
Read this article about Cognizant, Best Achievement in Technology Enabled Process Automation (Robotic Process Automation, Machine Learning, Cognitive ...