Skip to main content

Agile is Rational, Rational is Agile Series: Architecture? Agile Don’t Need No Architecture!

To watch the Flash version, you need Flash 8 or later, and Javascript must be enabled in your browser.


HOLITZA: Good see you guys again. I'm really enjoying these chats. You know, any break from the usual routine is, you know, it's all good. So I'm really interested to understand how modeling fits into the Agile paradigm.

When we chatted last time Scott, you mentioned that the misconception out there that Agile shops don't architects of their software. And I was wondering if you guys could embellish on that a bit more?

AMBLER: Sure, yes.

This is actually one of the great misconceptions that people have about Agile. The reality is that the vast majority of Agile projects do in fact do architecture, and they'll do some architecture and visioning up front, but the main differences that we see is that the Agilist will spend, you know, maybe days or a week or so doing this sort of work and not, you know, weeks or months that we see sometimes in the traditional world.

So the main difference is the Agile community tries to get value out of modeling which is to think things through and to communicate ideas, but to not take the hit of unnecessary documentation. So we're focusing on the value and not on the bureaucracy.

BOOCH: And [INAUDIBLE] you can go back to the basic tenets of what architecture is all about, every system has an architecture although most are accidental and a few are intentional.

The desire is to increase the intentionality of that design because in the end, all architecture is design although not all design is architecture. And for me, the architecture represents the significant design decisions that shape the system.

The challenge, though, is that you can't a priori know what all those decisions are unless you've actually tried it against some raw running naked code. So by having a process, which is what Agile is all about... do the minimal but intentional and desirable things necessary, and then validate those against real running systems, and then come back and revisit those, then you have this delightful dance between architecture and implementation. And the two really influence each other over time.

AMBLER: Exactly.

HOLITZA: So how does software architecting, modeling and construction differ in Agile shops than more traditional shops? Or is there a difference, or should there be a difference?

BOOCH: Well, it depends on what you mean by more traditional, but if you're assuming that the more traditional tends to do more heavyweight modeling before they touch a line of code and before they validated it, then, you know, the fundamental difference is having this tighter feedback loop between asserting the design decisions and then validating them against reality because, you know, injecting reality is always a good thing.

HOLITZA: Right. Yes, the customer I'm dealing with, what they tend to do is do one large, you know, technical design document at the beginning of the software process, then six months later they deliver code to production. So that's kind of what they're doing today and, you know, that's obviously not working for them.

AMBLER: Yes, that's a common approach, and it's actually fairly risky in practice. You really do want to have more of an evolutionary approach to architecture, evolutionary approach to design and development. One of the things that the Agile community brings to the table as well is this greater focus on discipline that we often don't see in the traditional community.

And so not only will we do this little [grip] unfront model and get going in the right direction, and know, we also want to reduce the feedback cycle. But more importantly, particularly the more disciplined Agile developers will also do test driven development where they write a single test before they write just enough code to fulfill that test.

And the end side effect of that is that not only are they doing more validation of their work through a continuous integration approach, but they're also specifying their software in detail as they go along.

So they have a tendency to do more specification and more validation leading to greater quality. So I think there is a lot of good things to be said about that approach, but it does require greater discipline.

BOOCH: You know, you mentioned the phrase, six months. And, my gosh, in software terms, that's the equivalent of a major geological epic. There's so much that can happen in that timeframe. And if one asserts those kinds of decisions to any level of detail over a six month period without validating those in reality, then you probably have done the illusion of architecting but you've probably architect the wrong things.

Indeed, you can't even really reasonably ask the right questions about the architecture until you have something to validate it against. So this feedback loop that Scott speaks of is so essential to making the right architectural decisions about the right issues and actively attacking risk.

HOLITZA: Right, right. So how would a customer move from a heavyweight architecture, you know, that I talked to earlier, to a more lightweight evolving architecture?

AMBLER: Well, I think the first thing is to try it. You've got to start piloting some of these new concepts. I think one of the things that I see with a lot of customers is that, you know, they'll have some very good skilled architects and some very good skilled designers, but they'll believe a little too much in the do it up front type of mentality.

So we often have to sort of [rent] that sort of mentality back a bit and you know, hold them back. And at the same time, the coders might want to do a little less architecting than will be healthy for them. So we have to sort of prod them along to say, you know, why don't we slow down a bit, do a little bit of thinking before we act, and then let's act.

So it's, you know, we need to sort of find the middle ground in between these two extremes of either over architecting or doing no architecture at all. And I think it's the experimentation, the piloting of these techniques is absolutely critical to your success.

BOOCH: Another curious cultural thing I find is that those organizations that tend to upfront design in a heavyweight way are also those organizations that are afraid to fail. And failing is not a bad thing if you do it on a small scale.

Again, you can't know a priori all the risks you're going to encounter, so by proceeding in a manner where you have rapid feedback, you build things and try them, that actually creates the opportunity for you can fail small and learn from that, as opposed to being ultra conservative in your designs and failing big in the end whereas many who follow traditional waterfall lifecycles often end up.

HOLITZA: Right, right, that makes sense.

AMBLER: Yes, exactly. One of the things we talk about in the Agile community is we want to fail, we want to fail early so that way we can learn from our mistakes and move forward. By failing earlier, by failing in short feedback loops, you end up being, you reduce your risk and it ends up being a lot less expensive in the long run.

BOOCH: It also creates the opportunity for you to be refactor along the way as well, because the architecture you may assert at the beginning is probably not the right one for the fifth, and you need to have process that allows you to refactor along the way to keep improving that architecture. It becomes one of not just asserting the architecture, but rather a process of continuous architectural improvement.

AMBLER: Exactly. And refactoring is a quality technique, and I see many organizations are often afraid of it at the beginning because, you know, they're always worried about well, refactoring is a waste of time, it's not going to help them, it's rework.

And you've done a poor job, and the exact opposite is true. It's, I'd like to view refactoring as an investment quality. And you know, who really doesn't want to invest in quality? So it requires a bit of a mindset change.

HOLITZA: Right. So how does Rational help companies adopt these lightweight evolving architectures? What can we do to help customers succeed in these endeavors?

AMBLER: Well, one of the things we do is we've got a new service called Measure Capability Improvement Framework. And what that does is, it's...there's a couple aspects to it. The first one is an initial assessment to discover where you are, where you want to be and as well, you know, what's stopping you, what are the inhibitors that are preventing you from succeeding? So I think that's absolutely critical.

And then the second part is, you know, how do you continue to monitor and assess where you are so that we can actually act on the suggested improvements. I think that's one of the big differences between this sort of process improvement approach as opposed to what we've seen in the past where, you know, assessors would come in, they give some very good advice, and then it would sit on the shelf and nothing would come of it.

So you actually need to execute your strategy. So I think this is a good thing. But it really does, you know, you need some training and mentoring as well. So I think there's that sort of stuff going on. So there's a lot of opportunity for improvement if you choose to make it.

HOLITZA: Great. Well, you know, this is making a lot more sense to me now. I'm really starting to get the concept of what Agile means for the customer I'm working with.

But you know, I really want to get into some of the other aspects of Agile. Can we meet next time, and talk more about how testers fit into a Agile paradigm?

BOOCH: I would love to do so.

AMBLER: Yes, definitely.



Video not available.