Space-based Agility

A related post on space-based architecture was published a couple of weeks ago. It was going to be a one-off but I was at the inaugural Gigaspaces User Group in London recently, and a couple of things occurred to me between presentations that I thought worth mentioning. So there are two extra articles to come (this is the first). Perhaps it’s not a conventional place to start, but the idea for linking spaces and agility occurred to me because I am having a bathroom remodelled at the moment (bear with me.. this will make sense in a minute..).

Nati Shalom, the CTO and a founder of Gigaspaces, rounded off the day with a fairly convincing presentation on the latest thinking to support the notion of a Space-based Architecture. The deployment mentioned in my previous post, although referring to a space-based architecture, in fact didn’t use the name as it wasn’t coined at that time and to be fair the idea has come a long way since then.

Rather than being simply a novel addition to the canon of enterprise integration approaches, it is now (for certain situations) a full-on critique of the n-tier approach: highlighting its illogical weaknesses and its limits around scalability and resilience as the ‘crash barrier’ is met. For some problem domains, it is suggested, SBA is not just an alternative worthy of consideration, but the rightful successor to tier based computing.

Quite a bold claim, and one that I’m sure will fuel debates on TSS, but above and beyond any technical merit, I think there’s enough synergy between the Space-based Architecture and Agile delivery that you could make a similar argument on delivery grounds:

• Tiered architectures often don’t make intuitive sense to business people, presenting a major communication problem when doing agile.

• Tiered architectures organise things by ‘technology purpose’ (presentational rendering, business logic, persistence, messaging) whereas in an SBA you organise by ‘business purpose’ - processing units offering services that exchange data

• Tiered architectures can create refactoring nightmares when developed iteratively whereas the decoupled nature of an SBA lends itself much better to sectioned delivery

But to fully explain this, we have to go back to my bathroom:

I’ve owned a two-hundred year old house for nearly fifteen years, which kind of forces you to pick up a reasonable amount of knowledge about fixing plumbing and household electrics. I’ve installed whole power circuits and plumbed in an entire kitchen in my time, but I also know when to call in the experts. Redesigning an entire bathroom, with a new electrical spur for the shower, a new roof, new consumer unit, new bath, toilet, basin, heated floor, etc is not a candidate project for my level of DIY, even if government regulations would let me.

There’s a lot to decide: where the walls go, what bathroom suite items you want, tiles, windows, lighting, ventilation and so on. It’s a lot like gathering project requirements from stakeholders. And like any group of stakeholders, my wife and I frequently disagree on what the requirements are. Even when we agree, we often change our mind (and disagree again) as we see the job unfold. What helps us get to something close to our shared conceptual model of a finished bathroom, though, is communication. Not with each other (were you not listening? I said we were married, of course we don’t talk), but with the project manager and the various electricians, carpenters, plumbers, tilers and plasterers that appear at our house every day.

And it works (so far, we’re due to finish in a few days) because every decision we have to make is explained by analogy and example, not by technology. So we we’re never asked whether we wanted an 8, 9 or a 10.5 KW shower, we were asked how often we showered, whether we liked ‘power’ showers, how much we were happy to spend. We were told about the ‘tap test’ that potential buyers do to basins to see if they are made of cheaper materials, and asked about when we might sell the house. We were asked how we managed the central heating in the summer when you might want a warm bathroom, but not a hot house. We were asked to illustrate, not specify, our storage requirements. Indirectly I may have picked up a lot of technical details about things like 300ms RCD delays and the way they interact with the consumer unit, but I could easily be blissfully aware of all this.

Perhaps it’s stretching the analogy somewhat, but the bathroom development has felt to me to be pretty component-based. The new towel rail, its cable spur and switched socket represent a fairly cohesive unit which is loosely coupled to the rest of the bathroom. If I changed my mind about having one, the whole lot could be replaced quite easily. The heated floor similarly has it’s own spur and socket at the other end of the room. A bit like processing units, rather than tiers - what the electrician didn’t do was put all the spurs together along one wall, and all the sockets together somewhere else. He could of. There are no regulations that stipulate where these things need to be (except for well away from water of course).

These principles also work during the delivery process for an SBA:

• It’s easy to talk to stakeholders about what a ‘space’ is. Everyone gets the idea of a blackboard. There are hundreds of corporate examples of shared-data, accessed by more than one person or business role, you can refer to. And having distinct spaces for distinct activities is akin to a departmental separation of concerns.

• Entries within spaces are easy to discuss without boring business owners or resorting to code examples or technical details. In the non-software world, passing a structured document (i.e. a form) between people and maintaining that as the basis of communication is entirely logical. Often forms contain instructions for the reader on how to interpret or use the form’s data (just think of your credit card statement. Wouldn’t it be weird if payment instructions were kept somewhere else, and you had to go and look them up?)

• Workers make sense too, not only because they represent real ‘workers’, but because as sponsors change their minds (if there’s one key attribute of Agile, it’s that it transparently reacts to changing requirements better than waterfall) the extent of change to workers and entries is linear - big change to model, big change to workers/data.

• Because the entries are code and data, they are, like my towel rail example, self-contained capsules of all that’s needed to perform particular steps of a business operation. Easy to isolate and change because they are naturally loosely coupled.

And if that wasn’t enough, you get some pretty impressive performance benefits too, which are just what you need when doing show and tell at the end of a delivery iteration. In the Processing Unit paradigm of SBA, much of the above is happening within the same VM, so there’s no network overhead, and because it’s memory resident there’s no disk IO (other than regular container activity).

Of course, on most projects there will always be legacy systems to contend with, but even here there are design options that can power your SBA processing units to new heights.

And that’s the topic for next time.