Join forces with me, Paul Preiss, and the visionary program architect Stefano Bianchini, as we navigate the lesser-known seas of orchestrating monumental transformations within sprawling organizations. Unlock the secrets behind the title of a program architect, a role that's often cloaked in mystery, yet pivotal in steering projects that ripple through every business unit, shouldering immense budgets and expectations. Our dialogue ventures beyond the typical architect's blueprint, drawing from my tenure as a chief architect, and aligns with Stefano's astute observations on how these strategic roles are instrumental in charting the course for enterprise-wide evolution.
As we thread through the labyrinth of specialization in technology architecture, we illuminate the vital role of mediating between the tech gurus and the corporate chiefs. Hear firsthand how to cultivate a deep reservoir of technical wisdom, while mastering the art of shaping intricate tech jargon into narratives that resonate with those who sit at the head of the table. We'll share war stories of battling imposter syndrome and forging a path to become trusted advisors—valued for our ability to influence pivotal executive decisions and advocate technology as a cornerstone of business strategy. Stefano and I examine how the journey of a program architect, although not eternal, leaves indelible marks on the canvas of an organization, intertwining with the expertise of enterprise architects, domain specialists, and beyond.
Join forces with me, Paul Preiss, and the visionary program architect Stefano Bianchini, as we navigate the lesser-known seas of orchestrating monumental transformations within sprawling organizations. Unlock the secrets behind the title of a program architect, a role that's often cloaked in mystery, yet pivotal in steering projects that ripple through every business unit, shouldering immense budgets and expectations. Our dialogue ventures beyond the typical architect's blueprint, drawing from my tenure as a chief architect, and aligns with Stefano's astute observations on how these strategic roles are instrumental in charting the course for enterprise-wide evolution.
As we thread through the labyrinth of specialization in technology architecture, we illuminate the vital role of mediating between the tech gurus and the corporate chiefs. Hear firsthand how to cultivate a deep reservoir of technical wisdom, while mastering the art of shaping intricate tech jargon into narratives that resonate with those who sit at the head of the table. We'll share war stories of battling imposter syndrome and forging a path to become trusted advisors—valued for our ability to influence pivotal executive decisions and advocate technology as a cornerstone of business strategy. Stefano and I examine how the journey of a program architect, although not eternal, leaves indelible marks on the canvas of an organization, intertwining with the expertise of enterprise architects, domain specialists, and beyond.
Hey, this is Paul Price, ceo and founder of ISA. I'm doing my favorite thing here on the argument. I am interviewing a real-life architects who do real work and have real jobs and have to deliver, just like you. The argument is a series of podcasts. It is also hosted by host our chief architect podcast, as well as women in architecture, and we're adding editors and broadcasters to the argument on a regular basis. But I am pleased to be interviewing today Stefano. I'm saying do I get it right? Bianchini? Yes, is it Bianchini? It's Bianchini.
Speaker 2:You said it properly. I'm impressed. Good, I bet you know I was in Italy through.
Speaker 1:COVID? Not that you could tell. The only way you could tell that Italians recognize COVID is that they noticed that there weren't as many tourists. Everybody was out at the beaches, hugging and kissing on the cheek and eating, and I was just like. I love this place. I'm home Now. Stefano is a program architect for Suncore Group. Is that correct?
Speaker 2:Yes, I finished my assignment there.
Speaker 1:Oh, okay, great, Great Well, and has been a recent speaker. If you have not caught the built conference series, this is a free quarterly conference that we've been running for three to four, going on four years now. It has some group, just amazing speakers. Stefano, you presented on surviving and thriving as a program architect and we really appreciate you doing that. So for those of you, there'll be a link in the podcast or a link in the YouTube channel with Stefano's talk. That'll be hosted there as well. But, stefano, what the hell is a program architect? Tell us in your words what's the key here?
Speaker 2:Yeah, I mean the program architect is really the architect that would implement a large program into a large and complex organization. So it's the link between the strategy and the execution of that strategy. And several examples of when you would require a program architect. For example, if you're doing a merger and acquisition integration that you would require a program architect. This is because there are multiple streams of work and you need someone that is overseeing the multiple streams of work and understands all the dependencies between different streams and effectively it's like managing the whole architecture team to deliver against this large transformation program. Other example are ERP implementations, digital transformation or custom experience transformation, where really you're looking at the whole enterprise there.
Speaker 1:Okay, so I'm clear now, because I'm just a dumb software architect sometimes and you know a program to me isexe or a bash file of some kind. So we're not talking about a piece of software, we're talking about a change program. So that's pretty exciting. Now you mentioned really big change programs. We really look at this in the notebook and sort of core concepts, because this is going to be quite confusing for an HR person that has to hire a program architect. Or if you go to a conference and they say well, everybody knows that a program architect is this. So you're talking about a big change agent. Now are there small change agents? Does this apply to a project?
Speaker 2:No, I mean the program. You're talking about budgets that go 80 million plus, so you're not looking at a 5 to 10 million piece of work because you can call that a project architect versus a program architect. So a program architect is really multiple streams of work impacting different business units, for example, or just impacting the whole enterprise and the big budgets large, complex organization and that's when you can justify having a program architect overseeing the whole transmission program.
Speaker 1:So this would include. So one of my bigger projects was about products programs. I guess was a retail point of sale for a major retail firm, 250 to 350 million dollar kind of thing, multiple streams of work and I was the chief architect for that transformation. Is that a what the appropriate level of scope for program?
Speaker 2:What does that do? Absolutely. So. It's like I've seen the chief architect of that program or you know the head of architecture for that program. You end up a team of architects. There is not only application architect, you have security architect, data architect, you have infrastructure architect over pouring into you for the To deliver against a specific, you know, budget as specific scope that is by the enterprise. So it's you're impacting the whole enterprise but you're playing against a specific budget. You have some timelines.
Speaker 1:So I'm gonna throw some terms out sheet out there. Then, for those of our listeners who do use the bit of buck as a kind of a, just to get to my understanding things correctly died right. There is an article in the bit of buck called scope, in context in one of the and it talks about some of these different scoping terms we use and then tie it back to the title. The goal here is never to diminish, always to increase understanding, always. Never to diminish a role or a job or an understanding of ours, of our guests, but to help our listeners kind of understand.
Speaker 1:So in traditional, in that article we look at things like portfolio of work, program work and and project work. In the traditional 3p sort of change management, project management thinking, we also think in terms of product capability, value stream kinds of thinking and I'm curious to in your aid from. From your perspective it is the program in the sense of this is a large enough grouping of projects and streams of work then that they have executive visibility, that it has its own Effectively, it has its own P&L in a way. Right, you're really judging, it's gonna make or break us in some ways.
Speaker 2:Yes, I mean definitely something. It's similar to a portfolio level Because there are a number. Initially, you'll impact in different areas of the enterprise.
Speaker 2:They're all in areas of your, of your sack. Therefore, I think you can compare with a portfolio level delivery, but the the point is that Usually in a portfolio you would have different projects and you have a project accurate for each of those. It might not be the penances, but not part of the same bundle, if you want, in the the program I key, that is, I intended it's more that all these projects are linked by a specific budget and have a specific timelines. Therefore, you need to sequence the work because the penances between different, different streams and you need to achieve a specific date. So a good example again is when you do a merger and acquisition, so you either sever any company or you acquire any company, there are specific dates by which you need to have completed integration and and then becomes, you know, a program, even if it's a portfolio of initiatives.
Speaker 2:They have a Lot of the benefits between each other and you need to have an accurate. It looks at the different, you know verticals, if you want, you know the age of system, the finances and and you know I don't we're gonna do specific, but you know the past systems and middleware and the workplace and all the different bits and pieces that's made up the enterprise, those need to be either replicated across or uplifted, and and that all has to be under the umbrella of a program. And you need, on top of that, a program, accurate, that manages all these dependencies and has. Is it right to keep in contact with my creative perspective for the program?
Speaker 1:You know, this is a really interesting thing that I've long been curious about in a debate that I have, quite realistically, on a regular basis. So, and that is, you know, it's sort of how fly can it? How fly, how high can it cross, fly right. So the question becomes what do we tell so? How many architects would you have on a program of that size? Would you do? You think, if you had, literally, if you had no people constraints, how would you scope that?
Speaker 2:Yeah, yeah. So you will start maybe with five architects just for the initial, you know, business case phase or initial inception phase of the program, but then you will all the way up to maybe 20 or 30 architects, including all the different disciplines. So you the infrastructure, data and, and you know, on top of the application architects you would have cloud architects and that becomes a large team that might have different lines of report but as far as the program is concerned, they all need to report to the program architect, for the benefit of the program in fact. So you have a kind of a?
Speaker 1:have you found there is either a complexity or financial relationship between that number? Because on my on the one of the big programs it took 250 or so level programs I had we had, if you include the primary vendor, the consult, the consultants and the architects at the, at the organization, the retail organization, I mean the grand total was like 70 different architects at different times but a good 40 were there almost all the way through those three years and even then it felt a little tight. You know like I kind of wish we had some junior architects, so to speak, that you know were we could do some of the filing in of the models and the filing in of the documents in some ways. Is that? Does that feel right to you?
Speaker 2:You know, I mean, I always have this number in mind that is, three to 5% of the budget is for architecture and so if it's 200 mil, obviously that means you know, 5%, 200 mil, let's cover enough for the architects as a minimum, right? So that's kind of a guideline always used to see whether there is too much architecture or not enough architecture. Obviously big the VMs, they always have too many architects.
Speaker 1:You know, I'm glad to hear you say that, though I'm so, I'm so relieved to hear you say that, because we always hear this 1% number which is so anemic and so, like you, you floating up there as the program architect, right, and it's like there's nobody there to do the architect. You know like, oh my God, what am I supposed to do? You know I'm supposed to be in 20 meetings a day, but you already have.
Speaker 2:Arquities, but these are application Arquities, they're not that Arquities. Well, what's the difference? You know, there's different skillset. They don't get it because they labelize it Arquities. You know what I mean.
Speaker 1:Well, let's, let's dive into that. Then you said the word skill set. That's such a great word. What does it take to be a great program level, that level of program or change agent program? Architect?
Speaker 2:Yeah. So I think a good analogy always uses that you look at the pilot versus. You know every pilot can drive a car, but everybody can drive a car they can't drive. You know an airplane, you know there can be a pilot right.
Speaker 2:And the big difference is that when you're working on a large program like that, there's a lot of unknowns and you need to be comfortable with not knowing all the details. What you might have on a $8 million program, on a, you know, $100 plus million dollars, you don't have all the details. And it's a new. It's a new world for the organization as well. So you can expect to back and wait for the business to give you requirements because they don't know what their info, they don't even know what requirements they give you. So so you need to be comfortable in working in uncertainty and leading the change without having all the information, which means that sometimes you get it right, sometimes you get it wrong, which means you need to be prepared to.
Speaker 2:You know, step up to the plate, give the direction to the business, but also, at the same time, review that direction is still valid. So along the way, you might find things. You might, the business might have more clarity on what they want to do along the way. And now you have to revisit some of the decisions or maybe things that have been found initially don't work anymore. So you need to go back and look at decisions. So it requires a combination of leadership but, as well as you know, humility, because you also need to be aware that things might have changed and decision have been made six months ago, now not bad anymore. You need to be prepared to relook at those decisions. So how do you program like that? You need to be involved in large information programs and see. You know the complexities of managing a large information program. There's no easy way to get there.
Speaker 1:You know, we would almost talk about that as a kind of when you think about discrete competencies is there. You know, this is where I think the measurable qualities of this get really interesting, because you've really talked about the human dynamic side of this and how strong and difficult that is at that level. Right, the politics, the not letting your ego get in the way, the being able to get rid of cognitive bias, the being willing to what the head of the chief architect forum calls being the sort of chief technical psychologist of the program. Right, tell me your problems.
Speaker 2:Exactly this would be like that and it's all. How do we say? It's about being like Switzerland. You know, you put up the facts. You're not attached to solutions. You just, you know, bring up the facts, no emotions involved, and just make sure that people are well, well what decisions can be made and what are the impacts of those decisions, and just guide them through the change.
Speaker 1:So this is a very powerful discussion because these affect a lot of titles in the world, and a lot of titles affect a lot of how much people make and how they get their bonuses, and then they go to a different employer and it's a completely different world. Now, if you are this person, like you said, you can't know all the details and you might be working with an information architect one day and a business architect the next day and a software architect the next day. What are the? How do you do that? How do you cross these specializations and deal with these deep people, with these deep knowledge areas of something like you know, something difficult like information architecture, and yet you're kind of in between all of those?
Speaker 2:in some way. And then you need to have a combination of all the skillset enough to be able to talk to them and understand what the issue is. And you become like the translator you translate from technical to business language what that means. You dumb it down for execs. So it's about having a good technical background, but it's really sitting down and it's standing with the architect what the real issue is, because you cannot tend to go on and on forever. You're going to have to deal down, yeah, but what is the business impact of this? Is this really going to be a problem If I have to explain to an exec what options are going to put forward?
Speaker 2:And you always wanted three options. You know what is the do nothing. That's a strategic. We had all the money in the world. And what is the pragmatic option that would get us over the line? And having those conversations with you know technical people, you need to have that capability of extracting the information that you need. So once you're playing it back to the business or playing back to senior executive, kind of nail it down and really condensed passion that they can understand and digest it. So it's a complex skill if you want, and you know just like architecture is like a black magic. You know what I?
Speaker 1:mean, yeah Well, you know we're hoping to take that magic away and turn it into more of a science, but you know, let's see where we go. I always figure, if they can teach people to save lives in an ER, they can teach people to be a freaking architect, you know. Like come on. So here's a question I have for you. Then how do you avoid that imposter syndrome, that imposter feeling? How do you avoid losing your depth over time while maintaining that scope level?
Speaker 2:Well, I mean, obviously you know the college changes all the time. There's no way you can get up to speed all the time, so you need to be letting go of a bit of the detail and rely on the people. So really gets down to less technique of skills but more human skills in terms of communication skills and understand talking. Sitting down with the you know the technical person, admit that you don't know anything and you're really dumb and you want to understand what is going on in an easy way. You can, you know, play back to the business. So you have to be a little bit of you know humility and when you approach them that way, you're not trying to show that you are more powerful because you have a title or you know more things. Then they kind of open up and try to give you you know the essence of what the issue is, versus trying to you know, cover you with some terms of taking yourself that you don't understand.
Speaker 1:Well, I always found, I always found that if I brag about my architects, my other architects, they're more than they do, that, in fact, sometimes they're just, you know it's like. Now I want to just talk about how, you know, bradley Cooper did this data architecture. It's absolutely brilliant it's, you know, it really hits on all the key elements of our you know, our relational data, our non-relational data. We've got unstructured data in there. We've been able to use Metabubble, you know, and really really play up that person that you're almost like a megaphone for their excellence, right in a way, which then, of course, like you talked about already, humility, but at the same time and this, I think, is a struggle, I know it's a struggle for me on a regular basis which is, as you get a certain amount of you know away from the technology, I am still convinced that there is a certain point you stop being an architect anymore because you can't hold your own in a regular level solution, a regular level architect engagement anymore, and so you're not credible.
Speaker 1:There's a certain amount of time that a I don't know an accountant stops being an accountant or a doctor stops being a doctor, right, where they're just not a doctor anymore and you don't want them to operate on you, right? So what do you think about that? How do you navigate that channel? Do you just get enough by osmosis, is it?
Speaker 2:I think once you've seen a lot of, you know at the end of the day there's always going to be new technology around the corner. Yeah, that's the thing. But I think once you've seen a lot of new technologies coming through, at the end of the day the options are always the same. It might be one technology versus another technology, but at the end of the day you know the complexity of putting in a new technology versus using existing one. When you want to boil it down to a senior exec, that's more than enough, I mean.
Speaker 1:All right, do you get challenged in, though? Because a lot of what you said was this is about decisions. There are some really important decisions and, quite frankly, some of them are so nuanced technically that you really don't want an idiot making them. I mean, there's decisions about airplane aerodynamics that I don't want an executive of Boeing to make.
Speaker 2:There's different levels of decision.
Speaker 1:If you're talking about this, I didn't mean to use Boeing there. Oops, sorry guys, anyway, so I'm sorry.
Speaker 2:What level of decision we're talking about? Obviously the low level detail. You want to really work with the designers or the engineering teams to make those kind of decisions. You need to involve an anxiety for that. But what I'm talking about at this moment the program level stuff is that when you are impacting multiple streams of work, then the decisions are that level where you might want to go tactical on some solutions versus going more strategic. It really gets down the day how much money versus how much risk you're willing to cope with. There's technical decisions behind that, but this is more like direction kind of decision where the senior executive needs to lead the way in terms of where he wants to go.
Speaker 2:I'm not talking about low level decisions where obviously you wouldn't get a senior executive. Even sometimes they kind of want to do that. Unfortunately, when they do that, then it's like six weeks of running around trying to turn that around, because they kind of make up the mind that that's the way to go and because they've done it before or someone on the airplane told them that that's the way to do it, and then now you slowly have to go around and try to combine, get his people on board with this. Maybe not the right way of doing it and slowly get these people to talk to, to the person. So they slowly maybe they also a bit of ego, because they said that in a big forum from other executives and now, slowly, you have to go back. It can not look bad. They change the decision but slowly influence the facts in a way that now turns out that maybe there's a better option as opposed to what they initially thought.
Speaker 1:Well, so let's talk then about that. How did you get, how did you first start building that credibility with sort of the non-technical audience, with your business stakeholders, with executives, etc. How did you start to generate, develop those skills and develop that part of your career?
Speaker 2:Well, obviously it's a lot about sitting down with them, understanding where they're coming from and understanding the business. Obviously, you need to be credible in understanding the business. If you speak the language, you're not credible. On the other hand, it's also showing that you are there to effectively representing technology to help them. You're not there to try to build your toys.
Speaker 2:Sometimes they look at you as here you go, they're coming with their shiny toys and want to implement all this little technology because they want to play with it.
Speaker 2:So it's really having the business acumen and showing that you are effectively a business executive on technology side and you're representing technology and you're at that level.
Speaker 2:So they understand that if they want to follow what you're saying, then there could be some help with the enterprise. You're making good for the enterprise. But if there are some business drivers that at that point in time lead you other way, which is usually less cost effective but more tactical solutions, then you really need to sit down and have all these risks that they need to be aware of and make sure that the people that are going to wear the risk are also involved in that decision so you don't come across as the techie coming in with the technologies and want to implement their tools. So it takes a little bit of time. You need to pick your battles because obviously sometimes you have to let go some things to build that report. But then that allows you to have the conversation and build up that report when there's actually stuff on high stakes, on some decisions where you really don't want to let them go.
Speaker 1:So what you're saying then is you dive into their language, you understand what they value, you then learn to communicate what impacts on those value elements that you have from decisions, technical or non-technical, that are being made as a part of that program, and then you communicate those high level points, giving kind of clear demarcation between options. Correct that's right. Yes, yes, great point. Okay, how much of that does it take before they just start believing you? If I don't want to know, just tell me what to do.
Speaker 2:They never believe you because they always see you as an accurate, so you wouldn't get when they start julking about you being an accurate, you're doing something right.
Speaker 1:Okay, okay, so it's the British way. As soon as they start making fun of you then they like you.
Speaker 2:Okay, okay, I get it now.
Speaker 1:Okay. So what I mean do you? Where do you see this role emerging in relation to the other roles of architect in kind of like you know, especially as you go from group to group or assignments with Simon or whatnot, you see a lot of different titles out there, at least 100 plus titles. I've seen the numbers as high as 140, something different architect titles out there. How do you navigate that jungle of you know, just with architects much less? How would you describe your roles with the other big, important stakeholders in these programs?
Speaker 2:Yes, so how do I see the program accurate in relation to the other roles?
Speaker 1:Yeah.
Speaker 2:Yeah, how are you seeing this? It's not a BAU role, obviously. It's a temporary role that gets set up as together with the big program that gets allocated big budget. So it's a temporary function. Therefore it needs to interact with all the existing, you know, architecture team that looks after you know, the BAU, if you want. So you need to interact with the enterprise.
Speaker 2:I kid is you need to domain I kid is. Draw from the existing pool of social I kid is, which will be allocated to your program. Draw from the existing pool of infrastructure and data and security I kid is present in the organization and by human you might end up having more I kid is just to fulfill the need, more I kids and more they have working large programs. So they are know how to deal with large programs versus usually be your kids might have done like more BAU projects or maybe smaller projects. So you end up, you know, getting subcontractors on your team.
Speaker 2:But then you obviously need to engage with the enterprise. I kid it because a large piece of work you want to try to do as much as possible of what's on target state and therefore we need to align with the enterprise. I kid is you need to work with business I kid is because there's new processes, they need to be defined and how the business, business operating models that need to be defined, and doing I kid is as well. So this is a temporary role to achieve a specific outcome of a large program and it needs to interact with all the existing you know I kid rules on the organization already and obviously I'm talking about large organization which have a quite a mature I kid should practice in place. Right, it's kind of less pretty much the context.
Speaker 1:Okay, well, you know, these things go fast. I've got 25 or other things I want to talk to you about. Okay, well, I, unfortunately I don't, I can't ask you 24 more things. So I'm going to say let's end this with a quick. What are your top three things that architects should be focused on for the coming 12 months?
Speaker 2:12 months.
Speaker 1:Okay, so I'm not going to say artificial intelligence, oh, please don't, I'm not going to say that I'm going to say how you can take all your experience and somehow make it apply to an artificial intelligence. Yeah, it's an AI system. Okay, we got that one.
Speaker 2:All right, next 12 months, what should be an accurate be looking at? Well, I think it's I. I like the idea to work on the soft skills a lot, so that's a big thing for me and I think that's a good thing for me Because it's an accurate. You're the middle where, if you want to the company, you have to talk with different people. So commission skills is always a good thing that I guess should be messing in.
Speaker 2:That's number one. Number two is understanding more about the business, so develop a business acumen. And the third one is knowing what's happening in the market. And I'm not talking about technology or really talking about the market, reading the news, because that shows that you are on top of what's the environment and the context around you and you really be like really, really with your business execs, instead of just talking about the latest technology, which you know everybody can read. I think you show that you have a business acumen, you're aware what's happening in the market, so you're not asking for a stupid amount of money when you know that the market is not going well, you know. These are things that I would recommend Arquitis to look into in the next 12 months.
Speaker 2:It's the human and what the market is doing Wonderful Well. Thank you so much, stefano.
Speaker 1:No problem at all. My pleasure and for those of you who enjoyed this podcast, you will enjoy a lot more is talk at the build conference. You can find that on the ISO website or as part of our mighty networks, or link to it from the build website. They should be up in the next week or so. So there, so thank you so much. And thank you, guys for the next effort, joining the latest installment of the argument. The next installment will be the kickoff session from the chief architect. The chief architect leaders this will be Grant Eckert and Brian Chambers, I believe in this case will be edit will be publishing their first chief architect broadcast on the argument. So for those of you waiting for the next episode, that one will be uploaded to the next few days. So thank you again, stefano, and we'll catch you next time. Thank you both.