The evolution of systems architecture design Insights In Depth: Tech Trends 2020

29 July 2020

Technology brings complexity. Sergei Komarov of National Australia Bank joins Deloitte's Scott Buchholz and Saul Caganoff to discuss how architects can help navigate that complexity without losing sight of business goals.

Scott Buchholz: A lot of things are moving to agile and oftentimes it’s tempting in agile to skip the design portion of the step and just get going. And that makes architects that much more important because they’re a little bit of the “think twice and code once.”

Tanya Ott: Measure twice, cut once works on home renovation—why not apply the same concept to building technology?

Tanya: I’m Tanya Ott and this is Insights in Depth. I want [to] give you a scenario.

You run a car rental company. You’ve got 100 cars in your fleet and you decide to add 10 more. This doesn’t really make your operation any more complex. Yes, you’ve got some additional cars to maintain, but those 10 new cars don’t change what you do with the 100 cars you already had. My guest—Sergei Komarov—calls this arithmetic complexity. It’s one plus two plus three plus four. Simple addition.

But, he says, when you’re talking about technology, the equation is geometric and more complicated.

Sergei Komarov: With technology, when you add a new system, it is almost never an island. Let’s say you have a new use case. You want to try something new. You want to add a new feature to the products you’re offering customers and so on. Whatever is the new application that you purchased or system or piece of technology that you decided to integrate, it has to link in with everything that existed before. And if you don’t just count this additional one extra application, but if you count the addition of all the connections between this new application or system and everything that you had before, that number of connections rises very, very quickly.

Tanya: Sergei Komarov is the chief architect for National Australia Bank. And let me just explain that in this context, architect has nothing to do with building design. It’s about the systems and processes of IT, sitting within a larger enterprise.

And to help explain that, we also have Deloitte’s chief technology officer for the Government & Public Services practice, Scott Buchholz.

Scott Buchholz: I lead our research on Tech Trends and get to share [it] with clients and all of you.

And Saul Caganoff is the chief technology officer of platform engineering for Deloitte Australia …

Saul Caganoff: That means, I look after a lot of the technology standards and practices within our business unit.

Saul has spent his career straddling the line between engineering and architecture—which is an important distinction that we’ll talk about in a moment. But first, I asked Saul to explain what exactly an architect does.

Saul: One of the concerns of architecture is the relationship between the parts of a system. A system is made up of people, processes, technologies, software, hardware, et cetera, all interacting, hopefully working in concert and working together to support a business capability. But often they’re working against each other as well. And it’s these relationships, it’s the way that the different parts of the system move together or don’t move together that is part of the concern of architecture, particularly enterprise architecture. When Sergei talks about complex systems, one of the problems with a complex system is that there’s lots of unanticipated consequences of changing that system. So you might make a small change somewhere which has a big ripple effect somewhere else. We often talk about something like the butterfly effect in relation to complex systems. As our enterprise systems become more and more complex because of the demands of customers, the demands of new technologies, the demands of innovation, as our systems become more complex, we need somebody who’s looking after how the pieces fit together and how we react to change and how we can enable change without disruption.

Tanya: Scott, what Saul is talking about, this person who is going to have that sort of 20,000-foot view of not only the technologies, but also the processes in an organization, that can be a pretty contentious concept because sometimes different parties are coming at it from different perspective. Engineers might come at it from a practice perspective and these architects, as we call them, from a more theoretical perspective.

Scott: The word “architect” we sometimes use like we use the word “apple,” and apple refers to everything from a crab apple to an empire or a pink lady or other varieties that we eat. And what we’re really talking about and focusing on in our article is what some people call solution architects: The individuals who are charged with figuring out the hard problems and being more hands-on in the technology.

What winds up happening is when you get a whole bunch of smart people together, you always have a difference of opinion. Part of the job of the architects is to figure out how you navigate, on one level, what’s probably a more long-term perspective that the architects are asked to take, a more enterprise perspective that they’re asked to take, and the need to get it done quickly, which is often the view that the engineers and developers are asked to take. That tension is actually healthy because, managed well, it leads to better solutions. Like many things, though, tension managed poorly leads to not better solutions.

Tanya: It sounds like it’s maybe a little bit of governance versus hands-on work? Am I encapsulating that properly?

Scott: A really good solution architect is going to be the person who has either [the] enviable or [the] unenviable job, depending on your view of the world, of having to reconcile all parties, and chart the path forward for everybody. I actually think it’s the best job you can have, because what it means is that you are knee-deep in all the complexity, sorting through everything from the business process and policies and change impact and organizational change management to technology decisions and downstream impacts. For those who find that level of complexity and that many different things [difficult] to manage at the same time, it can feel a little bit more daunting. But, you know, those of us who love it think that’s where the best part of the job is.

Tanya: Saul, I wanted to ask you where the architect in general comes into this conversation. Are they there from the beginning of any technology conversation or do they come in toward the end as a gatekeeper on decision-making? How does that work?

Saul: It varies by role and it varies by organization. But traditionally, architecture has often been a role that defines rules and defines practices, but doesn’t necessarily come into the picture until the end of the process and says, just before you go live, did you follow all the rules? And quite often that’s too late. Architecture is changing to become more of an enabling capability and something where they engage with engineers earlier in the process—so not only, “Here [are] the rules,” but, “Here [are] some frameworks which will help you align with the rules.” Therefore, it becomes less of a governance function, a checklist when it’s potentially too late, and more of an enabling set of capabilities or tools which come into play right at the beginning of the process and ensures that the engineering effort starts out right and continues on the right path.

Tanya: Sergei, National Australia Bank—NAB—has gone through a restructuring. How do architects fit into that?

Sergei: It was important for us from the beginning to avoid architecture becoming just theoretical. Somebody famously said, “In theory, theory and practice are the same, but in practice, they’re different.” It is very dangerous for architects to become theoretical in the sense that they’re not close enough to solving actual business problems, actual engineering problems, if it just becomes a discipline founded on book knowledge rather than practical experience or a good blend of book knowledge with practical experience. And so at NAB, what we wanted to do is to improve architects’ ability to build up depth of expertise. If you’re a solution architect for one problem today and a completely different problem tomorrow, it’s often very difficult for that person to build up depth in specific areas, which is very much needed in order to solve problems, not superficially, but with real insight. So we restructured architecture to enable a more optimal division of labor, where we have business architecture, which is facing into core business units of the bank and understands everything about their business strategy, about the fundamental constraints and tensions where degrees of freedom are required, where the business needs to be able to experiment of lower cost, etc. So this is the first area. And these business architects help shape demands on technology in a sense, because oftentimes the way you ask questions, the way you pose the problems, has a profound impact on how solutions are shaped. The job of business architects is to understand the businesses that they are durably attached to, on one hand, and on the other understand the technology landscape and its intended evolution and strategy and make the two meet in the optimal point.

Then we have the service architects, which are basically responsible for all the systems that comprise the bank services. They’re called services because they provide common enterprise capabilities such as document management, for example, or fraud detection or security and so on. So service architects’ role is to be responsible for knowing everything there is to know about their particular subset of applications. Then they can come up with very good answers to important questions very, very quickly because they are not new to the problem. They’re not new to those systems. And oftentimes the solution happens in the interplay between the business architects and the systems and service architects. And that also creates very good dynamics, because oftentimes the need from businesses [is] to solve something as quickly and as cheaply as possible. But on the other hand, it’s important not to shortchange yourself and do something that’s cheap this year and then triply expensive the next year or over the lifetime of the solution. That again is a role of architecture, not just to look at how do we optimize for a specific problem to be solved or specific delivery, but how do we optimize for the longer term and for the broader landscape as well. Because it’s easy to optimize for a silo or for a project by shifting risks or challenges elsewhere.

Tanya: Scott, you have got the big view of this. As we see the role of architecture evolving, what sort of cultural changes do you either see or anticipate seeing within organizations as a result of it?

Scott: What we’re actually seeing is a lot of IT organizations rethinking their internal operational model when it comes to architects. As Saul and Sergei have been talking about and alluding to, in many organizations the architecture team is a group of very experienced, very highly capable technologists who’ve been asked to oversee the portfolio and sometimes say no to things, as opposed to helping people figure out how to get from here to there. What we’re increasingly seeing is organizations like NAB and others saying, how do we take this opportunity to rethink the way we’ve deployed people and take the architects out of their governance functions and put them into more individual delivery functions? How do we make them responsible for solutions? How do we make them more responsible for the decisions and tradeoffs that we’ve been talking about?

And then, because when they were in a group, there was a sense of community and team and structure, how do we recreate that through other mechanisms as we go forward so that we don’t lose the value that we had by having everybody together but, conversely, we can benefit from all their experience in a different and differentiated way.

Tanya: So let’s talk about what’s driving all this. You’ve all alluded to the business imperative and how complex things are. But one of the other things driving this is startup culture and the ability of startups to move quickly and innovate in a way that sometimes larger organizations that are tied down by legacy technology are challenged to do. Is that a fair analysis?

Scott: I’d say so. A lot of times what we’re seeing is, to your point, Tanya, new organizations, startups are coming into existing industries like financial services unencumbered by years of investments and mainframes and mergers and acquisitions and all sorts of complexity. They can rethink the way they do things in a way that is fundamentally more nimble, agile and has far less burden and history wrapped behind it, which makes them much more able to respond to changes in the market in the moment.

In order for older organizations and larger organizations to keep pace and to meet the digital natives where they are, we’re increasingly seeing the importance of modern technology, infrastructure, and design and that leads to the need to have more of these solution architects and individuals who can help those same organizations navigate their way from the technologies of yesterday to the technologies of tomorrow.

Saul: There’s a model out there—it’s autonomy versus alignment. So as we’ve had the startup culture and startups who have come into the marketplace, they can move fast and they can change things and they innovate their products and the way they deliver their services more rapidly than the incumbents have been able to. A lot of the focus has therefore been around agile methods, lean manufacturing principles, and some of these methods have come into software engineering. These are now mainstream. Just about every major enterprise I work with is doing agile methodologies in some form. Agile really emphasizes autonomy of teams. You give a team the tools and the permission to achieve the outcome that they need to stand up a new system or provide a service or a new product. And autonomy, it’s a really great enabler for rapid delivery of new services. However, autonomy by itself is not sufficient. You need to ensure that all of the different teams within your organization are moving in a common direction, moving toward some general aligned purpose. That’s where the alignment comes into the picture. Autonomy by itself means I can have lots of agile teams moving in different directions, but if they’re all working against each other, then they may not be making progress for the overall organization. If I bring alignment in, I can make sure that the progress that each team is making is toward a common purpose. And we can overshoot too much. We can have too much alignment and not enough autonomy. And that’s where you get in some very heavily regulated environments, etc., where engineers don’t have autonomy. They face constraints in their ability to deliver. So it’s all about getting that balance between autonomy and alignment. The lean and agile methods really focus on autonomy. Architecture is what you need to bring in to get that alignment between the outputs of the different teams.

Tanya: Sergei. NAB’s Architecture Lab. What is it? How does it work? What do you guys do there?

Sergei: It’s something that we set up from the very beginning. It’s basically [an] area of safe and therefore unfettered experimentation.

So the lab is in the cloud, of course. And this is where we can try out new technologies quite safely, as I said, because we never put any customer data there. It’s almost like a startup where everything is new. You can try things quickly and easily. But that also puts the onus on architects to be more hands-on, which is very helpful because if an architect brings a document to engineers, then that’s just another document. It could be seen as theoretical, but if they bring proof of architecture, proof of concept implemented in code, that actually explains at code level the fundamental pattern that the architect is proposing to implement. It’s [a] much more substantive way of communicating between architecture and engineering implementation. And also, it puts the onus on architects not to theorize something that later may turn out to be impractical. If they can’t actually make it happen in the lab, then how could the engineering teams with all the pressures of delivery and all the additional complexities could hope to implement it?

Saul: If we come back to Sergei’s comment that architecture is about distilled experience, if the technologies you’re working with are changing on a year by year basis almost, you need to be constantly reinventing and revisiting that experience. That’s where a hands-on function for architecture is really vital.

Tanya: I would imagine also being able to test things in this lab can kind of, for lack of a better word, sort of poke a hole in the idea of engineers saying that something can’t work when it really can because they can test it out.

Sergei: Yes, exactly. I would agree. So it’s just [a] much, much better way of discourse on both sides. Again, Tanya, you’re right, it puts onus on both sides because architects going to no longer propose something that turns out later to be impractical, but on the other hand, it’s much harder for engineers to say, well, we don’t want to try this new thing. We have our old ways of doing things; your thing is new and impractical, if you have a prototype that’s been built in the lab and it’s working.

Tanya: Speaking of new, what’s up next, Scott? Where are you expecting this trend to go?

Scott: We’re going to see more and more organizations taking a look at how they’re organized and how they’re structured and increasingly moving to put architects and designers or the individuals who are charting a path to market tomorrow increasingly in charge of services and products. As Saul was pointing out, a lot of things are moving to agile and oftentimes it’s tempting in agile to skip the design portion of the step and just get going. That makes architects that much more important because they’re a little bit of the “think twice and code once” as opposed to just getting going, a little bit like the “measure twice and cut once” adage of old days. What we’re going to see going forward is an increased need for individuals with these levels of sophistication, technical understanding, business understanding, and overall vision. The future for sophisticated individuals who understand the balance between business and technology is very bright. And you can hear it because you hear Sergei and Saul’s descriptions of different cases and different instances of people using architects to figure out novel ways to solve hard problems and finding clever ways like the architecture lab to be able to test out things and kick the tires in ways that we couldn't have done even a decade ago or so.

Tanya: Sergei, Saul, Scott, thank you so much for the conversation today. Really interesting. And we’ll drive, obviously, our listeners to the website to learn more.

Sergei, Saul, Scott: Thank you very much. Really great conversation. We really enjoyed [the] discussions.

Tanya: Sergei Komarov is the chief architect for National Australia Bank. Saul Caganoff is the chief technology officer of platform engineering for Deloitte Australia, and Scott Buchholz is Deloitte’s chief technology officer for the Government & Public Services practice. He also leads the team that produces the Tech Trends report …. and in that report you’ll find case studies and questions you should be asking yourself about architecture and technology as it is today and will be in the future. You can find the full report at

We’re on Twitter at @DeloitteInsight and I’m on Twitter at @tanyaott1.

And this is cool—you can also ask your smart speaker to play the podcast. With Alexa you just say “play or open” and with Google Assistant you can say “talk to.”

It’s just that easy.

And, when you download the Deloitte Insights app you can get all of our podcasts, plus lots of other news and information, right there. Search for “Deloitte Insights” in App Store or Google Play.

I’m Tanya Ott. Thanks for joining us and be well

This podcast is produced by Deloitte. The views and opinions expressed by podcast speakers and guests are solely their own and do not reflect the opinions of Deloitte. This podcast provides general information only and is not intended to constitute advice or services of any kind. For additional information about Deloitte, go to