Radical Change in Corporate IT

Wolfgang Göbl

March 30, 2020 R.M. Season 1 Episode 2
Radical Change in Corporate IT
Wolfgang Göbl
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 we asked Wolfgang Göbl, founder and President of the Architectural Thinking Association®

Wolfgang provides great answers to the question, with a focus on accountability.  
In addition, he shares his opinions on several important topics, including:

  • The CIO, a role that is bound to become irrelevant;
  • Why certain key tasks should not be left to a distinct IT team;
  • The death of the corporate IT department;
  • The importance of the vocabulary when designing business change;
  • Why the devil may hide in too much detail;

R.M.:   0:04
Hello, this is R.M. Bastien and welcome to another episode of the podcast series on radical change in Corporate IT.  Today meet Wolfgang Göbl.  He's the founder and president of the Architectural Thinking Association.  He's a lateral thinker and a visionary with a passion for challenging state of the art concepts from new and exciting viewpoints. He's been working in the field of Enterprise Architecture Management and Business Architecture in several large companies in Austria for 12 years now.  In addition to his job as a lead IT consultant at Iteratec in Vienna, he is a recognized speaker at various EAM conferences and author of several publications in journals in Germany and Austria. Mr Göbl teaches a "new way" of enterprise architecture management at Donau University in Krems, Austria.  Welcome, Wolfgang!

Wolfgang:   1:06
Well, good afternoon! I'm happy to be there.

R.M.:   1:09
The questions are simple. Leaving aside the challenges that you know are inevitable when you want to change something to an organization, imagine how the power a magic wand to influence radically the way IT engages itself within organizations, how would you redefine that relationship?  What would be the changes in the roles and the skills and the interactions, collaboration models, structures, incentives or anything worth changing in your mind, would you envision for the IT capability to change too. And how would you see that happening in order to maximize, the value that IT provides?

Wolfgang:   1:53
Well, yeah, I think first of all, I think we should stop thinking about an IT department and business department, and business people and IT people; so that's how companies are organized today.  But I think this will change in the future.  So my vision is that there will be no IT  departments in 10 years from now. I think that it won't be because think about digital transformation: that means that IT it's more and more interwoven into business processes.  So business people need to understand basic concepts of, maybe, architecture, artificial intelligence and so on.  And IT people need to understand processes and so on.  So I think what we see with digital transformation is that business and IT is about to merge into one. So then, the question it is simple to answer.   The thing is that there will be no IT department.  And there are already how many some companies in Germany --for example BMW-- they have the approached this Biz Dev Ops model,  where business people and development and operation people work together and produce value streams from business to operations. I think this is a model for the future; I believe this.  But to make this happen, what would will be needed is that, the basics skills, to think in elements and relations, to think a bit like an engineer, not not only as an engineer, it's what we call architectural thinking.   Engineers, when they come from the IT side, they are trained and they're used to structure things here.  So, as an IT engineer, you structure things into methods and components and database tables, and then relations to other database tables so that the way of thinking what you learn at technical university is exactly: you think like an engineer, you think like an architect and you have a quite structured way of thinking. And for me, it's a quite natural consequence of digital transformation to make this,  to build the bridges so that business people must and will start to think also in architectural structure because some off them already do.  Hey, you have process managers, for example, they are related business; and you have product managers, you have service designers,  you have many people in the business that already think in structures, but usually the structures are not connected very well. The disciplines are not connected; that's our vision.   What I believe is, yes,  that's a basic skill to be aware that you as a person or you as a discipline or the thing you model the product and service is and so on, it's just one part of the business architecture, of the structure. If you think architecturally, this means that you are aware, how the things are related to each other. How the services are connected to the processes; how are the products connected to the processes and then how the process connected to IT applications, and at the end to technology components and so on. Everything, of course, is connected. IT people are quite well trained in this way of thinking; business people are not.   So our vision, at Architectural Thinking Association is to bring this mindset and this way of thinking to the business side and we believe that would make an amazing difference to what happens today. Because today business people blame IT that complexity is increasing, that IT is totally out of control, everything is so slow and expensive in IT... and so what it means is that the architecture, IT architecture, isn't well designed at all. It has grown over the last 20 or 30 years and its complexity is overwhelming and so on.  But it's not okay if business blames IT because it was a business problem because business people made the wrong business decision.   They ordered the wrong projects. They paid for the wrong IT applications. They never spent the money to refactor,  to re-engineer existing structures. So what we have today are non-adaptive IT structures and these non-adaptive IT structures are the consequence of bad IT decisions. What we want to change is help the people make better IT decisions, make more sustainable business and IT decisions.  So business structures drive the IT structures not vice versa of course.  Yeah, so that that's that's my answer: we must make architecture a management instrument so that executives, when they make big decisions, strategic decisions, when they decide to launch a product or to close, to drop a product or so, or change organizational units.  So they make big decisions, but today, usually they make decisions on bad information. What we believe is that it's possible to implement business architecture models and make it natural for executives and the business people to work with them and make it mandatory to have it in a boardroom and so that the C-level executives get used to using simple maps and say, "OK, what shall I decide when I when I make this decision, what's the consequence on that part of the business structure?" Yeah, yeah, that's our vision.

R.M.:   7:15
So what you're saying, Wolfgang, is that the disappearance of the IT  department is in fact, to want business people to evolve and become, you know, architects of their business and the IT that supports it.  Is that you're getting at?

Wolfgang:   7:32
Yeah.  So, of course, you will always have people that are trained and that are business architect and what's happening today is that they usually come out off the IT department.  That's natural. You start as a software architect and maybe enterprise architect, and you call yourself a business architect. But in reality business people know the business much better. So I think that the easier way is to make them aware and think architecturally, and welcome and embrace architectural thinking. It's not not our it's not IT stuff.  Architecture's not IT stuff. It's their accountability. Then they must feel accountable. And, of course, they need business architects that are skilled and that are trained in capability modeling and so on to facilitate between the different stakeholders. But what  I see today is that the business thinks "okay, architecture, this is techie, it's IT stuff, we don't understand what they're doing but it's expensive, and it's slow; we don't need that".  But we believe if you change this mindset and make them feel accountable, this would change everything and it would lead over time to sustainable adaptive enterprises architectures started at the business side. Business architecture is there. The Business Architecture Guild has the BizBok and so on, but it hasn't made it to a broader audience. Still, BizBok is business architecture for business architects. It's not business architecture for business people. Still, it's a small, small group of people that does business architecture, and it must be open.  It must be a natural concept, like finance or so on. Every company does finance, but companies should do also architectural thinking. It's natural, that's where we wanna go.

R.M.:   9:12
Okay, that's great. Great Wolfgang. A great answer.  So what I'm hearing also is that you feel that there is currently a knowledge gap, and it's probably why the business people have left to the IT department these important tasks in the past. But what you envision is that, you know, they should. The knowledge gap should be filled at least partially,  so that they could take a handle out of the architecture of their business. And, of course, the IT  that's behind. Is that all right where to say it?

Wolfgang:   9:47
Yeah, I think accountability is important. So if you don't feel accountable for your structure, then you hare not accountable for the engine you're running on. It's like a captain on a ship here that there's a lot of pass around leadership and cultural agile  organization and people and soft skills and so on and that's important, of course. But if you don't take care of your engine and IT is the engine and also the business structure, the processes and so on, it's like a factory. If you I don't care about your processes and you're just IT and business structures and you don't care about them, business will never be agile, adaptive. So yeah, for me, most importantly, make them feel accountable. And of course, we must train them. I think it's important to make business architecture part of the curriculum of business schools. So today when you go to a technical university, you learn to engineer. Or if you're building engineer, when you when you go to technical university then you think architecturally,  because that's natural.  But when you go to business school, you don't.  We must change it because business architecture, it's not rocket science. You have capabilities and you have processes and information objects. For me, they are simple concepts, but not taught at business schools.

R.M.:   11:07
That's interesting, Wolfgang. So at the beginning, when you first answered my question, you said there won't be any IT anymore in the future but I'm tempted to ask:  well, there must be something that will still be an IT department. For example, you know, running computers or... don't you feel that there will still be an IT department?

Wolfgang:   11:30
I'm not sure if there will be a IT department. What I think is that the technical aspect. So IT disappears in the cloud.   So I don't care where my server runs.  Today with Amazon and Microsoft Azure and so on, the server is already gone. Then, of course, there is software-as-a-service. You can rent already applications in the cloud. So the technology is here.  So the question is what is IT when the servers and the applications are hidden in the cloud somewhere it's just cost there you pay some money and then you rent to software you use.  So cloud makes IT disappear. Of course, you need people that define the functionality of the applications. You need people that define the data structures and the interfaces to the outer world and so on. So I won't call them IT people anymore. These are people that are able to think analytically and that are able to structure more cloudy, embark business information and make them more and more precise.   So I wouldn't differentiate between business and IT.  Actually I wouldn't differentiate between business. When you start with a project, one has a vision for a new product, you start with a vision and not with precision.  And then you need to have a process that adds more and more details and more and more analytical thinking.  And at the end of this project, at the end of this process, you deploy something in the cloud. But it's not so much about business and IT anymore. It's much more about precision. It's about the business idea that is high level, right at the beginning. And then you need really brilliant business analysts, business architects, that are able to convert this vision into more precision. For me, it is that's not business and IT: it's just different levels of precision.

R.M.:   13:32
I see... So what you're envisioning is: no IT department anymore, no over-the-counter kind of requests to IT. But nevertheless, there would be specialties. You know, people that are versed into levels of details where maybe, let's say marketing executive cannot get down into, but that's OK because at some point you need to get into the details. Is that what you mean?

Wolfgang:   14:00
Yes, that's it. And it must become a seamless process. It's not like today you have business and defining the requirements, and then you pass them to IT and they say "No these requirements don't make any sense and that they are not feasible at all. We can't build this".   So today that's not a seamless process. Natural thing is: you start with a vision, and then you define your business architecture.  So it's more precision; it adds more detail  to your business vision.   And then you have the business architecture that gives you a feeling and defines the high level business processes, for example. And when you have them, you can detail the business process and then you add the information objects and define okay which information objects we need to run this capability, or about which information do I need to run this process on when I'm finished with this, the question is "okay, what attributes do we need in this information object?  So it's, I think, that, that meta-model elements you need for this process are already there.  You have commit to a vision; you need business capabilities; you need processes on various levels. You need information objects on various levels, and that's it! And then you need of course, a brilliant use interface designer that builds the user interfaces,  based on information and processes.

R.M.:   15:17
So for our C-level executives in the audience here (are fictitious audience) does it mean that, you know, in 10 years from now, there will not be any CIOs anymore?

Wolfgang:   15:29
Sure. I bet.   There won't.  The role doesn't make any sense anymore. Doesn't make any sense.

R.M.:   15:38
That's a big statement!  But I'm glad...I  knew, Wolfgang, you wouldn't be afraid to say it.

Wolfgang:   15:44
Ha ha!  But I don't want to scare anybody,

R.M.:   15:48
But they have 10 years to get there.  So the second question is kind of a continuation of the first anyway, is: okay now, given that's where you want things to be in the future, where should an organization start, I mean tomorrow or next year let's say?   Where should they put their energy first to get to that point?

Wolfgang:   16:11
I think first of all, it makes sense to invest in business architects.  So hire well trained business architects and let them create the capability model.  A well designed capability model of the current business. That's easy. It's not that much effort to do so. So if you have highly skilled business architects, they can do that for you. And a good capability model means that it's easy to understand and accepted and used by executives. My experience is that when you have really crystal clear one and a simple one and when you add your budgeting and your finance processes, to these capabilities, it's an awesome management instruments. So if you wan't to have a quick win, yeah, hire business architect, build a capability model and connect the capability model with money, investment strategies. Bring it to the board room and let executives make decisions based on the current capability maps. When, when you have this, we can point your finger to:  okay, we want to invest in capability A. Or we want to reduce investment there.  Or we have some a strategic goal. For example, you have a strategical in your enterprise, where is it located on the capability? What new capabilities to I  need to support this new strategic goals? What I feel it's amazingly powerful. So for me I would always start with this because it's quite a quick win. A trained business architect  can in half a year a year or so can create the capability map that is accepted and used in a large company. It's not that it's not rocket science. It's just you need to hire the right one because I've seen many, many capability models that were un-useful that were not usable.  Usually people that model business capabilities, they're coming from their IT side.  They are IT architects and later call themselves business architects, and they tend to make things complicated and t hey tend to be too precise.  And there's the  the precision arguments... When you start in IT what you're trained in his detailed precision, detailed data modelling . And I'd say that 90% of capability models are far too detailed and not in the language of the business people.  They don't have... they have too much precision, you know? I mean, you're really want to implement business capability as a management instrument, you mustn't be precise. You must speak the language of the executives. So great business architectures, business capability map is always in the language of the business people.  And that sounds easy and sounds obvious, but I've not seen very often in practice.   Yeah, but Okay. So that's where I would start.   And what I experienced is that when you implement this and want the executives and business people work with this, it's so powerful and they start to think architecturally. And once you have this, you connect it, you can connect it with your customer journeys. It's quite natural. It's the starting point for business architecture.  The starting point for architectural thinking.   And then, of course, you should train your people and say "Okay? We want to be sustainable. We want now to design our enterprise. We don't want to run hundreds of projects that lead to complexity and bad overall enterprise designs". Yeah, but okay. So that that's the first step I'd want to do.

R.M.:   19:41
It's good, Thank you, Wolfgang.  So I'm listening to you and I'm thinking so --and correct me if I'm wrong-- but another way to phrase your strategy here would be to say that you don't need IT people to get more business acquainted or business knowledgeable; instead what you're proposing is that business people would acquire some... let's call it "engineering skills" so you would move up some of the skills and knowledge that are currently into IT, move them up into the business so that they can take that in charge and benefit from that.

Wolfgang:   20:20
Maybe it's not not so much about skills. Maybe it's more about accountability. It's not that business people say "okay architecture, IT, it's not our accountability. We're not accountable for bad IT. Our structure is bad  structural decisions".   I think it's a mindset into matter of accountability.  But today they are great business architects out there I know there are, but usually they come from the IT department because they have been trained in architecture, IT architecture, and then they shifted their focus to business architecture. So there are great guys out there. Then of course, they should help the business people to build their business architectures.  It's it's their accountability. It's not the IT guy. It's not the architecture of the business of the business architect, it's the architecture of the CEO if you want.

R.M.:   21:11
I see. So I guess what you're saying is that the CEO should be the architect in chief?

Wolfgang:   21:17
I'm not sure if this --Chris Potts also states this yeah-- I'm not sure if this is right. He makes the big decisions of course, and then, of course, need somebody that facilitates and paints the business architecture diagrams. But if you want, of course, he makes the the big decisions. And whenever he decides (or that the board of directors) when they decide to drop a product or launch a new plan somewhere and then starting new product and service and so on, they make big decisions. Each and every day. And with these decisions, they shape the design of the enterprise. If you want, you can call them enterprise designers, enterprise architects, that I'm not sure. It's a matter of terminology. You will always have somebody that we call architecture facilitator. It's more a guy that communicates with many stakeholders and is responsible --not accountable-- is responsible for drawing the enterprise or the business architectural model. But accountable:  the executives and the business people. So I think that's the important difference between accountability and responsibility.

R.M.:   22:26
And you talked about accountability a few times.  So I guess it is quite important in your mind that there one of the radical thing that needs to happen is that all these things are not "ugly and dirty IT stuff".  It has to be owned and dealt with by the business.

Wolfgang:   22:46
Yep!  I think that's the most important summary. It's a matter of accountability,

R.M.:   22:51
Don't you agree to today, it's hard for them to be accountable for something that they don't really understand, or they cannot appreciate if it if it's good or bad?

Wolfgang:   22:59
Yes but my experience is that when you present a really cool capability map, or maybe if you connect this to finance and if you connected it to customer journeys and the IT applications. So if you have skilled business architect today and you present them a "company on one page" (that's how Tom Graves called it there). If you present them a company in one page and the executives are able to understand it in a second on did use it as a management instrument. If you give this powerful instrument to them, they use it. They love it.   I have had this to two or three times in my career and that that's why I started architectural thinking because it was it was: Wow!   I said, Okay, this is the right map and they were so happy and they started to model and to design based on this map. They started to think architecturally, they behaved like enterprise designers just by providing the right tool in the right granularity with their terms, not not the usual IT architect precision and so... That's amazing what can happen.  And it's not that much effort to build this.  It's not.

R.M.:   24:10
So we're back to the level of detail that you that you talked about. It's not about the fact that they cannot understand or appreciate it. It's because what they've been accustomed to see in the past was much to detailed.

Wolfgang:   24:24
Yeah, and not in their language. What I see quite often is that it's not in their  language. Architects want to be semantically precise. But business people aren't semantically precise. When you're an architect, you think a lot about the proper name and is this semantically and syntactically  brilliant, but that's not the point. The point is to name, the things in the business architecture and use the terms that are most commonly used in the business. That sounds obvious, but doesn't happen in practice. You're done when your map is used by the C-level executives. Then you know "Oh I've used to write words. I've used the right granularity."  That's it.

R.M.:   25:08
Well, that's great, Wolfgang. I'm really happy that you provided all this information. This is awesome. This is really good material. More than I expected. And that's great. Ending words? You have anything else you'd like the audience to be aware of?

Wolfgang:   25:26
I think it will happen, so I'm quite optimistic.  But for me it's a logical consequence, and I can see it.  I may be too much of a visionary, but for me it's obvious that it will go in this direction. It's the only way. So, yeah, I believe in in this architectural thinking vision and I think it's it's a way to get out of this trap and get out of this Valley of Tears, I see in so many companies and so many applications... and complexity... and IT is so expensive... and for me it's the only way to get out of this trap to switch the accountability of architecture from IT to business. 

R.M.:   26:02
Great ending words Wolfgang! Thanks for listening and stay tuned. Or click on the next podcast for more awesome opinions from world experts on radical change in corporate IT.