Julian Browne, formerly the head of architecture at Virgin Mobile, wrote a series of three posts about his experience with and views on Space Based Architecture:
- Space Based Architecture Illustration - In this post Julian provides a general introduction to SBA, and describes how at Virgin Mobile they re-designed a centralized J2EE Web-based Order Management System (OMS) into a scalable SOA using Space-Based Architecture: "we could make ordering a reliable and predictable process, and we could reuse our new OMS for other channels (why stop at the web? Once it works and works well, why not re-use it for telesales and high street stores too?)"
- Space Based Agility looks at how SBA supports Agile because of their complementary nature to how business people think.
- Space-based Archetypes discusses some of the subtleties of SBA as it relates to non-functional requirements such as Availability, Capacity, Concurrency, Enhance/Extend-ability, Interoperability, Latency, Maintain/Manage-ability & Monitoring, Recoverability, Reliability & Resilience, Security and Scalability.
Here are a few my favorite highlights from Julian's view and definition of Space Based Architecture. Julian's take is quite interesting since it goes beyond the technical definition to a level that can be understood by almost any human being (including my wife:) )
* 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, that is accessed by more than one person/role, you can refer to. And having special spaces for certain activities is akin to a departmental separation of concerns.
* Entries in spaces are also easy to discuss without boring them to death with code walk-throughs and technical details. In the non-software world, passing a 'thing' (most commonly 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 heated floor, 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.
Julian on when should one consider using SBA:
..my summary of all this is that if you have a simple application, with predictable growth and reasonably contained business logic a tired approach will do fine. If it's a database-driven web site that's not going to get heavy throughput, or generating lots of business transactions, then one of the MVC frameworks will probably cover it. But once you get into distributing that logical architecture across nodes, and the words scalability and transactional safety start to become important to the business, you really do need to look into better ways to break away from some of the heaviness of JEE, you'll probably have to do a bit more work to get some operational aspects to the same level as for the big application servers, but it's more than likely to be worth it in the long run.
Beyond the fact that it is an excellent piece, it is an indication of something that I felt happening to everyone exposed to the SBA concept . Once people get it, they feel this approach makes so much more sense than the traditional approaches they've been exposed to.
People that were burnt in the past by N-Tier architecture and J2EE are most likely to be enthusiastic advocates of SBA, as I've witnessed in our recent customer conference. I'm hoping that Julian is only the first one to speak about it publicly.
