Exploring Value-Driven Architecture: A Conversation with Charles Betz
May 31, 2024
Iasa Global
Unlock the keys to preventing IT disasters and security breaches with insights from Charles Betts, VP and Principal Analyst at Forrester. Charles shares his expertise on the vital role of architecture in modern enterprises, highlighting the crucial need for informed, strategic decision-making. Discover why more companies are rejuvenating their architecture units and how these roles are pivoting from outdated ivory tower practices to becoming pivotal in driving organizational success. This episode promises to equip you with a deeper understanding of the professionalization of architecture and its growing significance in engaging senior leaders in meaningful business conversations.
We also explore the revolutionary product-centric operating model through the lens of Haier's micro-enterprises. Learn about the balance between internal and external customer focus and the potential pitfalls of a governance-heavy mindset that stifles innovation. Our conversation underscores the indispensable role of architects in shaping organizational design and the practical application of Objectives and Key Results (OKRs) for aligning business outcomes with project deliverables. This engaging discussion is packed with actionable insights that every architect and business leader needs to hear.
Unlock the keys to preventing IT disasters and security breaches with insights from Charles Betts, VP and Principal Analyst at Forrester. Charles shares his expertise on the vital role of architecture in modern enterprises, highlighting the crucial need for informed, strategic decision-making. Discover why more companies are rejuvenating their architecture units and how these roles are pivoting from outdated ivory tower practices to becoming pivotal in driving organizational success. This episode promises to equip you with a deeper understanding of the professionalization of architecture and its growing significance in engaging senior leaders in meaningful business conversations.
We also explore the revolutionary product-centric operating model through the lens of Haier's micro-enterprises. Learn about the balance between internal and external customer focus and the potential pitfalls of a governance-heavy mindset that stifles innovation. Our conversation underscores the indispensable role of architects in shaping organizational design and the practical application of Objectives and Key Results (OKRs) for aligning business outcomes with project deliverables. This engaging discussion is packed with actionable insights that every architect and business leader needs to hear.
Speaker 1:
Hey, this is Paul Price from the ISA. I am here with Charles Betts on the argument and I have known Charles that we're able to have a good argument, so this could be a lot of fun. I also know that we have a lot of areas we agree on and we're going to explore today in terms of value, in terms of real architecture practices, in terms of the work we're doing now. Now Charles is the VP over at Forrester for Enterprise Architecture. Is that correct?
Speaker 2:
VP, principal analyst, so I am an individual contributor but I do lead from that role the architecture practice, including the International EA Awards and also some surveys that we do. That has a lot of questions on the a wonderful.
Speaker 1:
Well, you know and I I have a lot of respect follow you on on online. I know you were heavily involved in it for it, uh, digital practitioner as well. You're an individual contributor and have been around architect in and around architecture for your whole career. So, architecture in and around architecture for your whole career. So, uh, you must see a lot of architecture related to the awards and your um and your uh, your analytics work. So what tell us? Just give us your overview, tell us a little bit of intro of we at? What are the pros, what are the good stuff, what's the challenging stuff right now?
Speaker 2:
yeah, yeah. So let me just start from the top down. Um, I do think that architecture is making a comeback and we have specific data points that indicate that organizations last couple years are more likely to a uh say that they have an architect title and and or b say that they have an organizational unit with the word architecture in its name. And those are the two very, very crisp data points that I focus on when I make assertions about how widespread is architecture and typically most enterprises, it hovers around. Roughly going by memory. Say, 70% will say that they have an architect title in their HR list of roles and about 60% will say that they have an architect title in their HR list of roles and about 60% will say that they have an architecture organization, now a number of it. There's always a percentage we ask every year. About 20% to 25% will say we had such a unit but no longer do, and I watch that. I watch that Because we've seen the architecture pendulum.
Speaker 2:
You know architecture gets spun up with great fanfare and expectations. It proceeds to operate from an ivory tower basis and annoy the heck out of people and not deliver a lot of value, and then, all of a sudden, the organization doesn't have architecture anymore. And then something happens, you know, there's some security breach or the system seemed like it just taking longer and longer to change the systems. Bad things start happening in the IT space and finally somebody says, you know, maybe this wouldn't have happened if we hadn't got rid of architecture. And so then there's a push let's bring it back, but let's bring it back on different terms and let's keep it the heck out of the ivory tower. And this is the conversation I am in practically every week with Forrester clients.
Speaker 1:
Yeah, so you know we share this right. So you know ISA is just trying to professionalize architecture. Right, that means architecture as it's used outside of marine architecture or building architecture and inside of organizations, right? So if I'm a large organization, what value can I get? Group of people, right, I don't care what you put in front of the word. You know you can call yourself fluffy bunny architects, but if I'm a ceo or a stakeholder, I just want to know what do architects freaking do?
Speaker 2:
what, yeah, what is it? So? Um, I, um, I steal whenever I feel like it, and maybe you can tell me who came up with this quote. I thought it was maybe Martin Fowler. It's nothing more than getting the expensive to change decisions, right?
Speaker 1:
That would have originated. Grady uses that one a lot and that's kind of it's hard to change or expensive decisions, right, if it's measured by, and he and I were chatting about this the other day. So I just published a thing called the narratives, right? So we've got these big narratives in our field and I don't like to get it too esoteric. It basically is there's a whole bunch of people out there saying architecture is right now to someone you know, and it's the kind of core of what that is Like.
Speaker 1:
So you and I just joked about the fact that if you've got $10 million to spend on your dream home right, I like this one You're excited to talk to an architect. You're not excited to talk to a building inspector Right, exactly. So what for you then? Because we see this churn and I see this all the time too and how do you get rid of this? How do you get a? What is the value? What is you? What do you?
Speaker 2:
see that resonates and works over time. So, from that basic elevator pitch, which is, if a CIO, a CEO, put me on the spot in the elevator, and said what are you trying to do?
Speaker 2:
That's what I would say basic elevator soundbite. In more detailed conversations that I might have with the CIO say chief of staff or something, I'd say it starts with business school 101. 101. And some of the best mentoring I ever got in my life was when I was at a cocktail reception at a bank I worked at and senior leaders were there. I tried to talk to a senior leader. I was young and experienced. I started talking about technical topics and the senior leader listened politely for about 30 seconds and walked away a mentor, a mentor of mine, and I was an architect.
Speaker 2:
I was a fairly senior architect by title. A mentor of mine observed it and pulled me aside and said look, I'm gonna just give it to you straight top line, bottom line risk. If you can't break your conversation down to one of those three things, don't engage with a person at that level, just don't Advice. I never forgot and I've carried it through into how we approach architecture at Forrester we call it the outcome-driven architecture model, being Forrester and the fact that we coined the term customer obsession, and I also believe in what Peter Director said, that the purpose of a business is to create a customer. I take it to four, so it's in an in a different order risk, cost efficiency, customer or employee experience and then revenue or mission outcome Architecture needs yeah, go ahead, don't keep going.
Speaker 1:
I didn't mean to interrupt you.
Speaker 2:
No, no, no. So architecture needs to be able to articulate its value through line of sight to one or more of those four things, and architecture historically has been really bad at this. You get an architect on the elevator with the chief financial officer who says why the heck am I paying you a big, huge, you know double six, you know six figure salary? And the architect will mutter something about efficiency and alignment or blah, blah, blah.
Speaker 1:
And the cfo doesn't, doesn't, know anything, doesn't doesn't, doesn't, doesn't understand what the architect is saying. Now I am going to introduce and interrupt, sure. Now here's the thing though I agree with that statement to a degree, except I I don't at the actual, the lower level of scope. So historically, we've been really bad at making that argument to a CFO and a CIO who are primarily aligned with risk aversion, cost reduction and big IT spend and procurement. At the solution architect level, we have been very good at making the case because we grew up building things for people like the transformation architect, the one that's in charge of the e-commerce system, right when it was a big deal, or the bank app, or you know the point of sale, or the long tail marketing, or the you know the solution.
Speaker 1:
We're pretty good at that level in creating outcomes. Right, Because the Bitabuck is all based on digital customers, digital business models, digital employees, and then only then digital operations, and then only then digital operations. Like at the solution level, most of our practitioners are able to say, oh no, I'm working on the. You know the AI help desk rollout. So is it that the top-level sales pitch for our value is hard because it's all cost-savings-based and that's not in line with transformation, Because value is created as a part of change, not as a part of cost-savings initiatives.
Speaker 2:
Yeah, I didn't omit mission outcome, mission outcome. So I agree, the order that I gave you was risk, cost efficiency, but then customer and employee experience, and then, finally, revenue models and mission outcomes, and so that covers all of it. And what you're saying, for example, is that the solution architects are often working on delivering systems that are critical to the next generation of mission outcomes, but they're reducing, and the thing is is it's not either or because, to a certain extent, you can say, well, we are ensuring the likelihood of on-time and effective and valuable delivery, not just on time, but also actually valuable, because we know how to marshal, identify and marshal some of our best minds at, you know, on the hard problems as they come up. This is the architecture capability. Um, we also, by having these architects who are seasoned, there is still a legitimate risk reduction conversation because they are going to design these systems consistently. They are going to design these systems with resilience in mind. They are going to use the systems consistently. They are going to design these systems with resilience in mind. They are going to use the correct security design patterns, and so the benefits are not it's not risk at risk, but ignoring.
Speaker 2:
You know business, you know revenue and it's not focusing merely on revenue and ignoring risk and cost efficiency. You know it's across the board, but we don't typically, as as architects, draw that line of sight and let's say it's a different, let's say it's a, let's say it is a portfolio conversation. You know the architect may say use a word like efficiency, and that means that means very little to the senior leaders. You know that. You know they say exactly how and it's like well, look, we have 12 flavors of relational database and we run a technology lifecycle process and we're going to, you know, and through some portfolio work we're going to do right now, we're going to get out of three or four flavors of relational database. This narrows our attack surface and, by the way, recent research is showing that attack surface management is the number one variable in getting better security outcomes Very interesting meta-analysis that was just published last week in Journal of Cybersecurity Research.
Speaker 2:
And so, right there you're saying okay, I'm reducing the attack surface, I am making it easier for you to move people from team to team, your people are gonna be deeper in these chosen technologies and therefore they're going to be more adept at resolving emergent behaviors, you know, aka issues, incidents, because you aren't spread across. You know 15 different flavors of XYZ technology space. You're focused and all of this again boils down to hard to change decisions decisions.
Speaker 1:
So this get this gets at. So I've said, you know, I've said for a long time and I think the bit of Buck is focused on this and that we've and that's just a grouping of interviews and articles by archit, practicing architects. It's not, it's not a religious text, it's just a technique based. But it basically says look, the the vast majority of architects are not trained on on trained on rigorous decision management based on business outcome. Right? Basically, like here's how you make decisions in a business context versus just an engineering context, right? So, moving up the stack of architects, how do you, as you said, create a line of sight to value outcomes and then own the delivery of those, whether they be risk reduction, security management, you know, constraint and or compliance, rigor, or customer outcomes.
Speaker 1:
So a lot of IT people use the word customer and they apply it to an internal stakeholder. So tell me about what you see in what we have to change, about the people who do this work to be able to get what you want done. Right, because I see that mismatch every day. Right, we say architects and then we just include anybody who happens to have the title. We don't actually look at their competencies. So what do you think is needed to change?
Speaker 2:
Well. So one thing I'll add to there is that I don't have any problem with the internal customer uh conversation and in fact I think one of the things that brought the product-centric operating model stuff has given us, um, the end game of the product centric operating model is intrapreneurship and the idea of the business within a business, and some. There are some very interesting modern companies, like Haier, the Chinese appliance manufacturer. Haier is operated as a swarm of 2,000 microenterprises with P&L devolved down to radically low levels, and all of these business units are exchanging services and some of them sell directly into the market and they sell you your washing machine, but others sell services to each other internally.
Speaker 2:
It's a fascinating model. It's gotten a lot of attention. I don't have a lot of trouble with the idea that the customer is internal, the customer is external. Bringing an internal customer focus is actually what a lot of big IT shops need. They tend to be very bureaucratic and you'll get it when you get it, and first come, first serve, and they aren't particularly outcome or customer focused. But the other part of the question, just help me just rewind a little bit here, because I know I went in one particular direction, because I know I went in one particular direction.
Speaker 1:
Yeah, we were talking about. So I keep talking about. We talk about trends and we talk about standards and we talk about methods, but we don't talk about people. Right and effectively, if I take a governance-focused, risk-averse person and mindset and put them in an innovative capacity, it doesn't make them innovative, right? If I tell them you have to be innovative, they're going to try to reduce risk and increase governance, right, because that's innovative to them. So you know what I mean. Like we don't talk about how are we skilling up for this? Because the vast majority of organizations I go into do not reward the behavior that they want to see in their employees, right?
Speaker 2:
No, I mean, it's clearly behaviors. I mean we get into a nature versus nurture discussion here, you know, is the person who is risk averse? Are they risk averse because they're surrounded by controls and processes and incentives to keep them from taking any risks? Or are they inherently risk averse because of, you know, traumatic childhood experiences? I tend to believe that a lot of times in business, you know you get what you're operating, how you're operating, you get the results your operating model is set up to provide. And if you've got, you know, as we used to say, you know in the bank, checkers, checking checkers, and you know people playing gotcha with audits all the time. You know, yeah, you're going to have a lot of risk aversion. So I think you have to and this is something that I think increasingly we do see that architects are getting pulled into operating model issues, even org design. I was told as an architect you keep your fingers out of org designer, they're going to get badly burned. We talk about abstract capabilities, but the org design is too political. We don't want to go there and I still think that there's always going to be some of that with architecture. But I think more broadly, there is more and more architects, especially with the product-centric operating model stuff, there is an appetite and a need for architects to be thinking about.
Speaker 2:
Well, how does this all fit together? Yes, I got an org structure. I have cross-functional processes. I have collaborative overlays like product teams that are matrix overlays. How am I getting results out of this? And, yes, what are my incentives? Am I going to go into an OKR strategy? Am I going to escape the OKRs? What is the relationship between project deliverables versus KPIs, your episodic, initiative-based outcome understandings versus your steady state outcome understandings? All of that becomes, I think, part of a valid part of the conversation and, yeah, it will ultimately impact your people's behaviors.
Speaker 1:
Let me ask you this I don't know if this is on point, but yeah, I had time with us today, but no this is perfect.
Speaker 1:
I was going to ask you one more question and then we'll close it at that and then I'll bring you back and we'll talk about the next topic the next time. But that next question is how do you get value focused? You just brought up OKRs. What are the practical line of sight tools to get to objectives? Risk and customer outcomes? Business model outcomes or digital employee outcomes outcomes? Business model outcomes or digital employee outcomes? What are the techniques that these architects need to learn to be able to achieve what you're suggesting?
Speaker 2:
Okay. So, as always, there's no silver bullet and nothing new under the sun, but there is the OKRs. I think that there is an inadequate understanding of OKRs with many people I talk to, including people who are consulting on them and pretending to be subject matter experts, and it might sound a little arrogant, but what I noticed with OKRs is I read the source materials the Wojcicki book and then the other one, the. In the previous Waterfall model you have the project management office running projects, and projects were not measured by KPIs. Projects were measured by the iron triangle of scope and cost and budget and did you make the deliverables and the metric was yes or no.
Speaker 2:
The metric was at risk and you know green light, you know the typical watermelon dashboard, and then you went.
Speaker 2:
Then things went into an operational mode and it was kpis like mean time to resolve and change fail rate and, uh, you know incidents and all of that. So your classic you know and I'm obviously simplifying and similar dynamics you know in business, um, you know business metrics, but those are kind of vertical specific. Now OKRs if you actually pull apart a number of OKR examples, you will see that they are a combination of both funded transformational initiatives which when you're done, you're done and you don't keep measuring them as measured by steady state results. So, for example, we are going to successfully, we are going to successfully establish a new sales organization in Portugal, and by success we mean that we have um, uh funnel, a funnel with at least, uh, you know, 200 qualified uh leads in it and a XY and a 20 conversion rate. You know between two levels of the funnel and so you have both an initiative. Now, once you successfully move into Portugal, you're not going to measure that next year. You did that last year, right? So your OKR has to change all the point, yeah.
Speaker 2:
But you're still going to track your conversion rate. But now you're going to say, ok, the OKR for next year is to go from 20 sales reps or 20, you know or three channel partners to you know, 30 sales reps or five channel partners. That's my, you know. The OKR for next year in Portugal is to get to that level. And then, yes, in the funnel conversion rate, I'm going to tweak it up to, you know, 25% conversion rate. Um, so that's uh, you still there?
Speaker 1:
Yeah, I'm here.
Speaker 2:
Okay, I just saw you. We lost your video, um, so that is, uh, I think, the uh, um, the one insight that I can offer you on OKRs, and then the idea, of course, is that they cascade, and that is a lot easier, a lot harder than it sounds, I think, to actually think about.
Speaker 1:
Yeah, the balanced scorecard methodology stuff has been really hard. I'll ask you to do a challenge for me for the beginnings of evaluation of OKRs. It doesn't provide the full advanced level that you're talking yet. But that's what I'd like you to see is go send a review of that article and the value methods there to actually improve it so that we can include exactly the reasoning for free and techniques. So we have an OKR card, it's in Miro, it's in Markdown, it's in all those times. But again, all I'm asking is for you to look at that and give us some some feedback on it so that we can improve it, and then we'll come back next time and talk about these techniques. Uh, because what we found is exactly what you've said. I mean, I think we, like you, said, there's nothing new under the sun. We're all learning the same lessons, and that is it is these. Using these techniques and learning how to do it is hard, but if you never start, you never are going to get aligned with these outcomes Is that a fair summary.
Speaker 2:
Yeah, that's fair. I just would close by saying that the thing I like about the OKR approach is that it starts to provide a necessary disciplinary corrective to metrics proliferation. Metrics proliferation because the um, I mean in the bad old days, the kpis you just. You just kept reporting more and more kpis and then, in the real old day, in the real old days, you know, you'd print them out on paper reports and send them to everybody. And nobody looked at these big reams of paper coming out of the report burster.
Speaker 1:
And now I'm really, you know, dating myself there's nothing wrong with being an old, good architect. You know what I mean.
Speaker 2:
And the thing is is when you tie it to an OKR, it's like, no, we're going to measure the KPIs and report on the KPIs that are meaningful to our business strategy this year at this time. But we are not just going to assume and there's a few KPIs that are I call them the boiler pressure KPIs that are I call them the boiler pressure KPIs things like MTTR, you know, and stuff. I mean you can argue about that, but there are a few. I think that probably should always be tracked. But you know, when you see somebody saying, well, we track, you know 50 metrics, you know, across a number of functional departments, and we have for 10 years it's like, oh my God, you know, like, oh my.
Speaker 1:
God, you know, yeah, I agree more, but I love I do love the value basis of the conversation because, you know, one of the things that we've been able to show is that you can relate these decisions even to the most technical decision records. Right, so you know, service integration, microservice patterns, these things will support particular features in your product spaces that then will support particular outcomes. I always use the LinkedIn login example, but there's a million of these features that are then based on technical choices, and if you can't track to that objective, then you can't make that decision and you're going to make it wrong or you're going to flip a coin. Charles, thank you so much for your time today.
Speaker 2:
I know you've got to go to your next appointment. Okay, we'll talk again. I enjoyed this.
Speaker 1:
Thank you so much.
Speaker 2:
Take care.
Speaker 1:
Bye, take care. All right. Well, thank you for joining us again. On the Argument that was Charles Betts, we'll invite him back to talk about objectives and OKRs. You can find us on Spotify and any of the other things, as well as our YouTube channel. I've got a number of different guests coming up in the next few weeks, both in software as solution, as well as in business and information architecture. Make sure to check out our classes at ISA. We teach objectives aligned with solution practices. Make sure to check out our upcoming Build Conference in May. That is all about hype and technology and how to deal with that. Otherwise, I'll see you on the next episode, thanks.