EA in miniature – Part 3: Getting real

At present, enterprise-architecture is most often used for mid- to larger-sized organisations. Yet what can we learn by applying the same methods at the smallest scale – a one-person organisation and their enterprise?

For this series, I’m using my own case as a worked-example. My work is in the enterprise of enterprise-architecture itself – or whole-enterprise architecture, to be more precise, the literal ‘the architecture of the enterprise‘. I’m exploring how to reposition myself and my business within that broader shared-enterprise, transitioning to a much more in-person role where I’ll be moving around a lot from place to place: ‘enterprise-architect as digital-nomad’. To do this will demand a fundamental shift in the way I work: for me, a ‘mobile-transformation’, in much the same sense as the term ‘digital-transformation’ is bandied around elsewhere. So in practice, the issues and concerns are essentially the same as in enterprise-architectures for larger organisations – though often a lot more personal here, and often a lot more intense, too…

(For more on how the principles and learnings at this scale can apply back in the more typical scales for mid- to larger-size organisations, see the ‘Implications for mainstream enterprise-architecture‘ section at the end of this post. And perhaps see also the companion video for this post: ‘Enterprise architecture in miniature – 3: Getting real‘ – Episode 82 in the ‘Tetradian on Architectures‘ video-playlist.)

In the first episode in this series, we had a brief overview for this series: about applying whole-enterprise architecture to itself, and a brief explanation of where and why to start. And in the previous episode, we explored some practical first steps to develop an understanding of the broader enterprise and its values and drivers, and some priorities for further exploration. For this episode, we begin getting real about all of this, by identifying key scopes for action, to create or change the capabilities and services that would make this new business role a reality.

As before, I’ll base this exploration on the CSPAR change-cycle (Context, Scope, Plan, Action, Review), mapped to that iterative version of Damien Newman’s ‘the Squiggle‘:

In terms of that sequence, for the previous episode we explored the Context for this business-transformation, heading towards Scope. In this part of the series, we move on to explore more about Scope (or Scopes, rather), in turn heading towards Plan.

The ‘obvious’ option here is to rush straight into planning, particularly about a van or other vehicle in which to do the new business. Yet that’d be just as much of a mistake as the instant leap to ‘solutions’ that’s so common in the usual IT-centric ‘enterprise’-architecture: so for here, as there, I need to slow down a bit, and explore what the real scopes for action actually are – and how to anchor each of them back to the initial Context. A brief period of quieter contemplation, then, would yield the following questions:

• What are the typical best practices for an on-the-road business-life, that have been identified by other ‘digital-nomads’?
• What business-model would I need, to make this business both useful (a key success-criterion from the Context!) and financially-viable?
• What operating-model would I need, to make this business operationally-viable?
• What are the development-tasks for each element – the vehicle (in several senses), the ‘thinking-tools’ for the business-model, and more?

So for this next step, I need to do a brief dive into each of these questions, and the scopes-for-action that each imply.

— Scope #1: Best-practice for digital-nomads

Searching around for existing best-practices for this type of enterprise, the closest equivalent that I could find was the ‘van-life’ communities. Those do tend to focus more on the needs of glamorous outdoorsy 20-something couples – none of which terms would apply to my own case, of course. Of the more generic ‘best-practice’ themes, though, seven points seem to stand out most:

1. Define and run a viable business-model for the personal-enterprise. No question that that’s needed – more on that in Scope #2 below.
2. Document and promote via blogs, videos and more. To a significant extent, this is what I already do: the only difference will be in adapting that to operate more on the road – for which the most likely challenge will be in finding and maintaining internet-access, particularly for the larger video-files.
3. Maintain a financial-reserve. This is mainly about breakdowns and other operational emergencies rather than initial capital – and yes, I’m already addressing that, though I don’t need to cover the details here.
4. Do live experience-testing. By this they mean a kind of ‘try before buy’ – a definite need for realism in what running a business on the road actually entails. I’ve done aspects of this life before – including a short stint or two of van-life, and a six-week trip by motorcycle across the US, coast-to-coast and back again – so I do have some first-hand experience of what it entails. Right now, my current family-commitments for eldercare do kinda preclude anything more than a day-trip away from home – but yeah, this could be a show-stopper if I don’t get it right, so it’s something I need to test as soon as I can.
5. Learn how to use all equipment for the business-model. This is key for all the outward-facing parts of the business-model. Most of it I know and do already – but I do want to up my game on the video side, with interviews, drone-shots and suchlike, so there’s a fair bit I’ll need to learn there.
6. Learn how to maintain vehicle-utilities. In effect, this is the inward-facing parts of the business-model. Again, I do know much of this already: the one known challenge will be the electrical-system – particularly the solar-power setup I’ll likely need for this.
7. Learn how to maintain the vehicle itself. This is essential: without this, I not only would have no mobility, but also no access to my home-from-home while the vehicle is stuck in a repair-bay. I’m not a complete novice on this – my many years of experience with unreliable motorcycles would likely come in handy here – but a good toolkit, test-gear and the respective Haynes Manual will no doubt become essential assets on the road.

A fair bit to do on that, then – though some of it will have to wait until I have an actual vehicle to experiment upon.

— Scope #2: Identify potential business-models

Perhaps a key point here is that it’s not just a single business-model that I’ll need, but several of them, all interweaving with each other. There may well be some real architecture-challenges in the ways that they interconnect with each other, and how they share the same capabilities.

An obvious first tool to use for this would be Alex Osterwalder’s Business Model Canvas. The most central of these business-models – probably the key revenue-earner – would be that for the teach/consult role, with delivery both in-person, and either direct or indirect online:

There’s the video component – unlikely to be much of a revenue-earner at first, though key to bringing people to other revenue-sources such as crowdfunding via Patreon and the like:

And there’s the pro-bono consulting thread to the business model – where ‘revenue’ is more in terms of reputation and research-material:

There are several other themes within the overall business-model, such as sales of books and ebooks, and consumables for tools-use and the like, but I won’t cover those here – the principles involved should be clear enough from the above, I think?

The one further key task here would be to shift from a narrower focus on business-architecture to the full scope of enterprise-architecture, such as by crossmapping from Business Model Canvas to the service-oriented Enterprise Canvas:

This would allow me to map out all of the services and service-interactions that would be needed to make the business-models work.

One example business-offer for the ‘teach/consult’ context might be “Come in with a business-idea, leave with an initial plan for action” – in other words, tackle the architecture part of what’s needed before developing a conventional business-plan. Tools from my existing tools-inventory that I might use for that offer would typically include SCORE, to map out strategic options and choices:

…the Holomap, to map out the organisation’s stakeholders within its enterprise:

…the Enterprise Canvas tool-suite, to map out the organisation’s services and service-relations:

…and the Service-Cycle, to map out service-interactions, and the means needed there to build and maintain trust:

From previous experience on using these tools to reframe business-models, I should be able to do all of this in perhaps one to two hours – delivering real, usable outcomes for the respective organisation.

— Scope #3: Identify operating-model

The emphasis here would be on support-services, on everything needed to support enterprise effectiveness. There’d be a lot of detail here, crosslinking across all of the capabilities and services needed to support each of the business-models and their interlinks. I would probably use the service-oriented Enterprise Canvas suite to model all of this – including support-services for all of the value-themes identified in the previous post in this series:

There’s a lot of work to do on this, though most of it would happen more in the Plan stage. What we mainly need to here is to acknowledge that this work does need to be done – that, both architecturally and in practice, a business-model only becomes feasible and viable when it’s matched by the respective real-world operating-model.

— Scope #4: Identify development-tasks

The last scope, for now, is to map out the development-sequence. There is at least one more scope we’ll need to address – the phased MUPS (Minimum Useful Product/Service) sets, that will ensure there’s enough income during development that the project can pay its own way at all stages. Much of that, though, is dependent on the development-sequence itself, so we’ll leave it out of the picture for now. (But not forget it! – it’s important! Just parked for now.)

The development-tasks split into two main sections: plan and develop ‘thinking-tools’ for each part of the teach/consult business-model; and plan the acquisition and build-sequence for the literal vehicle that will enable the ‘mobile-transformation’.

The first of these task-sets – tools-development – is already well under way: see the Patreon page for more on that. Probably too many strands to it, with several books and even some games-development going on at present: I’ll need to trim that back to a smaller subset that can be available straight away for the earlier MUPS stages, and keep the rest going on in the background.

For the other main task-set – the build-sequence – there’s not that much that we can do right now in terms of physical action: there’s a certain amount of ‘stuck in limbo’ whilst other key factors are resolved. (To give some idea idea, I don’t yet know even which country I’ll be doing this in…) Yet there’s a lot that I can still do right now in terms of sorting out design-constraints, preliminary models and concept-prototypes – enough to test and crosscheck the timings for all of the other strands in this transformation-story. That’s what I’ll use as the focus for the next and final (for now!) episode in this series.

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 a more mid-size to larger organisation.

For me, the first and perhaps most important lesson is that, for this early stage of architecture, we use exactly the same tools as those for larger-organisations’ architectures. And whilst at the more detail-oriented layers we’ll use specific tools for specific scopes, the core methods for architecture are always the same, regardless of scope or scale.

(In that sense, Zachman’s oft-repeated adage that ‘architecture is architecture is architecture’ is sort-of correct, in that architecture itself is indeed independent of scale. Where he went wrong – very wrong – was in arbitrarily constraining the scope to information-systems, yet still calling it ‘enterprise-architecture’: a scope-error or ‘term-hijack’ that has crippled enterprise-architecture for decades. The reality is that whilst the tools we use for architecture-development will often depend on scope, the underlying metamethods via which we select those tools must always be exactly the same.)

Next is a key point about architecture versus design. Design drives us downward into the detail – which we need if we’re to get things to work:

But the catch, if we’re not careful, is that an over-focus on design can lead to fragmentation – where the implementations for each scope work well in their own terms, but don’t connect well across the whole. This risk can become extreme if we arbitrarily focus on one scope and ignore the others – which is exactly what happens with the endemic IT-centrism of mainstream ‘enterprise’-architecture.

To counter that risk, we must balance design with architecture, to ensure that all the elements connect appropriately with each other at each ‘horizontal’ level, as well as back ‘upward’ to the initial intent:

To do this, we need an architecture that views all scopes and domains as ‘equal citizens’ – and, again, not arbitrarily privileging any domain over any other. In any major change or transformation, it’s all too easy to focus in on the main enabler – the IT in digital-transformation, or the physical vehicle in this example – and then forget or ignore everything else. But we must remember that, important as it is, the enabler is always in context of the whole, and not ‘a thing apart’ – otherwise our architecture will fail, often in ‘unexpected’ ways.

Another lesson is a reminder that a key role of architecture is to slow things down a bit, to prevent the usual headlong rush into ‘solutioneering’, and instead allow enough time to establish what the concerns for action really are. A classic description of that would be ensuring that that we not only do things right, we also ensure that we do the right things – and even that small shift can make a huge difference to the effectiveness of any change.

And a final lesson, for now, is our regular reminder that enterprise-architecture is always about much more than just IT. In this case here, we’re dealing with a ‘mobile-transformation’ rather than a ‘digital-transformation’, hence the emphasis is, necessarily, more on the physical vehicle than on any IT. Okay, yes, there’s definitely IT involved in key places here, no doubt about that – but it’s not the sole centre of attention. In a different type of transformation, the core technology could be different again: new materials such as graphene, for example. Or it might not be technology at all: think of the impact of regulatory change such as GDPR, or political or economic change such as treaties or tariffs.

Anyway, let’s leave it that for now. In the next and final episode in this series, we’ll start moving down towards more-detailed design – towards real-world plans for change, to make this ‘mobile-transformation’ real.