Agile arquithecture

I remember Grady Booch talking about with kind of what's the traditional definition of a time it was a high-level view of their components and interconnections and there was then pushback without saying well is that really a good definition and this led to amongst other things the hard to change notion which i think is a very good one

But I think it was taken a step further very nicely by Ralph Johnson when he said well actually architecture is the important stuff whatever that happens to be and it happens to be that important issues the things that you have to care about a lot do often correlates with stuff

That's hard to change and this was reinforced really nicely by a fairly obscure talk that we saw in a again in an early XP conference by an Italian economist and he was primarily talking about lean manufacturing and some of the effects of that but one of the things that he brought out is that one of the core drivers of complexity is irreversibility if you can't change your mind and go back that then constrains you very much it makes dealing with situations very complex.

And his comment was in fact that the traditional manufacturing processes the the traditional production line it tried to deal with complexity by reducing how many states the system could get into while lean manufacturing focused on trying to that problem of irreversibility by making steps reversible you could simplify things and that.

I think is a very good way of thinking about the importance of this hard to change notion so nil kind of hit on the next point we want to talk about a one he said that architecture is a large large nebulous thing that we could talk about we could talk about a lot of things when we say architecture and they've only given us 40 minutes to talk so we have a divided architecture into two different areas application and enterprise and we want to be clear about what one we're going to talk about we want to focus on application architecture there are a lot more things that can go into enterprise level architecture.

But for this talk we want to make sure that we're thinking about architecture on an application level and of course when we say that we have to say well what do we mean by an application it's fairly fuzzy term I like to think of it is there are three sort of main things that drive you round arees of an application one is a code base and a team of developers working on some common code base second is a cluster of functionality that's perceived as a single thing by its users and then third and perhaps the most important a single source of funding because applications tend to have a set a single group or organization.

Funding channel that drives into it so with those boundaries we want to go back to architecture and then think about the agile piece of it how do you make it a little bit more flexible a little bit easier to change so to do that we want to think a little bit about what is agile and some of the principles of the manifesto and then also how is architect architecture been done traditionally.

Documentatión in software development

So first one of the principles of agile which is working software over documentation I think one of the I had a question asked me an interview yesterday which was is there perception the architecture does not apply to agile and I think one of the reasons for that is some of these principles I think instead of being interpreted as we want working software over documentation they've been interpreted as we want working software and no documentation.

so if we think about traditional architecture we might think of it as in the waterfall sense so this is a diagram that kind of shows what waterfall might happen and what phases there are now these discrete phases has have outputs of some sort and documentation is often one of those outputs for example the design phase like martin was calling architecture might have architectural diagrams as an output so when you think about what agile is saying to say working software over documentation or what.

I think a lot of people interpret it as working software and no documentation kind of raises a question well are we doing architecture in a sense I want to change this diagram and show you what it kind of looks like when we think about in an agile fashion so we bring it all together and not even kind of ask the question a little bit more well how do you have any time to do architecture how do you have any time to think about architecture well instead of discrete phases where we're having some output at each level we want to be thinking about the value that we're creating an each one and repeating that in agile and it's important to realize that this is not just trivia activities within a traditional waterfall sense you you do all your design you do all your architecture then you finish it and hand it over to the programmers it's not just that it's also that the separation in terms of people but the people who do it a difference we're not organized differently and they don't have much collaboration while in an agile team

it's much more close-knit I mean yes you will have some of these people who are taking an architect's role but they are much more a team lead within a group of developers and everybody is to some extent thinking about architecture and thinking about the day to day programming as well certainly the lead the architect has much more of the architecture responsibilities and is doing much more of that kind of thinking but they're also still doing a certain amount of day-to-day development work at the same time my view has always been if you're going to be a lead on a development team you have to be doing some programming that's why

I'm on the stage by the way yeah somebody has to be actually be doing real work on this stage so coming back to diagrams and outputs and and what value they had what is what is it providing I personally don't think that waterfall would have had a design phase and doing waterfall would have a design phase without having value it's going to provide some value but what is it lacking so when you think about having an output and then moving on to the next phase and separate people then you have to think about what happens when you learn something else and something has to change so another principle in the agile manifesto is responding to change over having a plan now I'm going to say this

In a different way again responding to change and having no plan that's one way that people interpret that statement and I've heard different synonyms for agile which is the wild wild west or cowboy coding so we're not going to have any architecture no plan nothing that's not actually true what we want to be thinking about instead of having a plan that's set in stone we want something that can change and we can iterate on we want the value of a diagram something that can communicate things but something that can also change and that change ability

I think raises some questions about the whole metaphor of architecture itself I mean the reason we use the word architecture is we're drawing a metaphor from the construction industry and as in typical with software development we got the metaphor completely wrong because in the software if in the building industry what an architect it does is concentrate on the experience of people working and using in the building I mean if we were to say what is the equivalent of an architect in software development

Koukio would be user experience designers it wouldn't be anybody concerned with the internal design of a system I'm very conscious of this because I'm married to someone who does do that work she's a structural engineer and that's completely different work at it and I can tell you traditionally structural engineers and architects get on just about as well as the average programmer and enterprise architect does in our industry so I think a better metaphor for what architecture should be like in the software world let's put it there's a nice little talk.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License