Simone Cicero

Hello everyone and welcome back to the Boundaryless Conversations podcast. On this podcast, we meet with pioneers, thinkers, and doers and we talk about the future of business models, organizations, markets, and society in our rapidly changing world.

 

Today I’m alone on the podcast, but I have a very special guest. We have a friend and instigator of thinking. We had several exchanges in the past months about these topics. We have with us Charles Betz. Charles is VP and Research Director, Enterprise Architecture of Forest and Research. And he talks to a lot of people about how digital organizations operate at scale. Welcome to the podcast, Charles.

 

Charles 

Thank you, Simone. It’s great to be here. Quite honored.

 

Simone Cicero 

Thank you so much. Looking forward. You know, we normally on this podcast, talk a lot about organizations, and products. I must say that we don’t talk a lot about technology, maybe less than one would expect. And so today I’m excited to get into the implications of a lot of the conversations that we have on products tech, sorry, products and org to look into how the technology behind all this is evolving and adapting to the trends we are seeing. 

 

So as a starting point, I think as an icebreaker, I would like you to help us understand better, from your precious observation point, how is this convergence between products, technology, and organizations has happened in the last few years. And what are the big trends that you can describe in this convergence?

 

Charles 

Well, so when I think about the product and I think about entrepreneurship, the first thing I think about is the unbounded imagination, the idea that we are trying to, we come up, we conceive ideas for capabilities, services that might add value to the world. And that will result in us being compensated for that. 

 

And when you have a dream, it’s always the question, how can I execute it? How can I fulfill the dream? It’s a famous, very old, cliched quote from Thomas Edison, that genius is 1% inspiration and 99% perspiration. And the challenge, of course, has been when you have an idea that revolves around computing and information technology. And of course, let’s be clear, that’s the fundamental platform here, that I’m most familiar with. The platform capabilities, the ability for a person to realize their new product idea, have evolved considerably since the earliest days. And this might seem very obvious, but we have the initial precursors of computing, where if you were a business person, and just trying to solve an accounting problem for an insurance company, you were dealing with extremely low-level technical concerns. I mean, you were dealing with adders and registers and, you know, compilers didn’t even exist. But I’m being very specific. I’m talking about the experiences of a person named Edmund Berkeley, who was the founder of the Association for Computing

 

You read some of the initial work he was trying to do for prudential insurance. And you’re like, Oh my gosh, this guy had to go way down the rabbit hole because we didn’t have cloud. We didn’t even have compilers. We didn’t have high-level languages. I mean, you’re dealing with, you know, the digital equivalent of gears and an adding machine and trying to get them to work.

 

And he thought there was value there because that was essentially how it started. You know, people came back from World War II where they’d seen these machines breaking codes and calculating artillery trajectories and are like, you know, there’s probably some value here for business and similar things happen in the UK. Well, we went through, you know, the whole, the whole history. And I don’t want to go into a huge history lesson, mainframe and distributed computing and then cloud, and then I’ve just kind of casually summarized, you know, 60 years.

 

The overall trend has been a continual reduction of the friction. You know, we go from, is it 99% perspiration to 80% perspiration to 60% perspiration. There will always be some perspiration in the Thomas Edison metaphor, but one sees a higher and higher order capability to go from idea to concept. And this is, for example, what shocked people with the Silicon Valley. I still remember cartoons about this. The governing metaphor for creating large systems up until about 1998 and the rise of the internet, the governing metaphor was military and aerospace. And even if you were working in an enterprise or organization, a for-profit setting, you were heavily influenced by the thinking of the systems engineers who had created the first meaning, you know, much of the first meaningful large-scale systems engineering paradigm. And so you dealt with, you know, structured requirements and structured analysis and structured design and analysis was different from design, which is a concept even back then I found myself trying to wrap my head around. And then the internet came and people started realizing, do we need all this overhead and also, Hey, Amazon came. And all of a sudden, you know, computers for the first, I like to say the first 40 years of computing in enterprises, it was putting big file cabinets onto hard disks. 

 

I’m only oversimplifying a little bit, you know, we were putting enormous filing systems and human capabilities. We were moving them from paper to silicon. And that took years just to do that. And then all of a sudden Amazon came along and holy cow, this is not just a back office efficiency play, which is for the most part what the initial driver was, what’s more, efficient to store data on a hard disk than it is to store it in big paper filing cabinets, miles, and miles of them.

 

And then there’s Jeff Bezos with Amazon making money. And there’s Facebook and Google making money with computers. And this changed the whole commercial understanding of what digital technology could do. It also changed the assumptions about how one built digital technology. And people started to realize that the old school military aerospace mil-spec kinds of, you know, require heavy requirements analysis that was not going that was going to help Facebook beat MySpace. They needed a completely different delivery paradigm that was much more attuned to hey I have a thought I want to see that thought realized right now and it still needs to be done reliably with availability and security but we have to solve these things in a new way. So that was a long answer to a short question.

 

Simone Cicero 

And when it comes to projecting this too, I don’t want to say the limit, but let’s say look into where we are today, which feels very advanced already. So these days, does it still make sense to make a difference between business, logic, products, the organization underlying that, and technology?, or these three things are becoming a little bit of overlap, I would say not separable overlap. And therefore, in this case, what is the perspective we should be using? Should we start from the technology? Should we be starting from the product or should we be starting from the organization?

 

Charles 

Um, there are always layers and the layers never go away. Um, the sidewalk outside my house is infrastructure. It will hold a certain amount of weight. And as long as I honor that basic constraint, I can walk dogs and, you know, cats and dogs can walk on it. Squirrels and rabbits can walk on it. People can walk on it. People can ride a bike on it. I can push a cart down it.

 

The sidewalk lends itself to many applications of transportation. We are always gonna have sidewalks. We’re always, I mean, the fundamentals of computation, they realized that they were all, computers were all mathematically equivalent. That was settled by mathematicians in the 40s, right? So computation is a reality. We will always have computing machines and those computing machines, just like electricity, can be applied to a wide variety of use cases, but the use cases do not dictate the fact and the existence of the computing machine. Same thing with information transmission, information, and communication technologies. They are their legitimate domain, and you don’t need them, this is the beauty of it, and yet maybe part of the problem. The beauty of it is that you don’t need a customized computer to run the supply chain that is distinctly different than a computer that would handle payment processing. Same basic logical apparatus, ability to calculate, ability to store data, and the ability to transmit data. And I think that we lose sight of the forest for the trees. We’re the fish in the water, we don’t understand how miraculous the water is. 

 

The fact that you don’t have to go to IBM and buy a different product line for the supply chain as compared to human resource management, as compared to payments processing, it’s the same silicon running the same processing, right? Now this is changing with AI a little bit, but the whole idea of distinguishing hardware from software, maybe I’m just kind of, you know, saying some very, very fundamental things, but I get cautious when people say, well, it should all be business driven not the infrastructure layer. I don’t want to have to go, you know, buy different virtual machines at Amazon to run supply chain versus payments. No, it is all the same. 

 

And Amazon doesn’t need, you know, it’s useful for them to verticalize in terms of their marketing. They should understand the particular needs of their supply chain clients versus the particular needs of their payment processing clients. That’s all legitimate. But at the fundamental level, it’s all one sidewalk.

 

Simone Cicero 

And I’m thinking of trying to give our listeners an idea of when enterprise architecture becomes an important topic. Because, for example, let’s say we have a small company. Small companies tend to not care too much about enterprise architecture, of course, because maybe they only…

 

Charles

No. And we have survey data that shows that. I just, yeah, absolutely.

 

Simone Cicero 

Exactly. And because maybe they have only one product, and essentially the two things are pretty much overlapped. But at some point, companies grow. And this is one of the key topics we are researching at the moment. Our big belief at Boundaryless especially is that in the future or in the present, maybe, you can grow largely by diversifying your portfolio. Because you know, people want variety, technology has been lowering barriers, modularity is on the rise, AI is coming up as the universal duct tape that can put everything together. So in this dynamic that brings one company to empower more, and you know that we are very famously fans of the idea of micro-entrepreneurial units, so pushing a lot of freedom into the product teams that can create their stuff, their architectures. So what’s the meaning of enterprise architecture in a world that is no more bureaucratic, and is much more decentralized? So that’s one question that maybe I feel we should be answering.

 

Charles 

Absolutely. And enterprise architecture is notorious for being solved with bureaucratic mechanisms. So what we have to do is we have to get back to first principles. And I think in some ways, we almost get back to things like the theory of the firm, you know, the whole micro-entrepreneurship.

 

Of course, you’ve had some great economic thinkers on this podcast, people who understand the fundamentals of economics and strategic management. I’ve listened with great interest for years now. So I would say that ultimately, there is no enterprise architecture for the economy, other than maybe the regulatory and market apparatus. The basic architecture is, okay, well, we can exchange payments and then if things go wrong, there’s a legal system. We honor contracts. We have torts, and civil lawsuits if we need to. We have criminal cases, and criminal law if we need it. That’s the architecture of the market. But nobody goes around telling people, well, you should be consistent in how you do X.

 

We also even in the broader market have certain standards. Now, the standards are not necessarily legally enforced, but they take on a certain role that if you want to buy and sell electrical power, you are going to fall, no one’s going to buy or sell your electrical power unless you follow these protocols unless you offer your product in these increments with this voltage, with this wattage, using these particular physical forms to connect it. You know, we see those kinds of dynamics playing out even in a micro-entrepreneurial ecosystem. It can’t be a free-for-all all, right? Now let’s look at a large enterprise.

 

And I’ve dealt with this. I’ve worked at a bank where we had 85 different PNLs. So, you know, micro-enterprise as well. I mean, the PNL is kind of the proto micro-enterprise, right? And there was every, you know, every one of these PNLs had a different attitude and a different stance towards the central services. And it really becomes a question of shared, to some degree, shared governance, and then to another degree, shared service. And so as you look at how digital organizations scale within the boundaries of a firm and the whole theory of the firm, I mean, I read the paper once that basically, you reduce transaction costs by having kind of a 

gated boundary around the firm. Now that doesn’t mean that you know you can’t take an internal capability and start to externalize it, but in general, the theory is, is if we have a set of internal micro-enterprises, but we still have they still have broader boundaries around them, that this is beneficial and that the swarm of micro-enterprises will grow more efficiently and can leverage certain common capabilities. Well, right there, you have the germination of the enterprise architecture demand problem conundrum. And certainly, we want to see things more voluntary and less command and control, but always been attention. I mean, even, you know, 20 years ago, when I first started to see enterprise architecture, it was very obvious to me that enterprise architecture sometimes got its way, and sometimes didn’t. You know, there was always a negotiation, you know. 

 

Now, can enterprise architecture be very bureaucratic and top-down? Yes. And that’s the, in general, that plays out through a process called architecture review. And this is the classic process everybody hates – you have a product and back, you know, we might’ve just called it an application or a project, you know, 15 years ago, because that was the language then. Either way, you’re going to wind up with something running on a persistent basis, adding value. You would have to forward all your designs, you have to answer a 20-page questionnaire and attach pictures graphics boxes, and lines.

 

And the architect would sit there and you might not even see the architect and they would scrutinize your design. They’d come back, they’d ask you for more information. It was always on their timeframe, not yours. If you were in a hurry, too bad. If you had project timelines, too bad. The architect eventually would render their decision top-down from their ivory tower and tell you, you had to go fix these things or maybe even that you couldn’t proceed.And it would just lead to resentment. 

 

And ultimately, in many cases, architecture would get shut down. And, the trouble is, is then architecture would reemerge when the enterprise found itself in trouble. Just, I call this the pendulum, like a grandfather clock. You just watch it go back and forth. We’re, we’re high on architecture. We hate architecture. Oops. We need architecture. We just had a huge security breach or we’ve got too much technical debt or we can’t move people amongst the micro-enterprises. And if we could move people amongst the micro-enterprises more easily, that would be valuable. The micro-enterprises have too big an attack surface. Every micro-enterprise has to go through different security protocols. And ultimately, when you look at the reason that those protocols differ, it’s not adding any value to the overall swarm. There’s no reason for people to use 16 different forms of authentication. There’s no good reason for people to choose their monitoring tools, especially when there are interdependencies between the micro-enterprises and the micro-enterprises providing services to each other. Well, if you’ve got six different monitoring tools that don’t talk to each other, you’re not gonna understand the overall health of your swarm of micro-enterprises. These questions never go away. They always come back.

 

Simone Cicero 

My perception is that first, you spoke about architecture as a mediation layer, some type, some kind of mediation that you spoke about protocols, like basic architectures, language. And we come from decades in the past, let’s say in the last maybe 40 or 30 years, at least architecture as a bureaucratic process that was very technologically centered, right? Instead, what I perceive now is that when you explain that architecture is becoming the language for the organization to collaborate, let’s say, it resonates a lot with the work that we are doing and a lot of people are doing, for example, and the listeners on the podcast can listen to, for example, Craig Strong on taxonomies and portfolios, which are essentially ways that the multi-product organization decides intentionally to share a certain way to look at products that makes these products easier to integrate. So for example, we can say we do point solutions, we do bundles in this way, then we have DIY pieces together, and so on. And this is a kind of taxonomy. 

 

Sometimes it’s more vertical, sometimes it’s more horizontal. But it’s a way for people to say, OK, let’s agree on something. Because agreeing, it’s costly, but it has some, let’s say, positive outcomes. 

 

So let’s agree on the minimum thing that will allow everybody to be autonomous and entrepreneurial, but at the same time allow us to have some coherence. Another point that is emerging for me When you bring up topics such as compliance, and security, which are things that, ironically enough, people tend to value a lot as consumers, as customer, and value very little as developers, producers, and inventors, let’s say. When we invent things, we don’t want to care about security, who cares? But then when we consume stuff, we want to be very sure that our data is not leaked or that our transactions go well and don’t crash every second. 

 

So I feel like there is another piece that is coming. So from one side, we have these taxonomy agreements and product descriptions. On the other side, we have what we traditionally identified as coming from the world of DevOps or in general, again, enterprise architecture. So this idea that some services, some platforms, for example, we can create, are at the same time products and technological constraints that we decide to adopt in our organization. So can you maybe talk a little bit about if this is resonating with you?

 

Charles

Absolutely. Yeah, no, this is a core research topic for us at Forrester. I led the Forrester research into product-centric, and then I also led the research into the platform, and then I got promoted to management. And so now 

Julie Mohr, who works for me, is leading our research on platform because I don’t get to do the fun things anymore.

 

Absolutely. I think the pressures that you outlined result in the attention to platform engineering. Now, the interesting thing we’re seeing, and we’re seeing this in large-scale organizations around the world, are trying to move traditional infrastructure and operations into platform thinking. And the challenge is, what does this really mean? And am I actually doing something different?

 

Am I moving in a more entrepreneurial, intrapreneurial direction, or am I just rebranding myself? I’m giving myself a new coat of paint, but I’m still bureaucratic, I’m still command and control, and it still takes too long to get services from me. I have no customer feedback, and I have no sense of my internal customer. And that’s the big challenge because the modern infrastructure organization, the traditional infrastructure organization when challenged with the modern platform thinking, what you find is a large and economically huge part of the corporation that now needs to think in terms of product and has never done so. So there is a staffing gap

 

I think you could almost call it a, well, crisis is probably too strong a word, but there’s a huge opportunity. And if anybody out there is listening to this and they’re a boutique trainer, there’s a need for infrastructure product management to support the new platform engineering trend. A couple of other points on platform engineering. How does it relate to enterprise architecture? We recommend it as absolutely a priority for enterprise architecture groups. And it’s very pragmatic, very easy to understand. Look, you’ve had a 20-page questionnaire that you hit people over the head with, fill out my questions, give me, you know, tell me everything you’re doing so I can tell you whether you’re right or wrong. You can take 90% of that questionnaire and put it into the platform. You put it into the continuous delivery toolchain that does the software bill of materials, it does the static analysis, it does the dynamic analysis, it does all the quality assurance with maybe a small residual that you want humans checking. 

 

And then the target of that continuous delivery pipeline is a defined cloud platform that solves for monitoring, security, segmentation, well, that’s, you know, again, that’s gonna be performance and security, backup all of the things that developers hate to talk about and hate to think about, it’s just all there. And then the conversation with the product leads, it goes like this, you say, well, if you wanna go build all your infrastructure, you wanna go source every last component, you wanna source your own compute, your network, your security, you wanna source your architecture engineering at the infrastructure level, you’re fine, you’re free to go do that.

 

Because we’re an entrepreneurial organization. And you can take six months to do that. And then you’re still gonna be subject to at the very least security, you know, overviews because we’re not gonna allow you to deploy it and leak data all over the world. Or you can offer your budget code to the platform team and your developers can be writing code tomorrow on a predefined highly secure stack with all of the infrastructure taken care of. And at that point, if you have good entrepreneurial thinkers, they’re gonna be thinking in terms of the commercial challenge that they’re faced with. Six months of delay with an uncertain outcome or start developing code tomorrow, I know which I would choose.

 

Unless of course, I’m developing net new-gen AI capabilities and the platform is not there in which case, yes, I need to go build infrastructure and figure out a whole bunch of lower-level stuff. Um, this might seem very simple, but it has taken Simone it has taken us decades to get here and I still talk to organizations where people say, yeah, you know, people just seem to like to play with toys, you know, they want to go build low-level stuff, you know, they, they just, that’s what they’ve done their whole life.

 

They’re used to doing it and we’re still struggling to get people to buy into the platforms.

 

Simone Cicero

I mean, it’s fascinating because as I was listening to you, I was thinking that all this conversation around the platform organization that we are listening. So for example, I was reading a blog post, an article that came out in October from BCG called “Platforms Why now?” And they were making the case for the platform organization, which is essentially what we’re talking about. So shared services, market prices, and so on. And I feel like it makes no sense to talk about tech and org as two separate things. OK?

 

If you think about what’s happening in tech now, everything is an API, everything is pluggable, you can compose things, and so on. And if we kind of think about what Bezos did like 15 years ago, maybe less, I think it was early 2010, something like that, or maybe earlier, when he said when we enforced the API mandate.

 

And he said, teams can interact with each other only through APIs, or more generally, service-oriented architecture, let’s say. He was saying, our company, our organization, is technology. We are a technology organization. And so suddenly, and fascinating as well, when you transform a social interface into a technological interface you overcome the limitation of your company. So everything starts to be, it starts to make less sense to consider who you can collaborate with only inside your organization. You start to be OK. If there is an interface here, the interface is secure. I can collaborate with anyone. And therefore, my reflection that I want to bring back to you is this. 

 

First, I was thinking, OK, in this situation,

 

Okay, aren’t big players disadvantaged? Okay, why? Because of course, you know, if everything is modular, you tend to think that being a big company, slows you down. You know, so it’s very problematic to do 10 different modules as an organization, as a large organization versus the nimbleness and capability of a small team to create a modular product and bring it to the market. But suddenly, as you were talking, I was making this connection and said, but maybe if instead of having to take care of security, scalability, and a few other elements when I create a product as a small team, which is going to drain a lot of my energy and money and so on, maybe at the end of the day, a big company that succeeds to create this enabling infrastructure, enabling architecture can generate much faster innovations because the teams can innovate at a product level without having to take care of security, compliance, scalability and so on. Does it make sense?

 

Charles

Yeah, no. And I think that you know, the challenge then for the startups is how to quickly assemble that infrastructure out of readily available components. The advantage, I mean, you still, there’s, there’s still, you know, smaller organizations, you know, most of the components that I’m mentioning are readily available by the large cloud providers. The challenge that the small players run into is you have, as you say if you start to expand by differentiating. 

 

You create your first product and there was a certain thought process and you had lead engineers and they went and they selected, you know, certain Amazon products and they stitched it all together into a secure and compliant and available and deliverable product, you know, that was big, they could operate and gain value from, and so they say, okay, it’s time for product number two. 

 

Their thought process is still that I need to wire together a bunch of lower stuff. And I think at that point, you see this divergence. Do they simply charter another team that goes through the same thought process and now you have two technical stacks? Or do they take the first team and they say, okay, take your existing tech stack and build the second thing? And it’s not easy, you know, and it seems, you know, clear that you know, it would be probably more efficient if they took the existing tech stack and built the second thing, but there may be a lot of pragmatic reasons why they find that very difficult, starting with the fact that they’re making money over here and they don’t want to move these people over here. So now you’ve got the second team and they’re like, well, we don’t like Amazon. We like Azure. You know, like the most extreme example, it might be more subtle than that. You know, it might be Kubernetes versus let’s stay on, let’s go out serverless with Lambda or whatever. But you start to see the emergence of variation.

 

And as soon as you start seeing that emergence of variation, especially if it’s not really adding value, and this is where the technologists, they will fight bitterly, they will say, well, my assessment of the business dynamics are that this product needs to have serverless architecture. It needs to run on Lambda. It can’t run on Kubernetes with traditional code. And then you’re in, you know, a world of debate and argument and passion.

 

Um, and then the question is, as well, would it run adequately on Kubernetes? Well, yeah, but it wouldn’t be perfect. It doesn’t meet my complete vision. These are hard questions. I mean, I’m, you know, and this is where architecture I think plays a role, maybe not on the transition from the first product to the second product in the portfolio. I mean, realistically, you’re not going to put in an architecture group, but by the time you start to see these dynamics playing out in terms of a dozen products and 100 products, you’re going to need somebody skilled at facilitating these discussions. And this is where I kind of want to, you know, circle back and say, it’s not about architecture as command and control. It’s about architecture as presenting the bigger picture and facilitating the discussions. And I think that all architects should be skilled in group processes and

 

They should be familiar with the work of, is it the Harvard negotiation prod, the getting to yes people. All of that, that’s just as important as technical skills for the enterprise architect. Because ultimately, and I would find myself in this position many times, I didn’t know what the right answer might be. I was tasked to go sort out some situations. The last thing my manager told me, and this was 15 years ago in banking, let’s get past the caricature.

 

Charles 

I didn’t walk in and say, oh, I know everything, and I’m going to tell you people what to do. That wasn’t going to work. It wasn’t going to work then. It certainly wouldn’t work now. But I was there as the designated facilitator and person whose job it was to kind of be the diplomat and try and get to some alignment and agreement. And that’s the part of architecture that I think is underappreciated, and yet that good architects have always done. You know? And this is another reason why architecture doesn’t go away. You find its scale that you need a cadre or a core of people who can do that kind of thing. And it’s an essential, as you say, a mediation layer. I love that term.

 

Simone Cicero 

Another topic that came to my mind is that if we agree that large enterprises may have an advantage versus smaller players once they create a level playing field that grants their teams full capacity of innovation without having to deal with the implications in terms of security or data management or scalability and so on. 

 

On the other side, I think that you also mentioned that, for example, there is an emerging movement around what people call digital public infrastructures. So not only policymakers are making policy, but they’re also making infrastructure. For example, if you talk about what’s happening in India, when you have infrastructure for commerce, infrastructure for payments, and so on. So I see that as a first threat for large enterprises, like the public players that are moving into building infrastructure. On the other side, you have a threat that is coming directly from the big commodity players, like Amazon and Azure and so on. So I see the possibility that these big players or public players kind of eat the cake of the enterprise and create this secure level playing field. Because for example, that can be the government of India. We had Arvind Gupta on the podcast saying we’re going to take care of data identity and data access, data portability, and compliance and security. So startups, let’s innovate. We’re going to take care of the security of the thing. And again, these are threats for large companies. But at the same time, when you talk about architecture, the architects as facilitators, and mediators. 

 

In the preparatory conversation, you brought up this perspective of systems of systems, and also the necessity for architects to embrace a certain systems thinking approach and be able to kind of put oldest to gold on the same place. I feel like the ultimate value of an architecture will be to communicate to the customer a certain coherence of service and brand so that the customer might choose intentionally to work or to use the services of a certain enterprise versus the market because of a certain legibility of a certain type of narrative or communication or information architecture. So is the work of architects moving away from technology and increasingly moving into customer needs and explaining taxonomizing and ontologies that can facilitate customer engagement.

 

Charles 

Yep. Absolutely. And that’s always been a part of architecture. I mean, in architecture, we use a very, very classic old model called BDAT, B-D-A-T. It stands for Business Data Application and Technology. Some people think that we should move past it. I think it’s still a useful construct. Business architecture does include an analysis of capabilities and value streams.

 

Data architecture is not just physical databases. That’s where it ends. Data architecture, properly understood, starts with the ontology. And the ontology, managing the ontology, managing the enterprise vocabulary, is essential. I remember still when I was at Target Corporation, the famous US retailer.

 

The lead data architect, one of the early conversations with him had to do with a database attribute. And I had used the word price or somebody had suggested the word price. And he said, no. In retail, we have two numbers. We have cost. And then we have the word retail. Cost is what we paid for the razor blade. Retail is what we sell it at. 

 

The word price does not appear anywhere in our data model. That was not a technical discussion. That was an ontology discussion. He was schooling me in the correct ontology of large-scale merchandising retail. So yes, architects to some extent have always played that role. And that conversation happened 25 years ago. I’m getting old. Right? So yes, architecture has always had that ontology, standardization, and stabilization. And this is why it also serves, why it is positioned as a mediating layer. Because you work at the system of systems level. You socialize certain terminologies. A capability map is nothing more than a way to socialize certain terminologies and make sense of a complex ecosystem in terms that everybody at least grudgingly acquiesces to. I’m not going to say that people enthusiastically agree, but typically the capability map is it’s at least a common map that people can start with.

 

Simone Cicero 

It’s fascinating because I was talking to Alex Komoroske a few weeks ago and I said that there’s a lot of excitement in AI and what AI can do, for example, to reduce our need to comply with standards, for example, right?

 

Because being this magic duct tape that can put pieces together, we kind of don’t care anymore about standards. We do our own thing, and the AI would sort out how to connect the stuff. 

 

But at the same time, I feel like in a world that makes things more easily pluggable, there are a lot of adapters you can use, wrappers, no code, AI, whatever. My intuition was that it makes agreements on shared significance and meaning and ontologies, more important instead of less important. More intentionally agreeing may bear fruits. Why I was thinking about that? 

 

Because if you think about first principle, if you think in terms of first principles, you can see how putting effort into something bears fruits, bears results.

 

I don’t want to get too… Maybe this is a bit off track, but if you think about the Diogenes that used to go around in a barrel and kind of put themselves into this kind of funny situation so that it could seem crazy, but at the same time was going around and telling people that they were not men, they were really stupid people. 

 

And also he was doing the crazy man and at the same time was telling people that to some extent, they were not intelligent, right? And I think this is a message that tells you if something gets a cost, it bears a meaning, right? So the cost of agreeing can bear a meaning in the interaction, right? That’s the point that I was trying to make and it was just an intuition. 

 

But then now I talk to you and we surface this idea that basically the success of an architect is about communicating to the customer and clearly articulating the brand message and a product message and an architecture and taxonomy of products. And if I look at your outcome-driven architecture model maybe you can talk about a bit in the coming minutes.

 

It starts from experiences. It doesn’t start from the technology. It starts with the customer and the outcomes that the customers want to achieve. So can you maybe help me connect the work that you have been doing at Forrester on the outcome-driven architectural model with this conversation?

 

Charles 

Yeah, absolutely. So the outcome-driven architecture model is based on the concept of an impact map. It doesn’t have particularly formalized semantics and it was also reflective of Forrester, some broader themes at Forrester, broader research themes at Forrester that enterprises, high-performing enterprises, future-fit enterprises are essentially adaptive, creative and resilient.

 

And this is what leads to customer value, customer, the customer wishing to do business with the enterprise. So what we need is we need mechanisms by which the systems, the products, and the value propositions support these higher-level values of adaptive, creative, and resilient. In more traditional representations, we might position those higher values as revenue, mission outcome, cost, risk, and customer experience. 

 

But to develop those or to support those, we have certain architecture capabilities that operate via influence on products, projects, applications, services, whatever you wanna call them. And we’ve gone round and round on that terminology for ever since I’ve been in the industry. But those Architectural capabilities are very basic. They include the people, who is the architect, the practices, what the architect does, the artifacts, and how the architecture capability reifies its information and insight into artifacts. And then engagement, how does the architecture group actually influence, very specifically? 

 

And architecture groups right now the priority I have with many of my clients is identifying how do you engage because they will talk all day about how they’ve got a bunch of architects doing architecture and creating all these architecture diagrams when I say well what does it mean why do you do these the answers sometimes are not satisfactory so I push people on what is your engagement model? Is it the traditional architecture of you? Where are your command and control? Or are you embedding people? Are you offering people architects to come sit with them? And we have about eight different flavors of engagement that we’ve identified. And then at the very bottom of the model.

 

This is where the impact map paradigm is a little bit turned on its head, because at the bottom of the model, we’re not talking about the low-level activities and concerns, we’re talking about the cultural priorities and the cultural values of the architecture group itself. The architecture group must strongly internalize a burning desire to be valuable, accountable, and agile. And this is also, I think, a really important aspect of next-generation architecture.

 

When I say accountable, I don’t mean that you’re holding other people accountable. I mean that you are holding yourself accountable and you are demonstrating accountability to the enterprise that you have a very clear understanding of your value and what you’re trying to do. You’re doing things like tracking user sentiment, you know, tracking the sentiment of your stakeholders. And again, too many architecture groups in years past, just assumed that they had a mandate to be command and control and they would proceed in that until they angered too many people, and all of a sudden you come in one morning, and architecture is disbanded. And that’s the pattern that we’re trying to get people out of because it’s very wasteful.

 

Simone Cicero

It sounds really like a massive reality check that has arrived in the last five years or so for large organizations. Am I right?

 

Charles

Well, I think that especially when the economy, architecture’s stock goes up and down, but when the economy encounters challenges, people are confronted with the need to rationalize their portfolio to look more systematically at it. And I’ll close by saying at the end of the day, there are three ways to manage a large investment portfolio of technologies. One is command and control. You simply say things like, well, 15% cut across the board, or you have high-level people simply making decisions that appear often high arbitrary, poorly advised, and there are consequences and it doesn’t go well. Another way that we see these play out is it’s not clear who’s making the decisions. There’s a whisper network. But it’s not transparent. The third way to rationalize a large-scale digital portfolio is to use some kind of a transparent, reasonably transparent systematic and rational approach. 

 

And my argument is, is that if you’re doing that, if you’re managing your portfolio systematically and rationally, you’re doing architecture, whether you call it that or not because you are inventorying your assets and your capabilities and your systems and your products. You are looking at redundancy, you’re looking at sprawl, you’re trying to make well-advised investment decisions based on the technical debt and the currency and the user attitudes and the internal demand. I mean, a business within a business, get back to the intrapreneurship, the micro-enterprises, you’re looking at things as essentially you know, entities in the small that are run as small businesses. And to me, that’s where really this world of micro-enterprises and architecture converges, um, in significant ways.

 

Simone Cicero 

It looks like enterprise architecture is embracing a real architectural approach. So something that is based rather than on command and control, which doesn’t sound like architecture at all, into something that is much based on creating constraints so that teams can engage and generate value. Because if you cannot generate value in the world of today,

 

it doesn’t work, it’s no more like 20 years ago or 15 years ago. So I think we are seeing a reckoning of the profession of an architect, which is a kind of convergence of being able to create shared agreements and facilitate shared languages and creating enabling constraints rather than coming from a technological supremacy perspective and saying you have to do this, you have to do that because otherwise there would be too much risk that we don’t want to manage. 

 

Essentially, the world is pushing for a much different approach and it looks like that the architecture community is finally embracing that approach. Interestingly, I think it’s taking a more important role in the organization rather than being more limited.

 

Basically, the transition from a bureaucratic top-down perspective into an enabling value-driven perspective has increased the importance of enterprise architecture rather than decreased it.

 

Charles

One would hope so. And, you know, we’re, we hear various stories from across the industry, but in general, you know, we know that many large organisms, a majority of large organizations continue to invest in the practice and support it. And I think for all the reasons we’ve discussed here today.

 

Simone Cicero 

Charles, it’s been a fantastic conversation. Before we close, would you like to maybe share a couple of break rams with our audience?

 

Charles

Sure. Yeah. So one in particular, there is a man named Dean Meyer who has been writing about intrapreneurship and micro-enterprise philosophy for a long, long time. And his most recent book is kind of the culmination of his journey. It’s called, “How organizations should work” by, I think his full name is N. Dean Meyer.

 

So that’s one I think he might be an interesting fellow for you to talk to. But have a look at his book. But he’s talking about all of these same principles. He talks about how broader enterprise objectives like architecture can and should be funded and supported and are relevant still in an entrepreneurial micro-enterprise world. The other person who I think you might be familiar with is Don Reinertsen who has written just tremendously authoritative and rigorous books on thinking about product management from a lean perspective. Don is one of the most cited individuals in the Agile and DevOps communities, and yet he’s not at all a technologist. His background is actually in mechanical engineering.

 

And also he spent time in the US military. He ran nuclear reactors on submarines, I think. And then he worked for, I believe, McKinsey. He coined the term the fuzzy front end of product development. But when I read so many of the agile leading thinkers, I find that you know, if I read one of their books, I find that they’re citing Don Reinertson. So, you know, and then Don Reinertson, he’s citing like core economic theory, core, you know, distributed, sorry, discrete math theory. He’s, you know, very, very rigorous, but you can understand his work. You know, it’s not that he’s full of his books that have some math in them, but it’s not overwhelming. It’s generally understandable. And I think he’s, yeah, he’s, he has had so much influence that kind of operating behind the scenes.

 

Simone Cicero 

Thank you so much. I think our listeners often appreciated this deep connection with first principles. So I think this book sounds like an interesting book for our audience.

 

Charles

Yeah, and Don, yeah, Don would be an awesome guest on your program. Absolutely.

 

Simone Cicero 

Yes, we will ponder. So thank you so much for the guests’ suggestions as well. I mean, again, Charles, it’s been a pleasure to have you. I think we managed to talk about a few very deep questions about enterprise architecture. And we have been stretching the concept quite a lot. So I’m very happy for the conversation. I hope you also enjoyed it.

 

Charles

Yes. Yeah. Great to have a great talk with you this morning. And thank you again for having me on. I’m honored given some of the folks you’ve had on this podcast. So thank thanks very much.

 

Simone Cicero 

Thank you so much. And I encourage our listeners to follow your work. You always have very great updates on this topic. So for our listeners, don’t forget to head to boundaryless.io/resources/podcast where you can find a Charles interview and you can find a transcript and all the links to the break rounds and other things that the charts mentioned during the conversation.

 

Until we speak again, remember to think Boundaryless.