(This is part seven of a series. You might want to check the previous parts first)
Parallel and Simplification are the yin and yang of architecture evolution. Simplification, as mentioned previously, is about having foresight and thus provides for,relatively, easy evolution (i.e. architectural additions and not changes). Parallel is about reacting to changes in requirements as they come (no foresight) and making architectural changes.
But wait, architectural changes are hard by definition* – if we make a change to the architecture a lot of things are going to break – starting with the build (or the continuous deployment if you have one) and things will just deteriorate from there. An architectural change will take, relatively, a lot of time and there are a lot of risks in trying to put everything back together. Which is exactly why we need “parallel”.
As the name … Read More »
[Edited: added explanation of the difference between upfront design with iterative implementation and Simplification]
The previous installment in the series talked about leaps as a technique to change the architecture. Leaps are more of a revolution than an evolution and even though they are sometimes needed evolving an architecture is the more interesting topic. This and the next post deal with the two types of evolution strategies Simplification and Parallel. In Part IV I provided the following definition for Simplification (where the base definition is Kent Beck’s and the projection on software architecture is mine):
Simplification – is when you don’t know what you want to do and it is too expansive to directly get to an end result. This is the basis of the iterative system. start small and gradually add features as you go. From an architecture perspective it is … Read More »
When talking about “evolving architectures” a “leap” is one of the worst things that can happen. In the previous installment in this series I defined Kent Beck’s “Leap” design strategy in the context of Software architecture as
“Leap – is for when you know where you’re heading and you can afford to stop everything until the new way is in place. From an architecture perspective it is a bit like starting from scratch. From the practical perspective that would mean breaking the build until a few related changes are in place”
Basically making an architecture leap means that what we did so far is not good enough for us to go forward on. It also means that the current architecture is too far from something useful to bother with taking the more evolutionary approaches to getting it there.
This sounds very … Read More »
If we want to evolve architectures or change an existing architecture in general, for that matter, it is important to understand design mechanics. I recently attended a seminar with Kent Beck that talked about “responsive design”, where he provided a good definition for 5 strategies or types of design mechanics*:
“Just Do it”
Kent talks about these from a design and coding perspectives. Architecture is design but at a higher level and with more consequences system-wide so (I think) are are few nuances from how Kent sees this.
“Just Do it” is what you do when you don’t exactly know where you are going and you so you’re adding features and everything but you probably heading into a big ball of mud. If possible it is better to avoid working this way, but sometimes realities take us there … Read More »
Not all projects need architects. There, I’ve said it. Not all projects need architects and I am not talking here just about trivial projects. There are cases (maybe even many cases) where you can get by with what I call “off-the-shelf” architecture – maybe with a few adjustments that any master developer (i.e. seasoned and experienced developer) can handle. For instance a lot of web-sites can do pretty well by using Model-View-Controller (or a derivative of that) along with a simple O/R mapper such as active-record. In fact a lot of them do just that, when they use a framework like Rails that made these architectural choices for them*. Another example is the vanilla 3-tier architecture provided by software vendors (such as this one by Microsoft). Yes, when you take something off-the-shelf, the result might not be optimal but that doesn’t … Read More »
Before we talk about the what/how let’s do a quick recap on the why we’re here:
Architecture is important to software projects
Architecture and agile have some conflicting forces that needs to be reconciled (e.g. up-front work, hard to change vs. delivering business value quickly and embracing change)
design can be emergent but architectures can’t and must be grown instead
Another important point to remember is that sometimes you can get away with it. By “get away with it” I mean you can make 1 day or less design session opt for an off-the-shelf architecture, usually that also means choosing a product (e.g. Rails or Django) and it would be good enough for your project. This is usually true for small project or for projects which are ver/y familiar (and thus rather predictive and for the most part can be handled by waterfall processes).
If your project … Read More »
This is part II of a series on agile architecture. You can read part I here.
In the previous installment I provided a definition for software architecture and raised the apparent friction between the up front design implied by software architecture and the YAGNI approach and deferred requirements prompted by agile development in the large. This installment take a look at an additional angle of the problem which is the difference between design and architecture (while architecture is a type of design I cam calling design the code or close abstractions of it that don’t yet fall under “architecture” as defined in the previous post). The difference between the two, as the title suggests, is that while design can be emergent, Architecture, unfortunately needs to evolve.
Unless you’ve been living under a rock, you’ve probably already know about Test Driven Development (TDD) … Read More »
I’m writing a short series of posts for MS Israel MCS blog (in Hebrew) and I’d thought I’d translate them to English, as it seems to me they are interesting enough.
In this series I am going to talk about Evolutionary Architecture or , some of the aspect of dealing with software architecture in agile projects. The topic is interesting since architecture and agile seems to have some conflicting forces at work to better understand that let’s start by defining software architecture
There are many definitions for software architecture, with the simplest one (attributed, I think, to Kent Beck) that software architecture is what software architects does. Leaving the fact that (unfortunately) sometimes software architects are very far from building software architectures, the definition doesn’t tell us much. There are many … Read More »