Last time I left the cap off of the toothpaste, a small blob of toothpaste flowed onto the counter. No planning; it just emerged.
Now I know that emergent software architecture is another thing entirely. We can’t anticipate everything about our software’s architecture before we start building it. It is impossible to get design “right” the first or the second or the third time. That’s why it is so important to iterate. Yet I don’t like to think that good software architecture simply emerges. It’s a bit more complicated than that.
Several synonyms for emerge leave me feeling uncomfortable. I’d rather not have my architecture materialize, loom or just crop up! Emergent behaviors are a reality with complex software. But emergence doesn’t equate to goodness, no matter how hard you wish it did.
Yet I’m not a fan of big upfront architecture theoretical architecture, either. Emergent behavior can be an opportunity. I like the sense of learning and anticipation in these synonyms: become known, become visible and come into view.
The architecture of complex systems simply has to unfold. We make architecturally relevant decisions based on what we know at any given point in time. And when we don’t know how to proceed we experiment (don’t tell your boss that, call it a design spike instead).
Our architectural ideas should change as we write more code and build more of a system. The many micro-decisions we make along the way should lead us to change our minds and our architecture. We shouldn’t have to live forever with bad choices. That’s the beauty of iterative and agile practices. We can fix and repair things. So this is my way of thinking about how good software architecture comes into being:
Good architecture doesn’t emerge; it evolves.
It’s deceptive to say, good architecture emerges. I find that good architecture rarely œemerges. We aren’t magicians who materialize good architecture. Good architecture involves hard work, reflection, and paying attention to details. Ideas for architectural improvements emerge from coding. And as long as you have the skills and chops and know-how to make significant changes when they are needed you can improve your architecture. It takes skill to keep your software’s architecture on a good path. Refactoring and redesign is essential. Only when you have the courage (and permission) to refactor and rework your design will your architecture keep pace with your software
Sorry for spelling errors in previous. Here is exactly ONE serious corrected :
I could sign everything the Rebeca states here, but I am annoyed by the whole “architecture†concept in IT-system design & construction. I feel that it too abstract, fuzzy thing to really communicate. It contains so many aspects and layer that I have continuously difficulties to know what different writes actually means with it.
Anyhow my conviction is that there is a “eternal architecture†that is really more of a “perception or thought pattern†than any architecture. This is the loosely coupled 3-tier: Application layer, Domain layer and Persistence layer. The key here is that Domain layer code has NO references outside its own layer.
This pattern can be found for instance in all Sun’s Java presentation from late 1990’s. My true conviction is that this cannot change as long as we build operative control system for businesses and implement them in implementation of deterministic Turing-machines.
for more see my blog: http://jukkatamminen.wordpress.com/2010/02/23/oo-model-driven-application-development-the-state-of-art-and-for-the-foreseeable-future/
I think some people assume that architecture will just happen in agile projects. I agree with your points – it takes know-how, courage, and permission to make sure it does. It also takes some slack or breathing room – as even smart, courageous people can be so focused on the many tasks at hand that they don’t step back and think about the bigger picture.
In terms of planning an agile project, I don’t know if it makes more sense to allow some slack or to plan in some architecture spikes or other activities to facilitate some focus on it. I’d be interested in what you and others think.
Nadya- Yep. Architecture that just “happens” may not be what you want. Declaring a design spike works fine if the team is small, capable and tcan push back at times and not just let feature delivery always drive development. One way to manage architectural tasks for a larger project or program is to tag product backlog items that require architectural work or decisions. Those that do shouldn’t be worked on until the architecture is ready enough. Rather than just add in these tasks to the regular project background it may make more sense to have a separate backlog (or a kanban) for them. Often architecture-related tasks may not fit neatly into a sprint cadence (they may be hard to estimate and/or spawn even more tasks as you get into them). That’s one reason to keep them off the regular “sprint” backlog, yet still track their progress. The benefit of a kanban (instead of a scrum backlog) is that tasks don’t need to be sized to fit into an iteration.
I plan on blogging a lot more about various approaches (and they are discussed our new Agile Architecture workshop that I’ve developed with Johanna Rothman.
Managing agile projects so that architecture gets the attention it deserves involves first recognizing that it is important, and then putting processes and practices in place to support it.
Jukka-I would be interested in hearing more about why the whole architecture concept in IT annoys you. I suspect it has a lot to do with the fact that architecture is used in too many ways: enterprise architecture, solutions architecture, systems architecture, technical architecture, business architecture…etc., etc.
But my thinking about what software architecture is quite different. It is those fundamental choices and design decisions that impact the way you develop and deliver functionality. Pnce you’ve made an architecture decision (and then implemented significant functionality based on it) then it is hard (not impossible) to change. So, for example, the choice of a particular presentation framework can be an architecturally relevant decision…so too, can be the way you decide to do authentication or authorization, how you integrate services, even the design of critical service interfaces….
Thanks for the pointer to your blog entry. Your notion of an “eternal architecture” / “thought pattern” is a little higher level than what I mean. These seem to be high-level (or abstract). They are patterns for architecture (or styles), not architecture realizations.
Many aspects or artifacts of the software development process are only attended to if they are valued by the organization. So while individuals may have the skills, chops and know-how to initially address or readdress architectural issues; if the only valued outcome of a software development effort is working code, architectural issues may be ignored.
An interesting exercise is to conduct a ‘Value Model.’