In general, “architecture” is a word that carries some heavy connotations in the “agilist” community. We all fear the unfortunate problems that BDUF brings with it. We do not believe it is wise to start off by defining a big detailed design up front. What happens is that once you begin the learning (working) process, your BDUF plan changes anyhow, often A LOT. In this case you are either forced to
#1 Change your BDUF substantially enough that it was a waste of time.
#1 Conform to your BDUF even though it is no longer fit for the work you are doing.
Neither of these things is particularly nice. The agile view is that you let your architecture emerge. You put lots of tests in place, and your system is rapidly changeable. This is all well and good, but the larger the systems get, and the more dependencies there are, the larger and larger the “rework” becomes. For truly non-trivial distributed systems of applications (enterprise application portfolios for example) NEED some contracts between them. The volatility INSIDE one of the specific systems can change a lot easier than the contract that a system has with the systems that depend on it.
The general idea with “architecture” is that for small systems, you need a little, for medium systems, you need a little more, for large systems… etc. You DO want to allow the architecture to emerge, but you also need to coexist in a network of dependent systems. What are we to do?
I will add one more dynamic to the mix. In general, you want to be oriented to delivering “end user effecting behaviors”, not “software elements” per se. The general idea of “slicing the work vertically, not horizontally” has been spoken about a few times before, and it is something that I preach all the time. The basic idea is that you DO NOT want to build your system layer by layer, then arrive at the “end” or “top layer” and finally see it all come together. This is a model of failure for several reasons:
#1 The vaporware problem. Long periods of time pass and you have “vaporware”. You may well have developed a great resource access layer, transports, middleware, etc., BUT if you do not have anything visible and meaningful to an end user – it is STILL vaporware.
#2 When you get to the top layers, you get the fun of seeing the “things you missed” that you need from the upper layers and these changes have to ripple back down anyhow (aka, you were not really done with those lower layers as you thought). This leads to “hidden work”. “I thought we were done with the DAO, why do we keep going back to it”. You have a fake understanding.
#3 You get to see the incongruities between layers later.
#4 You are getting feedback from end users later. You are learning later.
In stead, we slice the “work vertically”. We in stead focus on delivering “user stories” or end user effecting features. We then work on the parts of the system that we need to in order to meet this goal. In this model, we are able to get feedback and learning faster. We are able to evolve the architecture each iteration. We have emergent architecture behavior. We are able to focus on “the prize” that really matters – delivering end user functionality.
OK – sounds good, but what does this have to do with Plinko and architecture? In case you missed “The Price Is Right” era; Plinko is a game that looks like this:
The basic idea is that you drop some disk like thingys in the top, they sort of “plinko” their way down into some predefined buckets at the bottom. Lately I have been using this game as a sort of metaphor for how I have been thinking about software architecture these days. The applications/ ecosystems of applications that I have been working on are large. Investment banks have very very large interconnections of software that is related, codependent, etc. There is obviously the need for some level of architecture. We ALSO want the emergent architecture behavior. In order to reconcile the 2 models, Plinko makes a lot of sense to me.
The basic idea is that your architecture is the buckets at the bottom. The implementation of work items – that are “vertical slices” are the bits and pieces of development along implementing a story that “plinko” down and land in some predefined bucket. People working at levels that cross between systems, on system integration/ collaboration, internal service providers, API providers etc work to define the “buckets” that make sense and provide a basic framework for operation. The best case is that “scrums of scrums” collaboratively evolve the “buckets” of the “grand organizational plinko”. This is real work and there are non-trivial challenges to effectively doing this work. That being said, the idea is to focus on true “breadth” here. The higher level architecture definitions focus more on defining the buckets than worrying about the “depth first” implementation of any particular bucket. The implementers of any particular bit focus on delivering those vertical slices and letting them plinko to the correct place.
We allow our development teams to focus on iteratively delivering “end user effecting features” or stories. Their ability to deliver these is the primary measure that matters. Tested delivered features is all the business really cares about anyhow (yes, quality, fitness for purpose, etc., but basically that). The implementation level inside these buckets emerges. Things that seem to fall outside these buckets can work to evolve the more “macro” level archetecture. In the “scrum of scrums” model, the bucketing of the plinko board can certainly change, but these changes must make it onto the queues of work for any of the players/ teams.
The key here is to work on defining the buckets, but not getting too caught up in immense detail. Things WILL change. Too much definition of detail will be false anyhow. Setting up an architectural model that expects change and allows for implementations to drive the changes as needed is required. The end effect is a system of systems that can co-evolve. This is the real end goal. Building large class software is a challenge. BDUF does not work in generalÂ – the learning that happens during development will change your design. Short sighted design decisions can hamper sustainability with zero design/ architecture. The Plinko Model allows for a bit of both, while allowing teams to “slice the work vertically”.
I’d love to hear any thoughts 🙂