Transcript

Welcome listeners to another episode of Software Engineering Radio. This time we are at the JAOO conference in Denmark, once again, and we are talking to Rebecca Wirfs-Brock today about lessons learned from architecture reviews. So Rebecca welcome to the show.

Thank you, and glad to be here.

Very nice and why don't you introduce yourself, so our listeners know who you are?

Well I am best known for having invented Responsibility Driven Design which as a way of thinking about organizing systems and dividing responsibilities and links to objects, but in my recent travels I have spent a lot of time looking at architectures and sorting those out which is the purpose of what we are going to talk today.

Yeah, so recent travels hints at that you are clearly a traveling consultant?

Yes, exactly, exactly, yeah.

Okay, so the topic today will be architecture reviews; we already had, well, a more conceptual discussion last year at JAOO with Dragos Manolescua. So this year is going to be probably a much more practical view on it, lessons learned, sounds to be practical. So why don't you give us a quick overview of what it's all about then we'll talk about details.

Well from my perspective I have been involved in two ways as one, obviously, as a consultant gone in and tried to review an architecture with teams. I get asked to do that and so I have learned things about how people tell me things and how to really find out what's really going on; and then the other aspect is as a developer, lead designer, presenting material for reviews. So I will get both sides of the coin.

Okay, so let's get started. The first thing that we have in our script on your slide or whatever is a statement that says, "Be aware of the technical stack", what does that suggest? I have an idea, but --

You have an idea; well, in some sense I am thinking of a specific review where I went in and the only thing that was there that the Chief Technical Architect would talk about was the 'technical stack' and the beauty of it and that picture on the slide is of Zen Stones nicely stacked up and arranged and beautiful and there is no substance behind the technical stack. So the technical stack does not make the architecture and I find many times the technical nuances are what intrigues smart architects and they worry about the wrong things.

So and just to get it clear, technical stack you mean I use web logic 'xyz' and then I have a web service communication to the other guy.

And we are using BPEL and, and, and, and horizontal messaging strategy and, "Oh, gees, the real problem was to unify two domain models and we didn't even think about that," or something like that and so it's easy to get, in our field, I think, any smart architect likes to consider the latest technology and the whole stack is beautiful but the solving of the real problem might be uglier.

Yeah, actually I have also -- that is one of my -- the things I always talk about that you should talk also about the conceptual aspects of an architecture is it asynchronous or synchronous, stateless or stateful, these kind of things and not just on real technical tool details.

It's easy to latch on to technical tool details because there are all kinds of things we can dig in to as opposed to the other qualities as well, performance, scalability, usability, and all those things.

The other thing is visualize the benefits. So probably first make people happy of what you have and then start criticizing or what does that mean?

Well in actual fact, I think, if you are trying to present your architecture to someone that we can present them very technical detail descriptions and draw nice pictures but if they don't know what it's going to do for them and why it's going to be a good architecture then we haven't spoken to their heart. I am thinking in particular again putting on a different hat as when I worked on a Telco integration framework and we worked on great models and presented a prototype but the key thing that sold it to the management was visualizing the benefits of the fact is we had this "Don't call us we will call you" architecture with an adapter and so you would have common adapters to common systems that we are trying to integrate and that would really reduce the costs of integration of new systems as we acquiring them. With all our beautiful architecture, if they didn't understand and could visualize why, what we are pushing was important and when they did, they got very excited, so we needed to find a way to communicate the essence that was really going to be the important thing.

If you do a review, how do you find the right people to whom you show what you have and also how do you find the people who are actually good candidates to tell about the architecture? How do you find out which people to get involved?

Well, again, from both perspectives, if you find that you need to have a technical review, obviously, you need technical people involved and it's good to have a different perspective than just people like you.So, if I am integrating a system, it would be nice to have other people that I am integrating with who are experts in that area or the technology and actually I think we are pretty good at finding technical reviewers but what we don't find is that sometimes the product owners and the people who really are going to demand those things of our systems. If we just had them there then they could tell us the right stories that we needed to support.We like to create things and if we over engineer things, because we think they want it, then we can get in trouble.

So maybe another term for this would be stakeholder integration, get all the stakeholders and make sure everybody has a say in the thing.

Stakeholders aren't just, I'd say, product sponsors or someone who are buying it, but they are people who may be in the marketing that are specifying features if we're developing products as well.

So in some sense if you do an architecture review you are kind of the inquisitor. So you go there and you have to make sure you are actually getting to the point and finding the issues, if there are any, so asking the right question is probably a big deal?

Yes and asking the right questions doesn't necessarily -- we are not looking for, is the architecture good, yes or no? I don't think those binary questions are really what we are doing, we are probing for does it meet the real characteristics that we must have.

Assuming they are specified somewhere?

Yeah, If they aren't, then I would say there is a little bit of problem or a little bit of investigation about what the real qualities that we're trying to produce and so that leads you in to, as a reviewer, if someone doesn't ask you or doesn't present everything you need to be prepared to ask those questions, you need to propose and probe and uncover the things that may not be said, wouldn't that be nice if I had all this documentation and I just dived in to a review and it was easy, but it's never that way.

So let's get specific; are there some stereotypes or idioms that you can use to think about what kind of questions to ask?

Well I think that, as a question asker, I always feel like -- there is a old TV show about this detective called Colombo and it's a US TV show and he was this unassuming gentleman, he wore rumpled clothing and he was always, basically, "Well, I don't know but maybe you know, can you tell me?" So in actual fact, I am not making judgments but I might evaluate, "Well, how good do you think this is going to be," that is one kind of thing. "Is that really so?' So reaffirming when someone makes a claim that maybe is outrageous but in another way coming back and saying, "Well is that really the case? I heard you say this, but do you mean that?" "I don't know this but maybe is that really so?" So you could ask accuracy questions or are they complete, "Is that all?" "Gees, that doesn't sound like there is enough there?" So there are s all these kinds of ways of asking questions in a way, I think it's not just asking probing questions, but asking them in a way that gets people to open up and not necessarily -- if I am conducting a review, being so judgmental that I am just trying to get them to open up.

Another technique that I like to use is I reformulate what they just said in my words, maybe draw little diagram and try to understand what they did, say the same thing in my world, and then just see whether that kind of is compatible to make sure I understood it correctly?

Absolutely, and in some sense when I am doing this I have to go in there without -- although I am a threat, I mean, as a consultant; I'm an external source of agitation - why did I get brought in anyway?

You evaluate their work?

Yeah exactly, and so in some sense I need to also validate whatever they are telling me is they are telling me the truth and that I just want to understand and help me clarify my understanding of what you are doing. I think that's a lot of what I do.

Yeah, so you basically try to make them think? You ask questions where you hope that it makes them think of what they just said and what they maybe should have thought about when they built the system and hopefully did.

Yeah there is a subtle art to that I would say, and so why did you do that, that way? What's the purpose of something? Oh I can understand; "Well, did you consider?" So again in a gentle way I can say it rather than a harsh way of and I can have them reveal limitations that way that they may not have been at first willing to talk about or even thought about or I mean were they really aware that, well maybe not; so I bring my context and background into it as well.

So how important is it that you, as a reviewer, actually understand the kind of system they have built be it the domain or maybe some of the architectural technical issues? Do you think every good reviewer can review any kind of architecture or do you need a connection to the stuff they are doing in addition to it being software?

Well that's a good question because in some sense I have been asked to review a variety of different things of which I have had no knowledge of but from my general ancient background of over 20 years of software development and systems I can usually draw some connections. For example an Enterprise Java applications certainly has some common nuts and bolts that I am familiar with, but I think it's fair to say where you are not competent to review, so you don't just want to dive in and Concurrent Real-time Embedded Systems is not my forte, if you will, although I have done technical reviews for that, but I do have some background in that too. So I don't think you want to overextend your knowledge, but if you don't understand the technology then it's somewhat difficult.

Right, my idea, that's my experience too. Although sometimes I think new technologies are just the old stuff with a new name and you can -- I mean SOA is a good example. I mean if you have done distributed systems -- well it's not that big a deal.

It's not that different and if you are talking about message orchestration, yeah well there are other things that we did before. So yeah, but there is new nuances and accumulated technology things but not everything about an architecture is technical for review.

Exactly that's what we talked about before. The next thing that's on our list is, probably to judge how big you organize the review. If you have a two-person project you shouldn't come with a five-person review team, so how do you size the review to the architecture?

It's really a matter of how much they want to know about the architecture and if it's a small change, if you will, I'll say an incremental release or I am just re-implementing the same things on a new hardware platform. So it's not always just the team size but it's the size of the architectural change --

Size of the problem.

-- problem, yes, that they are trying to solve and so I am thinking back to people who want to really get it right may start up and think they need this big formal review cycle, but they have to really consider is this a major architectural significance, is this a new thing or is it just some incremental, so that's one consideration. A review team of one or two people can actually do quite a lot. I wouldn't think that the size of a project is so important as the size of the architectural change and impact - how much scope in what you need to do? Particularly if you are building something that is designed to have a ten-year life cycle or fifteen-year life cycle; being like the Egyptian pyramids - lasting a long time requires more care and review, than otherwise.

If you are building a platform for a product line is a different thing than if you just hack your web application?

Well yes.

Yeah, Another metric that I like to use is also simply how much money would you like to spend? I mean I had cases where they say, we like to have this architecture review done in, well, three days I think, three days should - well we don't have more money, so that also answers the question.

Yes and that's true; they will get what they find in that time frame and so in that case you really have to focus on what are the key values that you want me to explore because I could wallow in the review all over the place, look all over the system.

So how detailed do you expect your, how to say this, reviewee or the thing you review or your customer in that sense, how specifically do you want them to ask you specific questions that you tried to find out? Do just go in there and say well let's review the architecture or how specific are the goals of the architecture itself specified typically?

It actually depends on how experienced they are at doing reviews. I mean some people would like to follow a process, like, something like the ATAM, the SEI; well let's look at the quality scenarios and growth scenarios and oh, Rebecca do come in and help us examine those things and those are rare actually in my experience and most people say, "Well we are doing something that's this size and we know we have some problems or concerns here, so you tell me what your concerns are?" As a consultant I can come in and then probe around and then I may decide that I need another colleague or two to help and then I can counter propose, so much money, well, this is what you will get, but maybe we need to look deeper.

So leveling the playing field, I guess, is crucial. I mean if you have this architecture field intimidated by the review team who comes in and, as I said, one architect five reviewers there is something wrong. So there's also, I guess, this psychological issue?

Well it's really the case and that even within a company let's say not having an outside consultant come in but if I have to go in front of a number of people and present my architectural ideas and it's a big, big threat and maybe there's politics involved and all that kind of stuff and so in actual fact if companies do set aside and get some consistency amongst it, it can make it, so, the expectations aren't that you are going to go in front of the inquisition, if you will, but that it's a set of peers that are helping architects express and do it in a non political way but as a part of review then that can kind of make it less intimidating and more effective for companies.

I think that's maybe also one of the reasons why external reviewers are brought in because they are not involved in politics.

That's a good point but someone politically brought us in; someone brought us in for a reason, someone has some worry or some concern.

Yeah, right.

But we don't have a vested interest in a particular outcome unless we are, let's say, a technologists who works for a product that they are having employed and it's part of their architecture.

In which case you are not a good reviewer I would guess but --

Well that's actually not always the case; when we were at interviewing and getting reviewers for this Telco product that I worked on, we purposefully asked the technologist, one of the external reviewers to be the server product because we were early implementation of this Java server technology and so but we didn't expect them to make all the comments about other things.

Right they were specifically there to help you with their system

Yes.

Yeah, sure. What are rainy-day scenarios?

What happens when things go wrong; one of the things that sometimes people ask you in a review is - let's make sure we understand the limits of our system and what it can really do? We are investing a lot, so can you please help us understand and articulate the limits and the constraints and has our technology addressed it, but I find that sometimes they have a tough time saying what will really happen -- how much do they really want to invest in recovery or performance scalability when life is bad, when the architecture is really strained and pushed to its limits.

Yeah which typically means that several things go wrong at the same time so you have several risks that kind of stack on to each other to really get to the problem like any accident, right?

Absolutely and so it's really kind of interesting when you do have those situations and I am thinking of, again, another Telco system that I worked on. What was really important in that case was articulating the limits, although it would fail over to another computing system. We had to say well too major faults at the same time is where we stopped because there is only so much investment, but until they articulated that, the architects didn't -- I mean they wanted to make it more reliable and they needed to know the boundaries and so expressing their limits to the rainy day or bad things go wrong can really help people do that, but we have trouble stopping and knowing what's enough, either it's too hard, so we don't try to do anything in our architecture recovery or it's we want to do so much that we don't know when to stop.

Yeah, and again it goes back to this requirements thing; well I have not worked much in the Telco area or something, but I think its very hard to make a customer say, well how many nines do you need after the dot, what are you willing, which risks are you willing to take with regards, for example, the uptime so getting precise requirements in order to know where to stop is probably not that trivial also for a reviewer.

I would say for hardware related systems it is easier to get those numbers but then from a software standpoint the software that's influencing that really how many nines you get, then it becomes a matter of, well how much effort can we expend because to get to that next nine is in order of magnitude; but also people don't like to talk about failure and recovery, just in general. We think about requirements in terms of what something should do, not how should it recover and oh but yes it must but they don't like to talk a lot about that. In actual fact, when you are talking about risk compound to one of the other problems that people have is if they don't know exactly the probability of a failure or probability of something happening and you are trying to architect or present options based on a spectrum of options that we must do. They tend to favor things that are known probabilities and latch on to those and discuss those or things where it's not so clear; and that's natural human nature. If something appears to be a better situation then they're gonna -- if we are presenting a range of architectural alternatives something that appears more certain - even though it has less benefit - is easy to select or want to have, than something that's gonna have big benefit, but it's not so certain that we will get that benefit.

And why is that a problem or why is that bad or --?

If I am an architect and I am really proposing something, if I can offer facts, concrete facts, again, flipping around to this point of view. Concrete facts that absolutely demonstrate that this will have 35%, 35.8%, better then it's far better if something is like well I think it will but I am not certain and sometimes with new technology it's very difficult for us to give those numbers and so we give sometimes probabilities and people don't react well if they are trying to choose amongst options for things I think are going to be good, trust me. Sometimes they should question, but sometimes if something seems so certain they'll pick some choice that involves, let's say technology or even software development risk, that isn't going to have a big enough benefit, because it's the easy certain thing to do. And sometimes we have to push for more risky things. But if there's more uncertainty around it then people don't like that. They are going to back away, it's just human nature. So as an architect if I am trying to sell an idea --

That's the point.

Yeah, the more facts I have, the better I am able to compel people.

And facts are either experience reports or maybe matrix, measurable?

Yeah, prototypes, measurable types of things. But if I am having to conjecture a bit that's when I start to be a little bit doubted. And there's a lot of risks that we don't know and a lot of 'precisely why are we doing something'. We know it will be better but we can't quantify things as clearly as we might like to make our argument. And then there is the case if you are talking about people listening to your ideas as an architect. If they perceive that something is not certain - and I have had managers myself, react this way (and you need to test this). Either they totally ignore any risk or they totally are in fear of that risk happening. So they either totally ignore the probability and leap ahead if they want, or they become paralyzed by it. And that's actually a dangerous thing too, the risks of an architecture.

I recently heard a podcast where some scientists said that humans are really bad in working with probability, in general. So maybe that's one of the reasons that they kind of see this number it's closer to zero than a hundred or the other way around and then it kind of flip to this, "Ah, it's going to be bad."

Yes, right, well it depends upon whether there an eternal pessimist or an optimist and depending upon the company, if you will, and the circumstance it maybe is beneficial to be a little bit risk adverse. If you look at certain companies they make their business off of being risk adverse and others, on the other hand, do have to take those risks.

Okay information bias.

When I am presenting information that supports an idea - we've been talking about the reason why people sometimes flip over binaries they become fearful but what the other problem can be that even if I am proposing an architectural idea and giving some credible evidence that it's never enough. We ask for more data. "Oh that was a nice prototype but can you show what's going to happen here?" and they keep asking and asking; because they are not going to commit to our architecture, and so in that case it's a very difficult challenge as an architect to get them over that hurdle and take your new idea. So in some sense you have to try very hard to present facts in new ways and convince people, maybe by even saying well our competitors are doing this.

So we should do something else?

Yeah.

Okay when you are building systems these days, at least in the enterprise world, there is typically always legacy stuff involved. So there is always the existing systems with which you have to merge or integrate or which you have to evolve. So I guess there are some specific risks and also then as a consequence some specific points you should address as a reviewer?

Oh, absolutely and I think actually Eric Evan's Strategic Design, which he is going to be talking about at this conference, is one way to address that; in that if we are merging existing systems perhaps it's not just the technology that we should be concerned about but are there domain models and data that needs to be merged and the platform isn't just one isolated silo that we just bang into another one and in some sense merging existing technologies isn't just the only problem, there is operational risks of how do I get those systems converted and working together and to me, those things can be show stoppers on many reviews and actually if I am just focusing on the new technology then all these other merging of customer needs, platforms, of domain models, data can be a huge problem that people don't recognize the consequence.

Yeah and another thing when you integrate several systems is that you often throw away one of them more or less and people are often reluctant if they have invested a lot of work into it, it's their baby.

Oh it's their baby and in some sense we spent a lot for that baby and we bought that baby from another company and let's say we merged company even and then we must do something with it. Where as in actual fact, it probably would have been better, again, to take the functionality and re-implement it rather than try and bolt systems together; but once I have invested in that technology or that other system I want to try to use it and in some sense I think that executives think that it's less cost to integrate but they don't understand the deep issues.

Yeah, exactly. Another thing that comes to mind is that many people actually like -- well the problem is if you promised the big benefit but it's far away people won't maybe let you actually do it, so you have to do small steps and show small benefits.

So in that case it isn't the case that we want to just throw that away and re-implement it, but we would like to merge the system gradually over time or do things like that. And that takes an understanding of a longer-term set of steps. But if we don't break it down into smaller steps of how to get there and if we - as architects - just say: well here is the end state and it's so far away. That's so much easier for them to just take the low hanging fruit. It is the easy thing they never get to where we need to be really integrated. So as an Architecture Review Consultant, I guess, my job sometimes has been to point out what everyone knows are the problems but they just don't like to talk about so much. And it's not just technology it's how do it I handle technology, how do I merge designs, and how do I really benefit the most out of things?

Okay let's look a little bit about how you describe decisions, because I mean as the reviewee - the one whose architecture is going to be reviewed - you will have to explain why you did things the way you do because that's one of the main points of architecture review, I guess. So what can you say about how do you actually explain ideas and decisions to a reviewer, what do you want to hear?

Well I think it depends on your audience. Are you having someone who is going to give you a constructive set of commentary back and that's what you would like or are you trying to sell something to someone and they say, "Yes, I'll buy it," and those are two different kinds of reviewers. And if I am wanting to have a constructive thought out, thoughtful review I think there is one pattern and if I am trying to sell it I might want to put little slant on it a little bit differently. So, I, as an external reviewer I want to make clear that usually I am not buying or selling I am just getting a judgment and I am reflecting back things that you may reveal to me. So I am going to ask you questions about what requirements drove you to it and what things aren't you going to consider. Because we could find fault as we have talked about earlier with almost anything. So what were the limits that you designed to or proposed in certain aspects of the architecture. And give me a set of your benefits and disadvantages because let's consider them. I may - from my experience, that isn't the same as yours - be able to give you some ideas were I have seen elsewhere. So I can give you some insights and if you are honest about it, again - for a constructive reviewer - if there were things that you were not certain about and you wanted me to reflect upon, well then tell me. So that's one pattern for a constructive thoughtful person who isn't going to say: "Yes, No, I am going to slam you," but they are going to give you a valuable feedback to improve the architecture. So on the other hand if you have someone who is going to be a little bit more judgmental you may start out with the things that limited our considerations. And then 'here's what we did' and 'we ruled out these things because of those facts' and 'here's what we are recommending' - sell, sell sell; and that's a different approach, that's a little different approach.

Something that I like to use, not in all, to sell an architecture but just in order to document the single decisions is actually the pattern form. A pattern is also like a single piece of information that is well described with problem, solution, context, and so on. I think that's also a good pattern to describe any kind of decision information, so that's also maybe an alternative that could be used?

So that's actually interesting: In our Telco integration framework - where I got external reviewers for - we actually did document our design decisions that way and we have like ten maybe, key decisions that drove us. And we did use that. And I was not thinking so much of patterns at the time, but it just seemed like a good way to explain it. But you are right, it does match the pattern.

In some sense the pattern form is just a good way to explain something.

Yes, yeah! Well now the other thing though - that was slightly different other than the pattern form - was, again we were looking for feedback. So not just saying what the forces where but also the issues that we wanted to address. So we wanted to leave it open for someone to comment on.

So how do you work with biases people have? I mean be they political or there is this web service guy who wants to do everything with web services? So there is Gregor Hohpe who wants to do everything with messaging. So whatever you do there are kind of biased to what certain solutions, how do you handle this?

I can say that Aspects rule the world and they are really cool and not everyone shares the same biases and if you latch on to an idea you think it's really great. I think it's really hard to overcome, biases are predispositions. If I have done something a certain way then I tend to follow that cow path. We pave the cow path as you say, and in some sense the first thing to realize is that you have biases too! I mean I do.

Sure, I have clearly.

Yes, Smalltalk is one of my favorite biases.

Model Driven Development.

Yeah that's right. As a matter of fact, recognizing that people will naturally - it's not good or bad, but it's just my easy non-thinking reaction to something. And then to recognize that I have to point them out if I am going to or subtly manipulate them. And that's not selling, it's subtly manipulating it, so the information that they should be seeing is more evident to them to overcome their biases for them.

Okay the next big issue is of course how do you make sure if you give an advice that people actually care and follow it. So you have to be convincing also as a reviewer because you have to make them do what you think is good, well, you should at least.

Well you can not make anyone do anything as an external reviewer. But you would like to make it clear that there are things that they should do. And if they don't do it here's what you think about it. And so in actual fact I've learned that in order to - again - not be threatening but be realistic. To break down what I do in to recommendations versus suggestions and observations. So an observation if you stack up a number of observations, well, maybe they could draw some conclusions from that. But not everything do I want to do that. So I limit the time to the really big recommendations. I could have a number of suggestions but big recommendations should come out, and the other observations they can draw their conclusions from.

So you are saying: For the really important things that you really think are mission critical, you give specific recommendations?

Specific recommendations and as concretely as I can supported by evidence because again there are those people that say fact finding and so if I can even use the words that I heard in a review or samples of code if they are showing things. So I can support it with evidence but oftentimes the people that are reading or looking and listening into your recommendations and I usually write written recommendations wants to know what's the heavy hitter items the most important and how do I support it with evidence and then all these other things, well those are nice.

It's actually interesting now, after actually you did the review as a reviewer. Now you become kind of the architect because now you have to communicate or sell your, let's say, changes or your changed architectural base in your review, your recommendations. So whenever you do an architecture review you also have to play the role of the architect.

That's an interesting point and in some sense I would say that I am not the architect but I am also not the casual observer anymore. And so I am someone who is saying: 'given my wisdom and my insight, here's how I might adjust your architecture'.So it's a careful line. I've seen some architecture reviewers go way over to just damning and telling it's bad and whatever. Whereas if you're trying to have an impact you just need to focus on: "Here's the key things I think must change and why. "In some sense I think that if you adopt a triage mentality when you trying to make recommendations. When someone walks in a disaster and there are a number of people that are injured or there are spots in the architecture that aren't quite so - the triage basically says there are things we can do something about, so they tie a green, orange or yellow ribbon around it if it's serious enough. If it's dead and it's hopeless they tie a black ribbon around it. And if it's green like it's maybe a little problem but nothing then they are walking wounded and they don't need immediate attention. So again it's trying to make sure that the most important things get emphasized and the other things can. Not everything has to be addressed.

So how do you persuade people to actually do these things?

As I said I have a written presentation usually that I do. But I also like to review my presentation with the key stakeholders before I deliver it as well. So I am saying: "Here's the things I am going to say" And then: "who should I really target this report to", so that they listen. So, for example, the VP of Engineering may bring me in. Okay, but he really wants the CTO to hear the message. And so in some sense I am not trying to blindside the person who brought me in to do the review. I am trying to support and discuss with him and so in some sense then I package it. And this sounds like marketing, doesn't it? So that the person, who is the primary target of the change or the recommendations, hears it. And they may not hear exactly what they wanted to hear, everything was rosy, but --So I have to make sure that they agree with my assessment and then present it in a way that perhaps raise some of those issues that they weren't comfortable with hearing before. They might have fixed on some things and said, "Oh, yes we are okay, we are great in this area," and then you have to get them unstuck on that point perhaps, and so it takes some convincing. Now, unless I live with a company after I do a review, I don't always get to choose to make sure that they hear all of what I say. But I do my best, I do my best! Sometimes they don't listen to what you say, so they're going to try to seek out information that supports their pre-held view. And that's a very difficult challenge as an architect.

So what do you do then?

Well they paid for me to come in and talk to them. They paid for me to spend a week or maybe even two weeks going and working with technical staff. And if I present them enough evidence and they say, "Well you are pretty harsh on us," and then they don't take my call to action, there is not much I can do. Except for saying, "I did my honest assessment." So I can't fix the world but I can point out the most critical things to consider.

So you probably even shouldn't feel really responsible of having these things implemented. Except if you are also going to be brought into actually implement things. But otherwise, basically, your mission is to point out what the problems are and give recommendations and that's it.

And that's it, in a way that they will hear. And so you do have to - again - listen to who is this report or this review for. And oftentimes, for me, I am presenting a number of issues to the technical staff and architects. They tend to have no problem listening to me. It's usually the executives, higher up where they may have to make some tough decisions that is more difficult.

So, when you present the result of your review -- (is it written or actual presentation?)

I probably do both.

so how much of that is psychology and marketing as opposed to hard facts?

Well I think it's a blend and the hard facts have to be there. My experience as a --

As a basis but it's not enough.

-- basis but it's not enough. And in some sense if all I did was present hard facts they probably wouldn't pay me so much, because I just do the technical. And so putting a spin on it in a way that has reflected that I understand both their mission, their marketplace and don't just focus on one thing but try to fit into their context, my comments has a bigger impact. So in some sense I have to develop a relationship with a variety of stakeholders in order to have the impact of that I would like in a review.

And since some times those stakeholders are on different sides of the table, that could be quite a challenge!

That can be quite a challenge. I don't know whether it's a good thing or not. But when at the end of the review - when the architects, product marketing and engineering are happy with me, I think I've done my job. They may not be happy with the magnitude of a recommendation, but at least they felt like I heard their concerns and I think that's --

You were fair.

Yeah I was fair but not dismissive of little problems. So they are appreciative in that way. Now do they act, that's another question.

Okay so this brings us to the end of our discussion. Is there anything else you want to say that we forgot or any words of wisdom towards the end?

Well I actually think that as a company or a product development group or an IT group that sometimes you do need that external perspective. And so external reviewers are good. I am not saying this just for having a need for more consultant. But on the other hand if you are doing that, that you ought to consider that what's the next step you need to -- I am very frustrated by people who take reviews and still "well that was nice and now let's go find another reviewer who might tell us what we want to hear". I have heard this at a -- other people who do architecture reviews and in some sense if you are investing in this then you should invest in some solutions too.

Exactly that was the prefix or prelude, foreword that I put on to the last review I did. Because I was skeptical about whether my customer would actually do what I said. And actually I was like "you pay me, you better at least consider it seriously what I say and so try to --"

And if they are not then I suppose it's their problem. But in actual fact I don't want to be part of their problem, I really don't. I don't come in there with my agenda.

So let me ask one last thing that just came to my mind. There is this thing about code reviews. So teams do internal code reviews to increase the quality of the code but also to make the reviewers aware of what's happening. Do you think it's a good idea, if you have a large organization, to have the teams to architect the reviews between or among themselves? So every architecture team is also a reviewer of other architectures, just to see both sides of the coin?

I actually think that if you build an architecture practice, that's one of the fundamental things to do. And so large companies that I know that are successful actually do this. And in some sense then you need to have this culture that says: when we make commentary we are not trying to compete or those kind of things. But how do I develop a supportive culture? And I think it really helps because there isn't just one best architecture. And if we are doing product lines or we doing enterprise applications, certain things may demand different choices and people make choices that change over time. So developing that community of practice in larger organizations is really important. Then they don't need us so much as consultants. If they develop their own review culture and that would be just fine by me. But they need to know how to communicate again and that's --

Not a skill you would find too often in --

-- too often, yes. And they also need to know in some sense how to give a realistic presentation of both benefits and risks. In a way that isn't going to turn people off or snow them with too much dazzling technical brilliance.

Okay, Rebecca thanks for being on the show.

Thank you very much, I enjoyed it.