Radical Change in Corporate IT

Hans van Bommel (Part 1)

September 11, 2023 Hans van Bommel Season 1 Episode 11
Radical Change in Corporate IT
Hans van Bommel (Part 1)
Show Notes Transcript

If you had a magic wand and you could radically modify the way corporate IT engages itself in organizations, what would you change?

That's the question I asked Hans van Bommel, an opinionated, lateral thinker about organizations and digital technology changes.

Hans is an author, crafting thought-provoking narratives that capture the essence of human experiences and sharing insightful perspectives on a wide range of topics.  He is a speaker, an opinion maker, and a conceptualist, exploring abstract notions and translating them into tangible insights and products.   Through Cycle to Accelerate,  Hans provides digital transformation coaching and strategy as well as continuous performance identification and growth.  He is also one of the key contributors behind the Flow Manifesto.

In this 1st part of two podcasts, Hans provides valuable insights such as:

  • Prioritizing knowledge above processes;
  • What is "Substantive Governance";
  • The difference between building models and gathering real data;
  • The 'Domination' processes of the Agile approach;
  • The utmost importance of nurturing a 'Disciplined Language';
R.M.:

Hello, this is R.M. Bastien and welcome to another episode of Expert Advice on Radical Change in Corporate it. In this episode, we have Hans V an Bommel. Hans has worked on major IT projects and digital transformation programs for the last 20 years. And he has, worked, he's a founder, sorry, he's the founder of I T companies like Cycle to Accelerate, SprongQ, Orinoq, c orrect me if I'm wrong...

Hans:

It's, it's , yeah, it's Orinoqo. It's a river . It's a Orinoco River, actually. So then you, but it's Orinoqo. Yeah.

R.M.:

Oh, great. I didn't know that. An d technology company Flukel, I guess.

Hans:

Fluqel! Yes. Yeah , yeah .

R.M.:

Okay. He's the co-founder of the , Flow Manifesto. I will put the links t o F low Manifesto and books in the text below below the podcast. Hans is an author and his opinion articles are regularly published. He i s a c olumnist for Computable Magazine and appears o ften in the Dutch m edia. He has been a speaker at many international events. I've read his books Cycle t o Accelerate Series. It's four small books, e asy to read, and I can tell you that today will be an interesting interview because h e i s certainly a parallel thinker, I would say. So I, I'm really excited because, I think we will have really different ideas today. That's my, that's my expectation. So Hans v an Bommel, Good afternoon, Hans.

Hans:

Thank you for welcoming me. Looking forward to , your questions and the interview.

R.M.:

That's great. So, Hans, it's always the same format. I I only have two questions. Here's the question. If you had a magic wand, you can change anything in medium to large organizations today so that the IT function, you know, the , the IT department, the corporate it, I call it, could be more effective, provide more value, be better at what they're doing, and and the whole company be better at the end. What would you do with that magic wand? And of course , um, uh, it has to be, it has to to be around , uh, not technology. So it's not a magic wand for, you know, having a new technology that doesn't exist today, but it's more like, what would you do in terms of roles or responsibilities, organizational functions, processes and so on. Anything you can think of that you think would radically change the effectiveness and the , the end results that companies get from information technology. Then what would you do with that magic wand?

Hans:

Thank you. I think I have a very clear idea and I will start with , uh, just making a sort of statement. And based on my statement, I will clarify , it with a little story, <laugh> a little presentation of the concept. So personally, I think we should, in an enterprise, put knowledge above processes. We, people intend when we build up our experience that we start to perform better over time. And when we build up more experience and when things and sort of repeatedly , uh, are true, at least for you as an individual or as a group, then we can talk about useful knowledge. The thing is, when we get into an enterprise, one of the big problems is just talking to each other about what an enterprise is about. So how is it structured to start with. And structure often is being used in terms of enterprise architecture, but what I saw over the last 20 years that we, in the whole, let's say cycle of producing IT based on products delivered to market, which need an upgrade or a change or need new technology to keep on existing for an enterprise that we do not have a common language around. And also not a , a common source of knowledge. I sometimes try to describe it as, as the wig , the wig of knowledge, you know, the wig as another lawyer. But how you call somebody who sits in front of the court the

Speaker 4:

Yeah, the judge or the judge.

Hans:

Yes . Yeah , the judge, yeah. So when you are a young, young person these days and you walk in, you are not part of the evolution of complexity of the organization, then you need to start actually, and try to find out that you need to build up this wig of knowledge in a very short time. And it's actually not possible to do that. So you need a lot of years, but nowadays everybody needs to go fast, and that's why they can't keep up and they leave the enterprise anyway again. So we need a system that bridges knowledge over the silos, not on the business side, but on the IT side. So we have silos at the IT side of the, of , of the organization. So the language of the enterprise architect architects is not a common language. And I also think they made , um, everything overly complex themself . If we go to a business architect, we have the same challenge. If we go to a solution architect, they also intend to talk their own language and so on and so on. So if you get into a DevOps teams , they also start to talk their own language. I strongly believe there's one language , possible. But then if we have this language around how do we organize it, and I don't prefer to organize stuff in models, ' cause models always have, again, ? ?? t ruths. So it should be based on real data. So what I like to call is we need a system around which is in one tool and not multiple tools, which we maintain in substantive governance. And w hy substantive governance? Because we talk about substance. S ubstance i s do we deliver a healthcare insurance t hrough society, or are we delivering a car to society? Both a re substance, um, and the substance can be in the form of it's outcome, something we deliver, and it can be in the form of a product or s ervice or what, what, s o, or whatever. But if we talk about how a product is being delivered, we need to know how an enterprise works so that we need capabilities, business capabilities, and these capabilities are supported again, by activities w.

:

e need to execute and to execute a activity. We need information to start with, to gather information, we to deliver a task. This could be a human or a machine task , or we have a set of rules which are executing based on the information we gathered and so on. And it's a whole chain of all of these small blocks. And the automation,

R.M.:

I'm sorry to interrupt. I'm, I'm still stuck on the substantive governance. Nowadays, you know t hat we, governance is used, you know, in many contexts. So there's, you know, corporate governance IT governance data governance, and so on. So how would you d ef differentiate substantive governance Y eah. From the other governances that w e're accustomed to to hear about? So, y eah.

Hans:

So if we , yeah , if we know, yeah , if we know our substance, how your substance is being supported in the enterprise to be delivered to the, to the outside world to society, then the structure of the inside world is by looking from all the dimensions you just mentioned, we need to support it, but also in a language that when we, if we know how we support products, we are delivering to society, we know there's a structure underneath. But everybody coming in and collaborating on upgrading the support of products being delivered, they need to collaborate. But if they don't have a disciplined language around about how , uh, if you call it what is a product or what is a serviceor what is a capability or what is a current and a new IT systems and what facilities are available to get stuff upgraded or changed, or... There are so many things we are discussing about while we are collaborating, that we could only say that we are not a mature , mature discipline yet. So we need to change something. And I think it's partly in a communication and discipline language, but we also need a tool. And nowadays we are okay, we have Confluence, we have Jira, we have Archimate kind of tools , uh, we have tools for continuous delivery, and we have the Trello's and we have so on and so on. So what we are doing ourself on is we are constantly siloing and slicing information about how we collaborate together. And we are actually all in different departments, and we made all these specialists very important. We are not equal in this type because as far as I know, if there's an enterprise architect around he sitting with the CEO around the table, not the rest. I don't mind all t hese status differences, but it implicates that when we communicate with each other, we need to trust that this person who's t he spokesman is talking to the CEO in a right manner. But if you are.. So substative governance is a repository based on a meta model where we can gather the information from a model which everybody, when they enter the collaboration should understand first. And if we understand each other, then collaboration based on knowledge will go faster and faster because we know that when one product needs a , it is upgrade and at the same time we know that the current technology is not supporting us anymore, then we need to do a technology refresh at the same time while we are upgrading it or innovating the products. This means a lot for a team. This understanding is essential. And when you wanna become , when you wanna move forward in the , in the direction of some strategy or goal or at the end the vision, then you need your substance to move along with the goal set of the organization. And , and if, and at the moment, we are lacking the possibility together to get it done because we are too much in discussion, too many things go wrong, and we should experiment more by how can we integrate information and make it real information and not model-based information so we can move forward together a lot faster. And that's what I call substantive governance. And then architects could say, yeah, but we already have these kind of tools, and I do not agree because these are models and they are a , they are not the real data going around. Because you could actually also, when you work based on a substantive governance model, process the real data within the enterprise underneath this model, and then you can as a watchdog look at the data. And what we are communicating about is this actually what is going on at the moment. We are collaborating. This kind of technology is possible at the moment with everything we have outside, but we don't see the market investing in it. And when you can work this way, you can also start making predictions to the future. So I like to challenge industry together to come up with real innovation inside in the middle of, and in the heart of the enterprise. There, where business, it, and even society, people from the outside world or scientists can come in and work together to make these enterprises move forward faster. So if they like to deliver positive impact, which is needed at the moment at the planet, they can also do this as high performance because we do not have a lot of time to solve certain elementary problems in society. So it's carrying knowledge around everywhere you are with the same view of the knowledge for everybody collaborating, that's substantive governance and not from one discipline only speaking the truth. So we need knowledge to , um, be carried along while we are collaborating. And if we do not have knowledge as in the center between us while we are trying to innovate or to talk with each other within all departments, that means that even a , CEO, everybody should start sort of start learning this language. And when people get get in, they also need this language. But it starts with agreeing on how to communicate and taking along , uh, uh, knowledge while we are moving forward reaching our goals as an enterprise. And actually this is called, a lot of people are talking about information and we need information flow around that . Probably that's the same. They all, many people are talking about what we are missing is this language and this information which we commonly intend at least intend to understand or clarify, constantly clarify to each other so we can ramp up success ratio. And why this is needed and why am I such a big fan of flow is the whole idea that the last 20 years Agile became a major hype. But Agile is very process based . It's not taking into account knowledge and understanding and all these kind of stuff. That means that the process and procedures are actually dominating the way we are behaving and the way we work. And that should not be the case. And it's also not scalable because we are unpredictable by definition if we are with more than a couple of people. And an enterprise per definition is unpredictable in regards to its outcome. So it's important that we enable the enterprise with elements to at least try to increase our success ratio and to increase the possibility that we deliver outcome as we desire. And on the, on the road to delivering outcome, we need to be constantly flexible and communicate to assure it's gonna happen. So I always say that flow should be in collaboration, should be in organizing your substance. So that means organizing your substance means having knowledge around in a system, not separated knowledge, but gathered knowledge. And on the other side, we need to create an organizational model, operating model, which is sound, and you need to leave old models out of the enterprise because systems like SAFe, they actually introduce a new operating model. And that doesn't work because then you have about , uh, three, four operating models crossing over each other at the moment within those enterprises. Another thing is that we need technology in place so that when we are out of the the possibilities of our old stuff , that we can always product by product move to a new technology reference architecture. But everybody needs to understand what it is and how it relates to the product in the products, in the enterprise being supported by current technology.

R.M.:

First of all, it's really interesting. This is very dense. You said something a few , uh, a few minutes ago about real information versus models or model-based. Can you explain what you mean by a model not being real information and where is real information versus the model? Because there, because after that you started to, to talk about the fact that, oh, we need a common, a common model. So I thought you were rejecting models and then you said we need a common model. So

Hans:

Yeah , so you , let's say like this, when we look at a tool like there are architectural tools around, and then we start drawing models based on , uh, for instance, Archimate or Enterprise Design , uh, or whatever. So we can agree on, on such language. But so far I've seen it's always used by a select group of people within the enterprise. So a business architect or enterprise architect likes to do it. And what they are doing, they are based on the understanding of the methodology, drawing models, they intend to relate to reality. And as long as it's, these models are just like being used as a tool to clarify and to communicate with each other. But the problem is they go in, they talk with the rest of the enterprise and they never were , uh, a part of the learning process coping with these, with the language within these models. And if you have a meta model for substantive, and it's a meta model, so it's not a visual model, but it's a meta model which embraces the structure, which is actually in production, which is actually carrying the enterprise, and you agree on it. So you have a consensus mechanism called it organizational building blocks, which are part of the substantive governance. These blocks, they definitely have a part like the rules or the policy policies of the enterprise policies for business operation rules by law, they have information defined going around. And what you can do when you process information in a business unit delivering a product, you can actually also process this information through your substantive model itself. So you build a model, but you, when you process, you process real data going through the enterprise. And it's not a visual interpretation of reality based on a methodology, it's based on a structure which we commonly embrace is this is the truth. And that's not what I see enterprise or business architects do. They protect their own models. Um, and when they would stop doing that and more and go more into the production of the enterprise together with everybody and , and we design a common language which engineers are also interested in, that means one common understanding of how products are being supported and not from a to TOGAF perspective, but also from a solution architecture perspective. And I think such models, I'm working based on these models now quite a while , and it makes us much easier to collaborate. And so it's the , it's consensus about the real model, which is supporting products and processing real data, which is being used by business operations through this model. So you're constantly validating when we talk, oh, look, this is exactly the data we are processing now.

R.M.:

Oh, that's interesting. And and when you talk about data, you mean what kind of data?

Hans:

Yeah, there's the information. So let's say information comes in, somebody requests for a product, they need to add information, and this information is to request for a insurance. Then in general perspective, the data comes in, needs to be archived, and we identify the information then when being used by a business unit within the enterprise. This identifier information will get used and we can add context to this information. So in a business unit, and they might even get an extra information about you. And in a certain point when it's done, the result will be archived again and sent out to the client. At the same time, while this process is going on, we can implement other trails, a trail who is actually following this process of we request for a product, it's being archived, it's, it went to the business, decisions were made and it was saved. Again, this audit trail can travel through your substantive governance model. So then when an enterprise architect of whoever in the organization tells us this is the truth, we can actually watch. And it's the truth. The question is, should we, when we stream it, it should not be visible in sense of who, whose data is being processed, but what data is being processed. And then we get reality into our face . And that makes it a lot easier. And, and also then at a certain point when somebody said , now I like to innovate this product, then when our current technology in the the complexity in our current support we get from technology is on the limits of, of, of flexibility, then we can decide product by product to migrate to a new technology reference architecture and keep on going and going and going until all products are being supported by the new one, and so on and so on. Because digital transformation is a process which started 50 years ago, and we'll never stop as long as at least you and I live

R.M.:

Quite interesting. So what you're saying, and , and that's my interpretation, but correct me if I'm wrong, is that there are people that are thinking about how to transform the organization and so on, and they build models, but these models are made in some sort of a silo that use different different languages from the reality that the rest of the organization is living. And it's also just a model. So it just boxes and lines and what you're envisioning is not just boxes and lines, but real data about what's in the boxes or what's in the lines and so on. So that you're not just talking theoretically, you're talking about the real, the real thing . So

Hans:

Yes. And if you then connect , and if you then connect this to, oh , we have vision. If there's no vision, it's a problem anyway. I really believe in vision and strategy, but it's all bounded. Everything is bounded, nothing is precise. But then if you have goals to, to achieve within the next few months or year or two, three years, you could, based on this real data and this model, make projections, projections what you need in the next three months or the next six months. Because further looking further in your projection, then this is not relevant, relevant, but if you have like scientists with a background in knowledge about economy, society, anthropology around, and they make science effect about the context of your enterprise or your business domain, you can reverse it via a data platform, which we are building anyway at the moment to action. And this action is: These and these and these products of these, and these domain needs to be adjusted to be ready in three, four months. So we can cope with new circumstances outside of the enterprise. But as long as we don't do it on real data and we communicate and we do not have this discipline language around this circle, will, will not be closed. And this circle needs to be closed first. Now this flow needs to be installed. And to be honest, agile has nothing to do with it. Agile is a mystery. If I ask agile, explain to me what agile means, then they, they and , and tend to show me a bird flying and adapting, but extrapolate this on an enterprise and they don't know anymore what it is . And I think it need s to be. Now, you do.

R.M.:

That's that's really interesting Hans. Now what you're saying here makes, makes me think. So are you proposing that the q uote u nquote the enterprise repositories, you know, and that idea h as been around for decades for as long as I can remember you know, the enterprise repository where you would have all t his, these models and knowledge and so on. So are you saying that not only this is a good idea, which we should go further than what it usually does and make it make it bigger, better, and include data, not just models and knowledge?

Hans:

So yes. Um yes. And it all starts by this discipline language. If we do not agree about the terms and the structure on which we build this substantive governance, and unfortunately it should not be based on an architectural view only. So the enterprise architecture should not be in the lead. What should be in the lead is all people around the IT production process from business to bringing updated products to production need to get around the table and agree on a model they all understand. We need , what we first of all need is the discipline language, and we need a , um, set of terms, symbols, structure, which everybody in the IT production process, including business of course, does agree with. So what is the core and the heart of this structure? If we need to follow a few people in a silo who think that they are having the truth in their model, then it's also not fine. And we need to agree on, on, on the, on the structure of the substantive governance first, and then we can process real data and we can start making projections. And this makes it possible to put knowledge over processes and then also trying to put everybody in , in a procedure to start working together in an agile way is not necessary anymore

R.M.:

Because everybody will be on the same page in terms of understanding what's the purpose of the , of the enterprise and how we're working, what we're doing, and so on. Is that why?

Hans:

Yeah. So what I, what I , my, my reaction on you is look in the sky, look at a swarm of birds. How is it possible that when there's a leader, there's always certain hierarchy in the swarm, the swarm is going into a direction, but the only way they can do it that they have a joint language a language in how they understand and communicate to move forward. So if we have knowledge in the center of our collaboration and it's always around and we start moving forward,

R.M.:

You're not rejecting processes.

Hans:

No, I'm rejecting that we predefine them. So we need to...Processes are patterns. Who , who we learned of that they work by doing stuff. So you first start doing stuff, then you find out certain patterns work and then you can fix them as saying, these are patterns which we should keep in place.

R.M.:

Thanks a lot, Hans Van Bommel, this is really awesome material, so much to hear and so much more to come. This is the end of part one. In the next one, part two, we will again hear some very interesting ideas from a lateral thinker. (If there's one that certainly Hans von Bommel) Thank you and hope to catch you in the next episode.