EA in miniature – Part 4: Prototyping
At present, enterprise-architecture is most often used in mid- to larger-sized organisations, and still primarily focussed on IT. Yet what can we learn by applying the same methods to a one-person organisation and their enterprise, and to capabilities beyond IT alone?
For this series, I’m using my own case as a worked-example. My chosen enterprise is in whole-enterprise architecture, the literal ‘the architecture of the enterprise‘. I’m transitioning to a much more in-person and more mobile role in that shared-enterprise: ‘enterprise-architect as digital-nomad’. For my work , this would be a ‘mobile-transformation’, essentially equivalent to the ‘digital-transformations’ occurring in many larger organisations right now. In practice, this is essentially the same as in enterprise-architectures for larger organisations – though often a lot more intense and personal here…
(For more on how the principles and learnings at this scale can apply to EA for mid- to larger-size organisations, see the ‘Implications for mainstream enterprise-architecture‘ section at the end of this post. For a quick overview, see the companion video for this post: ‘Enterprise architecture in miniature – 4: Prototypes‘ – Episode 83 in the ‘Tetradian on Architectures‘ video-playlist.)
As before, I’ll base this exploration on the CSPAR change-cycle (Context, Scope, Plan, Action, Review), mapped to an iterative version of Damien Newman’s ‘the Squiggle‘:
In terms of that sequence, the first two episodes focussed more on Context – first with a brief overview, about how and why and where to start applying whole-enterprise architecture to itself, and then some practical first steps, on values, drivers and priorities. Next, we focussed more on Scope, getting real about all of this by identifying key areas of action for the new capabilities and services needed to realise this new business role.
In this final episode (for now) in the series, we’ll explore the first stage of Plan, shifting the emphasis more towards design – a shift from Why to How. To do this, we use prototypes, along with research and raw imagination, in a Plan / Action / Review loop, to establish feasibilities and suchlike for initial ideas, aims, options, realities and real-world constraints. The explorations for Scope gave us the following focus-areas for initial assessment:
- design for change, design for re-use
- separation of concerns, separation of usages
- utilities-demand – energy, water, air
- requirements for storage and access
- overall feasibility – vehicle, cost, time, effort and more
Given that list, let’s go through this step-by-step.
First, the organisation operates within the shared-enterprise of whole-enterprise architecture.
The intended new role for the organisation – the basis for its business-transformation – is to provide the services of a mobile learning-lab, to teach and study whole-enterprise architectures, particularly for smaller organisations.
The mobile learning-lab must itself act as a live-demonstrator of the principles and practice of whole-enterprise architectures. We already have a core descriptor for those principles, from Part 2 of this series: that “Things work better when they work together, on purpose“. From that same ‘First steps’ work, we also have a core driver: a deep desire for a sense of being useful – which in turn leads to measurable real success-criteria such be that the work delivers value to others, that the work is valued by others, and that I and others enjoy what is learned, and the process of learning. I’ll need to ensure that each of these criteria weave through every part of the architecture, with evidence, tests and review-processes for each.
The same applies that swathe of values-themes – again elicited in that earlier ‘First steps’ work – such as privacy, security, safety, environment, financials, maintainability, reliability, hygiene, and adaptation and re-use. I’ll likewise need designs and tests that support all of these themes too.
For any transformation, we focus first on the most significant areas of change – particularly any potential ‘show-stoppers’ amongst those major areas of change. For a classic ‘digital-transformation’, the focus would therefore be on the respective changes in IT – or, more accurately, in the IT and on the changes in interactions between people and IT. For this ‘mobile-transformation’, though, the IT is relatively straightforward – there are a few changes, mainly in areas such as solar-controllers and power-management, but most of the technology for that is already well-known and well-understood. Instead, the major change here – the crucial enabler for the organisation’s intended enterprise, and the source of many as-yet ‘unknowns’ – is the physical vehicle and its fit-out. Hence, for this instance of ‘the architecture of the enterprise’, the vehicle – not the IT – will need to be our first area of focus here.
And whilst we’ll focus for now on the vehicle and the physical build, we must always remember that whatever we explore here, it’s always in context of the whole (which does include the IT, of course). Design draws from architecture: we need to see how those architecture-themes such as constraints, priorities and success-criteria echo down into the detail of the design.
Another core concern here is that we need to design for change, for re-use and alternative uses. We must expect change – changes of use, changes of configuration, and more – not just in the design-phase, but throughout operations too. For example, we’ll likely need to swap segments of functionality in and out as required. Yet we also want to avoid any structural changes to the vehicle: for example, the ideal is that if we start from a standard panel-van, we should be able to revert right back to the original van as and when that’s needed. And it is feasible, too: for example, there are cargo-rail kits for some vans which would enable us to mount everything in the van as removable modules.
We also need to consider the physical forces. Some of those forces are lot more extreme than we might expect: I’ve seen ‘van-life’ design described as like preparing for a hurricane or an earthquake, and that’s actually not far wrong. On the outside, wind-force at full highway-speed would be up at Category 11, ‘Violent storm’, on the standard Beaufort scale, or almost a Category 1 hurricane on the Saffir-Simpson scale – a serious challenge when mounting solar-panels and suchlike. And on the inside, the shaking-forces can provide earthquake-type stresses equivalent to level IV or V on the Mercalli scale even on ordinary roads, or up to Mercalli VII or more on the dirt-roads still common in Australia and elsewhere. Dealing with those kinds of loads will demand some solid engineering: a casual ‘throw something together and see if it works’ is not likely to work well for this…
To test the constraints, a quick assessment suggests that, for the intended purpose, the smallest feasible vehicle would be a medium-wheelbase van. (Anything much smaller than that might be able to fit a bed or a workspace, but probably not both.) For now we’ll make no assumptions about make or model – that’s a detail that can come later. We’ll note, though, that the typical outward appearance for that type of vehicle is much like the one below, with a typical internal cargo-space of around eleven feet in length, or a bit more than three metres long:
What we don’t do yet is rush out and buy one! – that would be a really expensive way to do first-stage prototypes. Eventually we’ll need to get to the real-world, but for now we can minimise the risk of expensive mistakes by working first on paper and practical models. One example of the latter is a foam-cardboard scale-model of the van interior – here shown with rear doors braced open and the internal cargo-bulkhead removed:
We can use this to explore a key design-criterion known as separation-of-concerns. Any ‘van-life’ vehicle must support a whole range of distinct uses: sit, cook, eat, sleep, move and more. In a typical smaller RV or motor-home, the uses are all mixed up together, or constrain each other: a permanent-bed leaves nowhere to sit, for example, or else a static seating-space means the bed has to be assembled and dismantled every day. But this case requires even more use-types: not just sit, cook, eat, sleep, but a swathe of business-uses too – which also each add their own demands for storage-space and more. It’s quite a challenge.
One way to resolve the challenge is actually to make it seem even harder: we apply separation-of-concerns, such that only one usage should be visible at each time – and also be able to switch easily between them. This means that we not only need the fit-out to support each function, but also to hide any functions that are not needed for each given usage.
For example, how do we solve the dilemma of the bed? At two metres long and at least a metre wide, any permanent bed would take up much of the available space; yet any typical demountable bed is not only tedious to use but often also uncomfortable as well. One option that sidesteps that dilemma is the so-called ‘Murphy-bed‘ that folds upward, against the wall, with all the bedding still attached. And if we use a whiteboard-panel as the underside of the bed, that also gives us additional functionality for the key business-usages.
So using that idea, let’s assemble a possible fit-out for the foam-cardboard model, and assess how it would work with each of the usages. For the model, we can represent larger units with glued-together stacks of the foam-cardboard. To indicate scale, each thickness of the foam-cardboard represents about four inches or ten centimetres on the real-world vehicle, whilst the walkway and the units either side of it would each represent about 18 inches or 45 centimetres wide:
This has a Murphy-bed over on the left, mounted above and hinged on a low-level storage-unit for batteries and controllers, and the galley area further forward. In the middle, there’s a set of movable seating/storage-units. On the right, there’s a mid-height sideboard / storage-unit with a fold-out desk, and a full-height storage-unit further forward. We’d also add high-level storage on both sides, though that’s not shown in the photo above.
For the consult usage, the bed-mount is in its upright position, clipped onto the upper storage on that side, and with the whiteboard in use. The movable seats are moved to the end of the space, with the bed, the galley and all other usages hidden away:
For the media usage (write, edit, and video), the bed and galley are again hidden, and the mobile storage-units lined up to make a comfortable bench-seat. The whiteboard acts as a back-rest, or green-screen backplane for video; the desk is folded out to provide a base for writing or video-editing; and there’s access to work-storage to either side or above:
For the rest/sleep usage, the bed is folded down and clipped to the sideboard. (I’ve shown a full-width bed, but a narrower single-bed bed-frame would leave a useful gap between bed and sideboard, making it easier to get up at night.) The desk is folded away, and much of the work-storage is hidden by the bed; all upper storage and clothes-storage remains accessible. The galley is hidden, and likewise the mobile seat/storage-units:
For the cook/eat usage, the bed is hidden, and the galley opened up, along with the fold-out food-preparation area. There’s access to all storage, and the cab seats rotated round to give more available space. To eat, either the desk or full table (see next example) can be used, or else use a demountable table in the galley-area:
For the entertain usage, the movable seats would be moved to each end, and the desk optionally extended further out as a full-width table. The galley could be either in-use, or again hidden away:
There are various other usages, but the above should be enough to illustrate the aim here: each unit within the fit-out supports as many usages as needed, and there’s a strict separation-of-concerns such that, as much as practicable, only one usage is active at a time.
Another key focus is an estimate of utilities-demand: power, water, fuel, data-usage and more. For example, we might estimate power-usage and need for energy-provision and energy-storage as follows:
…and likewise and estimate for water-usage and needs for water-storage:
We would also need estimates of fuel for cooking and heating – all-electric might be preferable for safety reasons, but may not be feasible in a smaller van without a second generator on the vehicle. And there’d also be data-usage, and means for data-connection – one of the few explicit IT-related items in this part of the architecture.
Next, there’s the question of storage: what is all the stuff that’s needed, and where will it go? There are a lot of different uses, hence a lot of different stuff… For example, the ‘stuff for living‘ – the items that are needed for just about any form of ‘van-life’ – we might summarise as follows:
…whereas ‘stuff for work‘ – items that are more specific to this form of ‘digital-nomad’ – we might summarise in a somewhat shorter list:
Given all of this ‘stuff’, we then need somewhere to put it – in other words, assess the storage-availability required in the vehicle:
We also need to cross-check this list against the configurations for each of the usages: we need not only to store all this stuff, but be able to access it when we need it.
And there’s another less-visible trap we need to avoid: going over weight-limits. To comply with various regulations, the total payload for the vehicle can’t weigh much more than a tonne (a thousand kilograms, or somewhat more than two thousand pounds) – and that includes not just the fit-out, but all of the ‘stuff’, and all the utilities too. For utilities, even that minimum water-supply of 60 litres equates to 60 kilograms; the batteries and their controllers will add another 60 kilograms: it adds up fast…
Which brings us to the last focus-area for now: feasibility. The key criteria are cost, time and effort. To put it at its simplest, if it can’t be done fast enough, it won’t be worth doing; and if doing the fit-out distracts too much from everything else, it also won’t be worth doing. The prototypes and other explorations we’re doing here do themselves cost a bit in time and effort – but they also help establish the feasibilities for further development. The same prototypes also help establish the feasibilities for each of the business-model options, and their linkage to Minimum Useful Product/Service (MUPS) for each phase of the build – which in turn helps to establish feasibility of income at each stage, to make the build itself more self-funding.
That’s it for this phase of the project: we lead from here towards Action, towards more-detailed planning, implementation, operations and more – yet always with the architectural vision, aims, values, constraints and suchlike in mind, every step of the way. The architecture-work we’ve done so far will help us maintain awareness of the whole-as-whole, down into every small detail of the design.
Implications for mainstream enterprise-architecture
As in the previous episode, there are some real lessons-learned here for more mainstream enterprise-architectures, operating within and for larger organisations.
Probably the single most important point is about where we start, on any move towards design. Classic IT-centric ‘enterprise’-architecture starts from content – some aspect of IT – and then builds an architecture only around those parts of the context to which that content does apply. The result is that we’re often left with glaring gaps in coverage, a swathe of arbitrary constraints on what types of transformations we can address, and a dangerous tendency towards ‘solutioneering’: “We have The Solution! – how can we force your problem to fit?” Instead, we need to turn that round the other way: that we should always begin any design from context, not content. That was the reason for all the earlier architecture-work on enterprise-vision, values, aims and the like: to establish what the actual context is, for each transformation-exercise or whatever.
What this worked-example adds to that overall principle is a more specific guideline: that we should focus first on the most significant areas of change – particularly any potential ‘show-stoppers’ amongst those major areas of change. For a so-called ‘digital-transformation’, those ‘show-stoppers’ indeed could be in some aspect of IT. But it’s just as likely to be about responses to changes in legislation or the like – such as for GDPR privacy-regulation, for example, or anti-money-laundering compliance. In another case, the ‘show-stopper’ could relate to something more specifically human – such as availability of specific skills, experience, expertise or tacit-knowledge. In yet another, the ‘show-stopper’ might be some specific type of resource – such as a stable power-supply for a mega-scale server-farm. Or – as in this example – it might relate to some other kind of technology, for which IT itself is less central. Whatever it is, we must always start from the needs of the context – not some arbitrarily pre-selected type of content.
There’s plenty more that follows from that, though most of it should be routine already – such as identifying and designing to constraints, and design-principles such as separation-of-concerns. But if we get that one wrong – starting from preselected content, rather than context – then the gains from those kinds of well-established best-practices are likely to end up kinda moot…
For the rest, well, most of it is just a reprise on what we’ve seen in earlier posts in this series – that before doing any design, we need to:
- identify the shared-enterprise
- identify the respective enterprise shared-values and drivers
- identify the organisation’s own values, drivers and success-criteria
- ensure that all of these aims, values, drivers and success-criteria are appropriately supported within every aspect of the architecture, and in every aspect of all designs derived from that architecture
- beware of any tendency towards fragmentation of the architecture
- beware of any tendency towards ‘solutioneering’
…and, as always now:
- remain aware at all times that there is much more to an enterprise-architecture than just the IT…
Leave it at that for now, I guess? Over to you for comment, anyway, if you wish.