Colin Garlick on Architecture Design in an Agile World

1. Hi, my name is Ralph Winzinger, I’m a software architect and I’m an editor for InfoQ, and I’m here with Colin Garlick at QCon London 2015 where we are going to talk a little bit about designing architectures. So Colin would you like to introduce yourself to our readers and watchers please.

Yes, I’m a knowledge engineer with software education, I have two main roles there, essentially first one is I look after the systems that we use like the CRM, the website and so forth, and my second role really, my main role is as a consultant and trainer where I train people up in various technical aspects of software development, and sometimes work with customers, helping them to do it.

2. You are training also architects on how to design architecture?

Yes, there is a, especially when it comes to agile too, it’s an interesting one try to do for the Agile in, but anything, the technical side, the architectures are very much on the technical side so I’ve got a number of them working with architects to try and help them to improve the way that they do their architecture, where they go about it.

3. Ok, that’s interesting. So once I heard somebody say architecture is like weather, you can have bad one, you can have good one, but you can’t go without. Is this true?

I believe so. No matter what happens, even if it’s done purely on an ad-hoc basis, you still have some sort of overall structure there, that structure might not be particularly elegant, so might not be particularly edifying, but there is still some sort of overall structure that we have, and whether is a good one or bad one, it still exist.

Ralph: So we have to look out to make the good one I guess.

That’s right, you don’t get it just by working on a wing and a prayer.

4. Where do you think is architecture most important or more important, is it during development of a new system or during maintenance when all the system is already in production and needs to have some new features added in and stuff like that?

It’s important during the development phase because that is where we are trying to create a solution and provide the easiest way to make that solution, the best way, the most effective way and so forth. So I think it’s important during development, but the real power of architecture with the real payoff I guess, is when you come into the maintenance phase, because an ad-hoc architecture is done just without any thought, the system is going to be very difficult to maintain and adapt as we go along. Whereas with architecture we are trying to think about what needs to be adapted in the future, what we need to do to support future changes. So the maintenance side is where we get the value of establishing an architecture in the first place.

5. What is in your opinion a practical approach to designing an architecture. So I have seen a lot of approaches maybe design everything upfront, maybe choosing from different predefined reference architectures which might or might not match the given problem, so what would be your proposal?

I like the idea on an evolving architecture. Various reference architectures can certainly be useful at a higher level, because they give us the overall structure but they are not going to have enough detail, we need to have more detail to them as we go along, and that extra detail is more of the evolving nature of it. To establish a monolithic architecture upfront assumes that we can know everything in advance, and we can’t. I mean we’ve all struggled with situations where we wish we designed something differently, somewhere along the line, simply because as we go along we learn more and more, so an architecture that can evolve and can take advantage of what we learn as we go along, is going to be much better than an architecture where we do it upfront and then handed over and it is set in concrete from that point almost.

6. You were talking about embrace change actually, which is some, one of the principles of agility, and there is another point in architecture which is quite hard to handle I think, because I’m trying to build a structure for a system and on the other hand we have agile methods in place in the organization, so I can’t know about future features and future aspects of the architecture. How do you handle this exactly?

We still want to have an understanding of the big picture upfront there. Without understanding the big picture, even agile methods still are not going to work. So they need to have a basic understanding of the high level goals and everything like that, and then slowly drill it down over a period of time. So that big understanding can allow us first of all to choose from various reference architectures and work out what is the basic structure, and we can flesh out more detail as we go into the various elements of it throughout the lifecycle of the development.

7. But just like with usual business features where you expect things to change and that you might be throwing away parts of your solution, that’s now applied to architecture too? So you might throwing away parts of your architecture?

Yes, nothing lives forever unfortunately, so many people as colleagues mentioned earlier today, so many people try to build the pyramids in their code and in their designs. We need to face the fact that despite all the work that we put into something, it comes a point where may no longer be capable of meeting our needs, and at that point we have an option: do we keep slapping band-aids on it and essentially the solution degrades quite rapidly over time at that point, or do we just throw it away and start from scratch again. And we need to be prepared to throw things away, we don’t like to because all of the effort that we put into it, but sometimes that is the only practical approach. Martin Fowler calls this a sacrificial architecture and we need to recognize that as I said before, nothing will last forever.

I guess it’s no problem to recognize this on the technical side, but I think business people don’t like the idea of throwing away that stuff.

No, it’s a difficult job to persuade them of the need or justification to put more funding into redevelop, something they already have, isn’t it? The key to that one I think is one of the various roles of an architect is to monitor the state of the existing systems, because if we can monitor them and get an understanding of what the typical cost of making a change to the system is, over time we will typically see that cost rise, and when it starts the cost as rising significantly, we can then present that to the business with, they gives us the factual basis, to have a conversation with the business about how long they prepare to put more and more money into maintaining and slapping band-aids onto the existing system as apposed to throwing it out. So it’s a manner of monitoring the cost of change, the risk, the number of failures and various things like that.

8. Let’s assume we have our idea and maybe first design of our architecture, how do we communicate this architecture, it’s useless if it’s just in our minds we have to put it in an organization, we have to put it into the development teams, how do we do that?

Using models and documentation is the obvious answer, the danger to that is I don’t like relying on that because anything that is written down can and almost certainly will be misinterpreted somewhere along the line. I would much rather, I probably certainly do that but I would also like to involve the development team in the creation of the architecture as well, walk them through from time to time, get their suggestions, get their comments, their feedback and so forth, because if they have some degree of involvement, they have a greater understanding straight away and I don’t need to do so much in the same way of laying out the ground work to provide the base understanding for them because they should already then have that.

Ralph: And I guess it’s also easier to keep track of the results actually because architecture governance is another point, how can I guarantee that whatever was the vision, is reflected by the system.

One of the things to that is to focus on persuading the development teams to follow that architecture. That comes back to things like what’s in it for me, things like that. We are going to provide them with a rational justification for why they should follow it, and rational addresses what’s in it for them. We can start using various things like tooling support to monitor some of it, we can do various reviews. I mean one simple example is just pull out the use of version control to see what changes had been made and make sure those changes are satisfying what we need. But those are more acting like a cop type approaches, and I would rather take the approach where we keep that communication between the development team and the architect going. The architect who is standing on their own and not communication with them is most least likely to have that vision followed, so if the communication is kept up and we’re addressing things like what’s in it for me, we are continually talking with the development team about the issues that they face while they try to apply it, and in that way we can get the feedback and we can work with them and give them more reasons as why to follow, we can adapt the architecture on the fly as we are going, where is needed. So communication to me is probably one of the key aspects there.

Ralph: So if the development team knows the goal, where the goal is, then they will make the right little steps towards the goal and we don’t have to monitor those steps.

That’s right, the big picture is all important here, isn’t it?

9. There is sometimes a certain gap with the regard to design capabilities between the architect and the rest of the development team. First of all do you consider that the architect to be part of the team or is it someone who is outside the team and how would you describe a fruitful corporation between the architect and the team?

I can work quite happily with the architects as part of the team or separate. Certainly in larger organizations the architects do tend to be more separate, a separate group that just has a small involvement with the team. In that scenario, then you probably want someone on the team who is more of a representative of the architect for when the architect is not there, so basically I tend to think in terms of a technical lead. So the technical lead is the architect in place and the technical lead should have a very close relationship, communication relationship with the architect. So that would address the one where the architect is not part of the team. If they are part of the team then obviously they are on a full time basis. The skill difference is, to a degree is inevitable because you are not going to make an architect out of someone who’s just fresh out of the university, you want someone who has had the experience and has got the necessary skill set over a period of time, so there is, always is going to be some degree of a skill gap. If that skill gap is too great, then if the architect is part of the team it’s not such a big issue because then they can coach the other team members as he goes along. When they are not part of the team, that is when it becomes more of a problem, so again to me that will come back to a technical lead again, you want someone who has got bit more experience and better understanding and the rest of the team put him in as a technical lead within the team.

10. I can hear from your answer that the architect is someone who knows how development teams are working, who in an ideal world was a developer himself before?

I prefer that style and I’ve seen others who talk about the architecture will come from a different perspective, maybe more from a business perspective or something like that, but giving the nature what they are doing I struggle to see how they can provide the sufficient and necessary advice to the development teams if they haven’t been through that themselves. So I think having a technical background is very much essential from my perspective.

11. Comparing software architecture and software design, in my opinion software architecture is done by the architect and software design is really low level decisions that are made to build a system. Is there a line, is some sort of twilight zone in between, can we differentiate it?

Kind of like a demilitarized zone I guess. I don’t know that I can draw a firm line because to some degree I think that line also varies depending on the situation. If you have a large team, maybe several teams working on the same solution, then that line is potentially going to be a little lower level whereas for a solution provided just by a single team, the line can probably be at a higher level, to more left to the team itself to make the decision. The reason why I talked about lower level for larger teams is because then we have the risk that different people or different groups will do things in different ways across the different aspects of the solution and that makes it difficult to get a coherent approach to a wider solution. So in that scenario I would see the architect as putting more lower level principles to ensure that consistency between teams and individuals.

Ralph: You would lower the degree of freedom for developers the larger the team is, and so you can keep track of the architecture being obeyed

Potentially yes. It’s all to ensure the consistency of the vision and to ensure that it’s still being followed.

12. I’ve seen solutions where actually model driven development was taken as an approach to ensure that architecture is in place just like design because you generate a whole application skeleton and developers only put business logic in predefine slots, is this a way to go?

It is a way to go, I haven’t seen it used that much back home. So I’m a little skeptical myself because I haven’t seen that same wide spread adoption of it at this point, but it can be. Some of it I think will come down to trust, too. If you can trust your team then you often prepare to give them a little more latitude in what they do, whereas model driven architecture is very much a tightly constrained solution and that may be appropriate for distributed teams for example where the architects and the development teams are into totally different countries even, it may be more appropriate there to enforce the integrity of the conceptual vision.

Ralph: So what are actually indicators for an architecture that is successful? How can I look back and look at my system and tell wow we have done great work in designing this architecture, it’s really good now.

Well, first one I think, when you go home at the end of the day without feeling dirty. Some of is that whole issue of a gut feel for it, there are some architectures, some designs and so forth, that just make our skin crawl, and if I can go home at the end of the day and feel good about it, that’s a really good start. But obviously to me I go with architecture looking for the longer vision too. So I guess one of the important ones is does this architecture help me make the necessarily adoptions over time that we need to in easily and cheap fashion. If the architecture is rigid and doesn’t allow me to make those changes, then it’s probably not a good architecture. Likewise if the testing team is struggling to test it, and again to me is probably not a good architecture, so it’s looking at things like those.

Ralph: How do you incorporate modern trends like we hear about microservices, we hear about reactive applications into architecture design, because I guess there can be too much of it, so what’s the point where you say: “Ok, this is some kind of aspect we will include in our architecture”.

Yes, somehow I suppose we’ll come to these reference architectures and things like that, we have the overall vision of what it’s going to be and that might provide support and slots where we can drop in micro-kernels or things like that. There is ultimately any of these new approaches, they are still this code at the end of the day, so the architecture is just a case of working out where do we want to allow things like micro-kernel to fit in, where do we want to slot a service over here, do we want to support that. If we are going to support things like microservices and we need some sort of broker to locate the services, how we are going to handle that, it’s all just matter of designing those into that bigger picture.

13. In your talk you made a statement that architecture is not done for ourselves but for our stake holders, and sometimes it’s like when you look at the requirements, you can maybe even cheaper fulfill them with buying more CPU’s, more memory, whatever, than with designing sophisticated and scalable architecture. So what’s the way to go then?

Again comes back to what the customer really wants from it, isn’t it? If what we are talking about is something that’s got a limited degree of growth or a limited lifetime, then buy an extra RAM or such like, maybe a valid option. The danger with that of course is that for example I’ve work on systems, I’ve developed a system for one company to communicate with the AS 400 and this was supposed to have a lifetime of 2 years because they were already under process planning a replacement for the AS 400. Ten years later it was still there. So simply buying more capability like that works up to a point, but it doesn’t recognize the fact that these systems that we create typically have a longer lifetime than we ever really want to admit, and as a result if we got a very good idea that is going to have this short lifetime that’s fine. If we can’t be sure on that, then we might want to start looking at designing for scaling out.

Ralph: And after all it’s more fun to design a scalable architecture than to buy more CPU.

It is more fun and there where you are on the risk of course of doing something that works better for our decision rather than the stakeholders decision, isn’t it? So really does still need to come back to what the stakeholders decisions are. I think as architects, our responsibility is to present the various cases to the stakeholders and to who is holding the purse strings, and give them the options and the scenarios about what could happen in the future if they don’t replace this existing mainframe or whatever it might be. But at the end of it, it is still their wishes and their requirements that should drive our decisions.

Ralph: I have to thank you for your insight into architecture design. It was very informative and thanks for having the time!

Thank you, it’s been a pleasure to be here!