One of my hobbies is tabletop wargaming – games with miniature figures, maligned in some quarters but actually a very social and creative pastime.
Recently I read “Tabletop Wargames: A Designers’ and Writers’ Handbook” by Rick Priestley & John Lambshead. A few of you might have heard of Rick Priestley; he is the world’s most successful and best known wargame designer and created amongst others Games Workshops’ Warhammer and Warhammer 40K, which together have outsold all other wargames by a huge margin.
This is where the link with CnR system design comes in.
Unlike chess or backgammon for instance, tabletop wargames have no single, accepted set of rules and the book explores the many facets of the game design process. What struck me as I read it was the overlap – in concepts as well as terminology – with good system design experiences I’ve had over the years. Perhaps this shouldn’t be surprising; but what is surprising is how frequently the key elements of executing a good design are not properly catered for in projects.
With this paper I aim to highlight the crucial areas that need careful consideration during the design phase.
CnR application implementations – getting the design right from the get go
Firstly, it is worth re-stating why the design phase is so important. Everyone acknowledges this, but because it can be difficult to chart tangible progress in this (very much a thinking) phase, there is often pressure to get on with it and produce the deliverables ASAP. The evidence however does seem to be that proper effective time spent in the design phase results in less re-work – and less project pain – further down the line (e.g. shorter build, testing and implementation timeframes) as well as a more robust end solution. And note this applies to project methodology approaches including both waterfall and agile; indeed it is even more important with the latter in order to ensure firm foundations are in place on which to build in an iterative fashion.
So, what are the primary design dimensions which a new CnR system project (or indeed most system projects generally) should take on board?
It is essential to have an individual or body of expertise who are responsible for the overall solution design – a Design Authority function – most crucially with regards to data entity structures and principles. This can be taken one step further. When designing a tabletop game, it is important to establish an overarching framework design within which lower level elements can be introduced (e.g. different units with specific rules) which do not compromise the overall framework. The same applies to CnR systems – putting in place an overarching framework design (data entity structures and principles) which allows for easier future maintenance and enhancement of the system without the need for a radical redesign and all that that can entail.
Reference has already been made to the Data Entity structure, but this is really important, especially when myriad systems are involved which may not all share the same primary entity relationships arrangement. At heart, we’re talking here of Customers (e.g. Single, Joint, Commercial (Sole, Partnerships, Ltd Companies) etc.) and Accounts – and who is liable for what. But there are others such as Security and Related Parties. For an agile orientated project, this is the main design aspect to settle right at the outset.
Another critical design element to nail down is with regards to Data Mapping. Most CnR solutions have upstream inbound (host) interfaces of one sort or another, and there are a number of downstream interfaces to other systems/reporting functions – and some downstream interfaces which feed back in. As well as some of this data needing to be transformed from a data structure perspective, individual data items might also need to be transformed en route from one location to another. With all this data traffic taking place, it is important to have a central Data Mapping function and documentation around which all relevant parties orbit – those writing programs and those configuring systems. Failure to do this effectively in the design and build phases comes to light in testing and in the additional time and effort in subsequent defect resolution.
As these fundamentals are put in place, then the more detailed solution design documentation can be progressed as required; high and low level designs; Functional and Technical specifications. With each it is important to create virtuous feedback loops with the Design Authority and Data Mapping functions in case there are challenges which need to be sorted or principles refined.
A final thought is that in order to fulfil much of the above, it does require within the resource mix enough bodies with relevant experience to ask the right questions, whether you’re dealing with CnR or wargaming.
Arum have such experience in abundance, so from the get go, make sure the right people are in place to ensure a good design solution which will provide firmer foundations for the project and beyond or contact us if you’d like some help.
Michael Haskell – Lead Consultant