EA in miniature – Part 2: First steps

What does enterprise-architecture look like 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: so how do I position myself within that enterprise? – what parts do I play, and not-play? What is my business in that enterprise? – my business-model, my operating-model and suchlike? And as my work shifts towards a more public phase, a more active promoting of the use and value of tools and techniques for whole-enterprise architectures, how do I adapt my business to those changes? The issues and concerns here are the same as in enterprise-architectures for larger organisations – just a fair bit more extreme, and a lot more personal…

(See the section ‘Implications for mainstream enterprise-architecture’, at the end of this post, to see how the principles and learnings at this scale can apply back in the more typical scales for mid- to larger-size organisations.)

In the previous episode, we looked at an overview of what this series is about: the core theme of applying whole-enterprise architecture to itself; a brief exploration of where to start; and an explanation of why, for whole-enterprise-architecture, we must treat IT as just one amongst many domains of interest – that unlike most current mainstream ‘enterprise’-architecture, we don’t assume that IT is inherently more important than everything else.

For this part of the series, we’ll explore some first steps: develop an understanding of the broader enterprise and its values and drivers, and then identify some initial priorities for further exploration.

(See also the companion video for this post: ‘Enterprise architecture in miniature – 2: First steps – Episode 81, Tetradian on Architectures‘.)

A key theme in the previous post is that I’m exploring a major change in my own business. Still the same enterprise of whole-enterprise architectures, but positioning myself differently: moving from ‘maker of tools for change‘, towards ‘teacher/student of practical use of tools-for-change‘ – particularly with small-businesses and social-enterprises.

In turn, that new positioning will call for some big shifts in how and where I work. The ‘maker of tools for change’ role was and is largely static, working closely with a small number of collaborators, such as my indefatigable, ever-inventive designer Joseph Chittenden, and the tester-team and review-team amongst our much-valued supporters on Patreon. This new role, though, will also need to be much more mobile – a literal ‘outreach’, in-person rather than primarily online, and anywhere across a whole region, rather than set only in one physical location. Kind of ‘enterprise-architecture meets digital-nomad’, if you like.

Everything else in that ‘repositioning’ within the enterprise remains much the same as before. For example, I’d use much the same ‘tools-inventory‘ that I already have – just updated to reflect all the work we’ve been doing for the past couple of years or so on making them more accessible and more usable for a more everyday user-base. And I’d also continue my current work of writing and making videos and the like, again using the same methods and software-tools as at present. In effect, the only part of the positioning that’s new and different – that’d need new capabilities, new services and so on – is the ‘digital-nomad’ bit.

Yet although the ‘digital-nomad’ bit is new, and hence needs much of the attention here, we always maintain awareness of the whole-as-whole – that’s a fundamental for all uses of whole-enterprise architecture. Part of the reason for this is that any change can ripple out to almost anywhere across the organisation and enterprise – which means that, for method, we’ll need to support an iterative version of Damien Newman’s ‘the Squiggle‘:

We need to expect change in ideas and more – design for change, rather than try to rush towards a single fixed ‘The Answer’. And  useful insights can arise at any moment, from anywhere – so it’s wise to keep a notebook or two on hand, at all times, to help capture those ideas and insights before they disappear:

As mentioned in the previous post, for method here I’m using our Change-mapping approach, with its sequence of Context, Scope, Plan, Action and Review (CSPAR). We can overlay that sequence onto the iterative-Squiggle as follows:

Which means that we need to start this first iteration here at Context – about the broader enterprise whose needs this one-person organisation will serve. Once we understand the nature of that broader enterprise, we can explore the organisation’s options for positioning itself within that enterprise – but first we need to understand what that enterprise is.

And to identify the enterprise, look for its story – the vision, values, principles and other shared-themes of the ‘storyworld’ that bring together all of the players into that enterprise as a shared-story.

For this, we could summarise the vision for the shared-enterprise as ‘Make enterprises more effective‘ – the intended outcome expressed in the tagline ‘Things work better when they work together, on purpose‘. I’ve written a fair bit on these themes already, such as in these posts:

• ‘Enterprise effectiveness‘ – on why the term ‘enterprise-effectiveness’
• ‘Effectiveness for enterprise-effectiveness‘ – on the context for ‘enterprise-effectiveness’
• ‘A tagline for enterprise-effectiveness‘ – on practical implications of the tagline ‘Things work better when they work together, on purpose’
• ‘On effectiveness, solutions and story‘ – on finding an effective balance between solutions and story
• ‘Building effectiveness in a small business‘ – on enterprise-effectiveness as applied to small-businesses

…but here the aim is to put all of this into practice, as a direct service into that shared-enterprise. Enterprise-effectiveness applied to enterprise-effectiveness, and whole-enterprise architecture applied to whole-enterprise architecture, via a small-business in support of other small-businesses. Kinda recursive, really. But it works.

Given that phrase of ‘Make enterprises more effective’ as the vision for the overall enterprise, where do I then position my own organisation within that shared-story?

This might seem just like a marketing exercise, but it’s actually quite a bit more than that. Yes, it’s about marketing-position: but it’s also about how the offers, promises and commitments made to the broader shared-enterprise must then echo throughout every aspect of the organisation itself. Hence the implied values from the enterprise-story would include default effectiveness-themes such as reliability, efficiency, alignment to purpose, the ‘elegance’ of human-factors and self-adaptation, and integration across the whole: in which case, how are each of these themes addressed in every aspect of this business? That’s the real challenge here: again, it’s not ‘just a marketing-exercise’.

Then there’s how my own choices interact with those of the shared-enterprise. The role for my one-person organisation is clear: as above, a mix of ‘maker of tools for change’ and ‘teacher/student of practical use of tools for change’, in context of this broader enterprise of the use and value of the broader shared-enterprise of whole-enterprise architectures.

For me, what matters most in any work I do is a sense of being useful: hence, for that given role, some real success-criteria for me here would 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. In which case, I’ll need to ensure that each of these criteria weave through every part of the architecture, that I capture evidence about these themes, and that I have appropriate tests and review-processes to use them for learning and continual-improvement.

The point, again, is that everything depends on everything else – including these value-themes. In fact, that’s also a key distinction between architecture and design: design focusses on how to implement appropriately all of the themes and requirements and suchlike for each given part of the context, whereas the role of architecture is to ensure that everything works together with everything else, as a unified whole.

Another key part of these first steps is to identify all of the scopes of concern. The one significant change in capabilities – and hence a new area of concern – is in making the business mobile: the ‘digital-nomad’ bit. For this alone, there are many different scopes I’ll need to consider: scopes of function such as mobility, power, heat, light, air-flow, water, communications, access, storage and more, and scopes of use such as work, rest, play, move and suchlike.

And there are also a whole swathe of values-themes that’ll need extra emphasis in that ‘making the business mobile’ area-of-concern – such as privacy, security, safety, environment, financials, maintainability, reliability, hygiene, and adaptation and re-use. Again, I’ll need designs and tests that support all of these themes.

A key aim is that both the business and the mobile learning-lab itself will act as a live-demonstrator for the principles and practice of whole-enterprise-architectures, for any scope and scale. I need to be able not just to talk about this stuff, but to live it too, connecting architecture to design to operations to continuous-learning. To be honest, I know that that’s not going to be easy for a theory-oriented person like me… – so the more that the vehicle and the organisation-of-the-organisation can help rather than hinder me in that, the better it’ll be. Hence, again, why this phase of planning is so important, to highlight hidden gaps and hidden assumptions that need to be addressed.

This in turn points to a maze of constraints – both chosen and imposed by by Reality Department – all of which interact in often bewilderingly-complex ways, even at this small scale of operation. (Indeed, some of these constraints and constraint-interactions are probably easier to resolve at a larger scale.) To resolve these, I need to make best use of all the choices and trade-offs across the whole – yet first I need to understand what those constraints, choices and trade-offs are. I need to start that process of exploration right up at this early phase, before I go into any kind of deep-dive for detailed design.

That’s probably enough for now – for the first steps to find and work with the story of and for this one-person organisation and its enterprise. Yet it’s all still been a bit abstract so far: so in the next step, we’ll need to make a start towards making it real. That’s what we’ll do in the next episode in this series.

Implications for mainstream enterprise-architecture

There are some real lessons-learned here for more mainstream enterprise-architectures, operating within and for a more mid-size to larger organisation.

Probably the key point is almost all of this still remains absent from mainstream ‘enterprise’-architecture. And yet it needs to be there, because it is literally the anchor for the entire architecture. If we want to understand why enterprise-architectures fail to deliver their desired outcomes, this absence is one of the most common causes of that failure. In the mainstream ‘EA’ frameworks, it often seems to be assumed that this kind of high-level exploration is Somebody Else’s Problem. But the reality is that enterprise-architects are the respective Somebody Else: so if they/we don’t do it, no-one will – which means that without it, the architecture will have no actual anchor. We need to do this work…

There’s a straightforward step-by-step sequence for this:

— Identify the shared-enterprise in which the organisation has or would choose to position itself.

Remember, this is a scope that is much broader than the organisation itself: ‘organisation’ and ‘enterprise’ have significantly different meanings here, with ‘organisation’ as ‘How’ and ‘enterprise’ as ‘Why’. For this purpose, it’s useful to extend our view of the respective shared-enterprise to at least three steps ‘outward’ from the organisation itself – transaction-partners, direct-interactions with the broader market, and indirect-interactions with this extended shared-enterprise:

Then look for unifying factors across all of this context – in effect, the enterprise-story or ‘storyworld’. A typical way to do this is to identify three themes that link together:

• What: a focus or type of ‘thing’ that everyone is concerned about
• How: what is being done to that ‘What’, in various ways, across all of the shared-enterprise
• Why: the reason that applying the ‘How’ to the ‘What’ is considered important to everyone in the shared-enterprise

A practical real-world example of this is the tagline for the TED conferences: ‘ideas worth spreading’ – ‘ideas‘ (What), ‘worth‘ (Why), ‘spreading‘ (How).

Then, from this:

— Identify the respective enterprise-values and drivers from which values-tests and success-criteria can be derived.

Remember that these apply to every player in the shared-enterprise – not solely our own organisation. (We’ll come back to that point in a moment.)

We do this by exploring the implications of that storyworld-definition – perhaps particularly the ‘Why’ element, and deriving values from that. To use the same TED example, we’d look at criteria for which ideas to spread – which ideas are worth spreading – and the values we use to determine what is or is-not worth spreading. We’d also look at signals and metrics to assess how well we’ve spread those ideas – what value those ideas have delivered to the wider shared-enterprise, and the effectiveness of the processes by which we’ve spread them. And we’d also ensure that we have tests and learning-processes that support error-capture and continual-improvement on all of those themes.

The reason why this is important is that these are the anchors for trust across the entirety of the shared-enterprise: and trust is the key to the enterprise. Without trust, the enterprise dies, and with it the organisation’s business too: it’s that important… Which is why we definitely need to support it throughout every aspect of our architectures.

From there, we’d switch the view the other way round, looking at how our organisation connects with that shared-enterprise:

— Identify the organisation’s own values, drivers and success-criteria – what the organisation needs, for it to be worthwhile to connect with this shared-enterprise.

This is essentially the same as just above, but this time it is primarily about the organisation and its choices. Note, though, that it’s still always in context of the shared-enterprise – and not solely about the organisation, without regard to anyone else. The value-systems need to connect – and connect well, in a way that does support the shared-enterprise – otherwise things risk getting seriously messy, in either or both directions. One useful crosscheck here, for example, is to reframe ‘Terms and Conditions’ as ‘Trust and Commitments’: be explicit about what the organisation needs from others, but also ensure that this does align with the expectations and values of the broader shared-enterprise.

Then, given all of the above:

— Ensure that these values, drivers and success-criteria are appropriately supported within every aspect of the architecture, and onward into all of the organisation’s structures, processes and operations.

In short, we need to use those values and suchlike to connect all of the organisation’s activities with all of the respective points in its transaction-space, market-space and broader shared-enterprise – all the way from ‘outside-out’ to ‘inside-in’:

To my knowledge, none of the existing mainstream ‘EA’-frameworks support this properly, if at all. At best, some will support some aspects of this, though often for only an incomplete and arbitrarily-selected subset of the overall scope. Yet for a viable enterprise-architecture, we must cover the whole scope – because that’s the only way that we can anchor the architecture into the real world of the enterprise.