Last week Visma Lietuva hosted a workshop by Professor Rick Kazman. He is one of the first scientists to work on the topic of software architecture and has created several highly influential methods for architectural analysis, including the SAAM (Software Architecture Analysis Method), the ATAM (Architecture Tradeoff Analysis Method) and the Dali architecture reverse engineering tool. Now he is a Professor at the University of Hawaii and a Visiting Scientist at the Software Engineering Institute of Carnegie Mellon University (USA). His primary research interests are software architecture, design and analysis tools, software visualization, and software engineering economics. He is a frequently quoted author of over 100 papers, and co-author of several books, including Software Architecture in Practice, and Evaluating Software Architectures: Methods and Case Studies.
I sat down with the Professor and we chatted about the importance of software architecture, the relationship between it and the Agile Manifesto, the ever-changing world of technology and many other topics. Read on!
What skills, from your perspective, are the most important to become an architect?
To most people the first thing that comes to mind are the technical skills. You should understand the technology, you should be a good programmer, you should have good analytical skills – all of that is true, but the person with the best technical skills might not be the best architect. At least 50% of an architect’s job is not technical. He has to do a lot of sales and marketing. You have to sell your vision of the architecture to the customers, to management and even to your development team. Not only do you have to convince them that this is the right way to do it, but also provide explanations why is it the right way. This is important, because you need people to follow you willingly. Because if you won’t manage to do that, people are going to do whatever they want and you’re going to end up with a mess. You won’t have any kind of conceptual integrity. Architects have to be good negotiators, they have to be able to build consensus, and they have to be good communicators and good listeners. As I said, at least half of the architect job consists of soft skills which none of us were trained for. You might have the absolute best technical person on your team, but if that person doesn’t have great soft skills, you shouldn’t put him in the role of an architect.
What is the most complex part for the architect when building software architecture?
I don’t know if it’s the most complex, but it’s probably the most misunderstood and easily overlooked part. At that is really understanding the quality attribute requirements and priorities of your stakeholders. And that’s why I spent so much time on that in courses, because as technological people we tend to love to jump to the solution. You might build the best solution for the wrong problem, but then your system is a waste, it’s a failure, because you solved a different problem than your stakeholders actually needed you to solve. It’s as we say “doing the wrong thing right”. Again, I don’t know if it’s the hardest part of the job, but it’s especially hard for many people in the technology field, because it’s not what we were trained for, it’s not what we wanted to do when we chose to study computer science or software engineering or other similar studies.
From what I see in the projects, no one clearly defines the quality attributes. For example, the system should be fast. How fast? Is it the main priority? This is usually left for developers to decide.
There is just as much of a risk in over-engineering as in under-engineering. So, if you decided fast means 10 milliseconds response time. And, if in fact, the user couldn’t tell the difference between ten, a hundred or five hundred milliseconds, you wasted a lot of development effort and computational resources that could have gone into improving some other part of the system (for example usability) that the user might have appreciated more. Nothing is for free in software development. If you put an extra effort in one part of the system, it means there is a part where you spent less time building.
What are the main mistakes architects make when building software architecture?
I think that a lot of architects make design decisions out of habit. They may not take a rigorous approach to design or analysis. You know, it’s like: this worked for me in the past, so I’m going to use it again or vice versa: this didn’t come out right in the past, so I’m not going to try it again. I think that when you are doing something as important as architecture design, and you’re doing it in an informal and non-rigorous way – it’s a risk. It’s a risk for your organization, because so much depends on the architecture, so much money is spent fleshing your architecture vision. It shouldn’t just be: “well, I had a dream and now it’s an architecture” or “I like the .NET stack, so that’s my reason for choosing that technology.” I think we make a lot of decisions out of habit or bias.
What is the most complex domain you ever faced when building architecture or doing architectural evaluation?
I think the most complex one was this physics simulations system. It had so many different operating modes, there was so much coupling between the various modes and modules. It had different kinds of simulations, it could do chemical reactions, thermal reactions, it could do it over different time scales, and in addition it could be distributed over multiple processors, or run on a single processor, or run on a supercomputer. It had so many different operational modes that it was really difficult to get my head around and understand what were the drivers and the design primitives in that system. The system had no architectural documentation, they creators didn’t really think about any abstractions for it. Essentially everything was based on functionality and so it was difficult for them to communicate what they were doing and why.
What about the architectural patterns. These days we often hear that we should use domain driven development, microservices, event sourcing and so on. And a lot of projects are using microservices, but is it really the answer to most problems?
Well, like everything else it’s susceptible to being over-hyped. Like every new technology. Ten years ago it was SOA, and now it’s microservices and ten years later it will be something else, but I do see a lot of benefits in microservices in the fact that they are micro. Micro leads you to some good development practices. For example, your services should be small, they should be operationally and evolutionary independent. And for years and years we have always said this about modules in software, but people just didn’t do it. For instance, If you’re not writing microservices and have a standard layered architecture or a monolithic architecture, there is the temptation to let the modules grow big and couple them tightly with one another, which later on limits their growth, makes them harder to evolve. I like microservices, because it kind of forces you to do the right thing, at least on some dimensions.
Are there some particular quality attributes that we should focus more compared to others. Or does it mainly depend on the system and requirements?
It really depends on the system and the requirements. If your system has safety implications or human life implications, for example, you’re doing a patient monitoring system which is going to be placed in a hospital emergency room vs. you’re a game developer or an app developer. Obviously, you have different concerns, both legally and from a business perspective. However, overall I would say that the software development community really do not pay enough attention to modularity and maintainability. It’s really easy to ignore, because you’re so busy implementing features that you don’t have time to think about how your technical debt is growing and how it’s dragging you down. Things like usability and security are more in your face, if it’s bad you’re going to be told it’s bad. And right away. On the other hand, nobody but the development team sees the lack of maintainability. It’s less externally visible and for that reason it’s often neglected.
But if you need to implement a new feature it will cost you a lot of time and that will cost you a lot of money.
I like to refer to it as cancer. You can live for some time while the cancer grows in your body, but eventually it’s going to eat you alive. Fortunately, we have techniques that are like an MRI or a CT scan and can identify these flaws. Still most projects never analyze their code base, never track it, so we’re still living in denial.
Maybe you could mention some of the patterns that you use the most. You mentioned the layering and that each application should have layers. Are there some other patterns architects should consider?
I guess I am a bit reluctant to promote one pattern over another, other than layering, because I think it really is domain or quality attribute dependent. If you’re building a high availability system there is one set of patterns, if it’s a high security system there’s another set of patterns. A performance system should use yet another set of patterns. Other than layering, it seems like many of those patterns are not so universal.
In your opinion, how is software architecture important for companies and developers?
We always say that architecture is important for all the stakeholders of the system, so that includes the users, but also project managers, developers, testers, because that’s what really defines the shape and qualities of the systems. If the system is difficult to use or is really slow it might be really hard to turn that into a usable and faster system without changing its architecture, if that was not thought of in the early design. It’s kind of like if a building was designed to be a warehouse, it’s really difficult to turn it into a shopping mall or a luxury apartment, it’s just not what it was intended for. So those initial design choices that you make really have long lasting consequences.
How did software development change during these years? Can you name any significant changes?
Certainly, the focus on Agile development has been a change and it’s now really the only way that people develop software. Everyone’s doing some form of Agile these days. Other changes might include that people are doing a lot less development from the ground up, everybody’s using commercial or open-source components. Life has gotten better for developers, because there isn’t so much responsibility on you to build everything by yourself. The fact that you’re not building software from the ground up really frees you to focus on the things that differentiate your product from other products rather than spending an enormous amount of time just to get something working.
You mentioned the Agile Manifesto and some engineers who use it think that software architecture is not as important as it used to be. What are your thoughts on this?
So the Agile Manifesto is actually not incompatible with architectural thinking. Most projects are using some form of Agile, many of them are doing architecture activities, and there is no conflict. It means augmenting the Agile methodologies with some additional steps like focusing on quality attributes that Agile methods typically don’t talk about. They talk about user stories, but not the qualities like how fast, how secure and so forth. And it’s not just me, the leaders of the Agile community are writing about how architecture is important. The only part of the Agile methodology that I disagree with is the principle which says that the best architectures emerge from self – organizing teams. That may work for someone or for very small-scale projects, but it does not scale up. I believe and it’s been my experience that you have to do some conscious design work, architecture just doesn’t magically emerge somehow.
What do you think will be the course of software development in the future? How will it change the way that we work now and maybe it will even change people’s lives directly? Do you have a hunch what could be the next big thing?
When you look at the Gartner Hype Cycle for Emerging Technologies, there is always a discussion going on about what will the next big thing be. I think that one of them is Machine Learning. It seems like people are figuring out more and more ways to build ML into systems, so that they adapt better or respond in a more intuitive way, or in a more human like way (note: Amazon Alexa). I think that for many applications it’s going to become a core assumption that your software knows who I am and remembers me, adapts to me, knows my preferences. In the future, that may become no different from setting user preferences in gmail today.
How would this influence the development?
There is a different set of architecture concerns when developing systems for ML. You have to think about where do we get the data set for training or do we carry out the training offline or online, security, privacy. Where do the models get executed, are they on the client servers or on ours. So there will be a whole bunch of engineering challenges that are going to come along with that, but we’ve adopted to engineering challenges for decades, I don’t think they will be insurmountable.
How does software architecture differ in big enterprises and small-scale companies. Does it differ?
I don’t think it is different. I remember hearing a talk by John Zachman, he worked for IBM for many years and he was a software architecture guru. In his talk he was basically saying architecture is architecture in many different ways. By which he meant (I think) that it doesn’t matter whether you’re talking about enterprise architecture or system architecture, or software architecture. That the principles, the concerns are all the same, it’s like fractals, they are scale-free. Even in relatively small systems or small companies you still have the same concerns. How am I going to organize my code base? How’s the system going to run? How’s it going to respond to faults? How am I going to secure it? These kinds of questions don’t go away. It’s not really a matter of scale, it’s really a matter of domains. Maybe something is more important in one domain than in the other. I don’t think they are related to scale.
You’re a professor and I wanted to ask you why do you think knowledge sharing is important? And do think that? You could just be a great software architect and earn tons of money.
There comes a lot of gratification from sharing my knowledge. Our best known book is called Software Architecture in Practice and we really take the in practice part seriously. So, for me just collecting a lot of knowledge and writing papers that only other academics read is not nearly as gratifying as sharing the knowledge and feeling like I am actually influencing this group of 20 odd people who took my class for the last two days. It’s good knowing that at least some of them are going to change their minds and change what they do (hopefully, for the better). And that’s nothing that you can measure in Euros.
To design and develop software architecture methods is not an easy thing to do, how did software architecture caught your interest?
I learned about a course of computational linguistics at Carnegie Mellon University, so I applied and was accepted, and moved to Pittsburgh. Later on, I started working in the Software Engineering Institute (SEI) as a graduate assistant. By the time I completed my PhD I found out that I was more interested in software engineering than in computational linguistics. I finished my degree in computational linguistics, but got a post at the Software Engineering Institute and never looked back.
I have always been fascinated in software design and software analysis, and while I was at SEI I heard the term software architecture for the first time in a lecture by Mary Shaw and this was in the late 1980s. The field was really in its early days at the time: no books, very few papers, but I was captivated by the ideas.
Initially, I was really interested in analysis. Some papers would say: here’s our architecture and it’s better because portability and modifiability, then someone else would write: here’s our architecture and it’s better because of usability or performance. There was never really any way to assess those claims. They were just claims. And this bothered me, it bothered the scientist in me and so, working with Len Bass, we created SAAM. I continued to be interested in architectural analysis, but what happened was that the needs of analysis raised other questions. I would go to analyse a system and I’d say show me your architecture documentation, and people would say: we don’t have any documentation, can you help us document our architecture? Or: can you help us to reverse-engineer the system, cause we don’t even know what we have… From then on, I started developing techniques for reverse-engineering of architectures and documentations of architectures and then eliciting architecture requirements. Eventually, people started saying we don’t even have a design, help us design our architecture. It all started from analysis but led to all of these other related fields.
Thank you for the conversation.