As I’m now into my second year I reckon I can become more experimental in my blogs. This entry is therefore completely off the scale and will either not go any further or be the start of something much bigger. Comments suggesting which it is are welcome.If we want to be able to build real complex systems (see previous entry for what these are) what might we do differently to ensure we allow truly emergent properties to appear? Is there a development process that we could adopt that both ensured something was delivered in a timely fashion but that also allowed sufficient ‘flex’ such that emergent behaviour was not prevented from happening? In other words is it possible to allow systems to evolve in a managed way where those properties that we value are allowed to grow and thrive but those that are of no use can be prevented from appearing or stopped early on?
Here are some properties I think any such a development process (an evolutionary systems development process) should have if we are to build truly complex systems
- The process needs to be independent of any project. Normally we use processes to derive some kind of work breakdown structure which is used to plan the project that will deliver the system. In other words there is a well defined start and end point with clear steps stating who does what by when in between. However for a complex system there is by definition no stopping point; just a number of evolutions where each introduces new (and possible unpredictable) behaviour.
- The process should be driven not so much by what users want but by what users do. Most processes start with a list of requirements, possibly expressed as use cases, which describe scenarios for how the system will be used. The problem with this approach is that use cases only describe what a user can envisage doing with the system and will not capture what they actually end up doing with the system. In other words the system is deemed to be ‘complete’ once all the use cases have been realised. However what if the act of delivering the system itself results in new use cases emerging. Ones that were not planned for? How do they get realised?
- The process must be both flexible enough to allow users to experiment and envisage doing new things whilst at the same time being robust enough not to allow negative emergent behaviour that will prevent any system being delivered or lead to the system deteriorating over time.
- If new behaviour is to be adopted this must be of overall benefit to the majority and must still meet (a possibly changed) set of business objectives. The process must therefore allow for some kind of voting system where the majorities behaviour is allowed to dominate. The trick is not allow new and innovative behaviour to be crushed early on.
- The underlying rules that control how the systems responds to external stimuli must themselves be easily adaptable. The process must therefore treat as peers the rules that govern (allowable) behaviour together with the description of the behaviour itself. Rules set some kind of constraint on what is allowable and not allowable by the system.
Of course not all systems that we build will or should be complex ones. As noted previously safety-critical systems need to behave in entirely predictable ways and users should not be allowed to change the behaviour of these where lives could be put at risk. So what type of systems might benefit from an evolutionary approach to development?
- Social networking systems where the users are intimately bound up with the system itself.
- Commerce systems where the buying behaviour of users might change how and when certain products are sold and at what price.
- Financial systems where money markets may affect what users do and how they respond.
- Government systems where responses to new legislation or the behaviour of citizens needs fast responses.
- Other, you decide?
My next step is to think about what the elements (process phases, work products etc) of an evolutionary systems development process might be.
Software Architecture Zen 
Interesting questions. I had meant to comment on the original post in this series and think my initial thoughts / comments here probably relate more to that. I'll get those down and then think about a follow-on comment 🙂
I'm unsure whether the systems that you reference truly display emergent behaviour (due to interactions between components), but instead allow people to use the system in ways that hadn't been expected. Trying to think of concrete examples of emergent behaviour to help frame the discussion:
* the infamous world of warcraft plague (http://news.bbc.co.uk/1/hi/technology/4272418.stm) seems like emergent behaviour as unexpected interactions between parts of the system led to this (albeit players exploited this unexpected behaviour to create the plague)
* facebook behaviour such as the Christmas Number One campaign is less emergent behaviour and more the network effect of facebook enabling huge numbers of people to rally around an idea.
That said, I think the comments about flexibility of development and the ability to 'flex' is important in building systems whether they are 'complicated' or 'complex'. In some part I think this is less the problem of SOA (Same Old Architecture) and more the problem of SOB (Same Old Business). The business & IT engagement process needs to be able to quickly respond (avoiding the 'A' word) to new information discovered during design / dev / testing to be fed back into the system (in a subsequent iteration perhaps) in time to be useful. Sadly at times however it still seems difficult enough for just the core interactions / use cases to be delivered successfully, let alone the kind of unexpected interactions that may come out of experimentation and which are the kind of behaviours that are most likely to 'delight' users. I think this kind of flexible process is easier when you're a company producing your own product / system e.g. Facebook, Blizzard (World of Warcraft), and much more difficult in the government / financial services scenarios where the contracting approach and need for firm estimates of what is delivered conflict with this agility (oh no the 'A' word slipped through!)
Feels like a bit of a negative comment this one, I think I need to get that bit off my chest before moving forward into the kind of process we could aspire to 🙂
Kris, Great points thank you. With regard to emergent behaviour just coming from components that make up the system I agree that is too limiting and that we really need to observe is behaviour that comes from the internal workers as well as the external actors and how both sets really use the system (or adapt it). For me the challenge is the one you point out at the end. How do Systems Integrators build complex systems given the short term contractual nature of the work they typically engage in?
” How do Systems Integrators build complex systems given the short term contractual nature of the work they typically engage in?”
Before thinking about the design / development process, I agree that getting the contractual / commercial position to support the kind of 'evolutionary' development we're discussing makes sense.
Most work I've been involved with occurs on a fixed price basis, which seems to be rooted in traditional engineering / construction / manufacturing where the expected behaviour and features of the item can be very specifically defined and then put out to tender. Customer: “I'd like a #4503 widget; it needs to operate in a temperature range of -50 to +120 degrees celcius, have a lifespan of 10,000 uses and a failure rate of 1 per 10,000 produced”; supplier: “That will be 10 dollars per widget”.
For the kind of evolutionary approach we're discussing here, the exact features of the product are not known in advance, as you discover and improvise them during the development process. This is more akin to a 'creative' industry than an 'manufacturing' approach. I wonder if lessons can be taken from how large scale creative enterprises work.
I have no intimate knowledge of these fields, but wonder how a company contracts for a major advertising campaign? As with our complex IT system, you can't define exactly how it should work or the exact features it should have. Instead you can provide a general theme and aims / goals. The supplier then has some creative freedom about how those goals are met.
How is the final deliverable assessed against 'acceptance criteria': i.e. when do you know you're going to get paid? Does the supplier have a stake in the outcome – what if the campaign turns out to be a disaster? These seem like fairly analagous questions as with our complex IT system.
Maybe advertising campaigns are contracted as time & materials and there's no great improvement to be gained here, but worth examining perhaps. Other large scale creative industries I was considering that may have parallels are a software house producing a computer game as a tie-in to a film (or other similar IP) license, or a film studio comissioned to produce the latest summer 'blockbuster'.