Tom Graves / Tetradian

How do we make sense of uniqueness in enterprise-architecture? How do we support decisions at ‘business-speed’ – especially when the context is in part unique? And what architectural support do we need to provide for sensemaking and decision-making at business-speed?

In the first part of this series we looked briefly at uniqueness, and why it’s a crucial if often-forgotten aspect of enterprise-architecture.

In the second part we explored how sensemaking and decision-making change when time-available is squeezed down to business-speed, using the real-life case of US Airways Flight 1549 as a worked-example.

In the third part we reviewed some of the tactics used for sensemaking at ‘business-speed’, and why it differs from conventional ‘considered’ sensemaking.

In this final post for the series, we’ll look at how we can balance all the different sensemaking techniques in real-world business-practice, and the architectures that we’d need in place to support this.

Read more…

How do we make sense of uniqueness? How can we use uniqueness? And how do we make appropriate decisions when some or all of a context is inherently unique?

In the first post in this series, we skimmed through Max Boisot’s I-Space and its impact on sensemaking in relation to complex-adaptive-systems. I then added a bit about my personal background, and why my own work focusses much more strongly on the individual context, the individual and personal moment of action, and its expression as personal knowledge and personal skill. Finally, we saw a quick overview of why uniqueness or ‘particularity’ is important in enterprise-architectures.

In the second post in the series, we had a brief exploration of why Boisot’s I-Space and similar frameworks don’t fit well with the sensemaking-needs for unique contexts – and illustrated this point with the real-life example of Flight 1549, the so-called ‘Miracle on the Hudson’.

In this post, I want to explore the different types of sensemaking that need to happen at ‘business-speed’ – especially when we have to cope with uniqueness as well at that speed.

In the final post in this series, which will follow this one, I’ll summarise some of the issues around how to balance the sensemaking techniques at ‘business-speed’, and the architectures that we need to support such forms of sensemaking.

First, though, a couple of Tweets to illustrate why this matters:

• SAlhir: RT @DennyCoates “Ideas can be life-changing. Sometimes all you need is just one more good idea.” – Jim Rohn
• CreatvEmergence: The difference between the unknown which leads to confusion and the unknown which leads to emergence is intention with creativity

So: ideas, intention, creativity, ‘life-changing’, even – all at ‘business-speed’. Let’s get down to it?

Read more…

How do we make sense of uniqueness? How can we make sense of what’s happening at the exact moment of action?

In the previous post in this series, I looked briefly at Boisot’s I-Space – promoted by some as ‘the answer’ to everything in the information-space – and discovered that, useful though it may be for other types of sensemaking, it doesn’t really address this specific challenge of uniqueness.

[If you're interested in Boisot, I understand that Cognitive Edge have just released a selection of his blogs there as a stand-alone document - check it out, perhaps?]

I then delved into a bit of my own history to identify the key theme for me here: the interaction between the individual and the context, in the moment of enacting some form of skill. In other words, uniqueness in practice.

So why is this relevant to enterprise-architecture? The last part of that post gave a brief overview of some of the reasons why uniqueness – and the balance between sameness and uniqueness – is right at the core of business-models, business-architecture, risk/opportunity management, operational excellence and many other key concerns in enterprise-architectures and the like.

So let’s keep digging a bit deeper here, to explore what we can use for sensemaking in that context of uniqueness.

Read more…

We know how to do sensemaking in enterprise-architectures; but why do we do it? What’s the purpose? What’s the point?

As a result of various recent proddings from Bruce Waltuck and Stephen Law, amongst others, I’ve finally gotten round to taking a more than just a cursory glance at Max Boisot‘s concept of information-space, or I-Space. It’s still only been a brief exploration, I’ll admit – a handful of academic papers, and a few I-Space websites. But what I’ve learnt even from that is just how radically different from mine is the problem that I-Space aims to address, in what might otherwise seem to be much the same context – and hence why the approach I’ve been using likewise needs to be radically different too.

Anyway, a warning: this is likely to be very theory-oriented, so it’s probably only relevant if you’re involved in the underlying theory of enterprise-architectures and suchlike. It’s likely to be very long as well, though I’ll probably split it into several parts, for everyone’s sake…

Read more…

As mentioned in the previous post, one of the key characteristics of ‘crossing the chasm’ to a viable whole-of-enterprise architecture is the explicit inclusion of people. In short, we need to be able to model and map where people fit in relation to the architecture.

But there’s a catch. A big catch. People should not be ‘designed in’ to the architecture.

We can see this well in building-architecture: there, the only case where people have been literally part of the architecture is that of the anchorite in the mediaeval church. An anchorite would choose to be permanently walled into a cell that was part of the fabric of the building, to act as a spiritual anchor for the people’s faith. Somehow I don’t think we’ll be likely to find many people willing to do the same for today’s for-profit enterprises…

Yet in most building-architecture, evidently, people are everywhere. Other than in certain special-cases – the equivalent of an IT-specific ‘enterprise’-architecture, perhaps – the building and its purpose and design will centre around people, about what people do, why they do it, what the building represents to people, and so on. And the equivalent of that ‘people-centrism’ is what we need in a viable enterprise-architecture.

But if we can’t design people into the architecture itself, how do we map people within the architecture? I would suggest four key themes:

• vision and values
• relational-assets
• roles and responsibilities
• capabilities and competencies

Let’s look at each of these in some detail.

Read more…

A few days ago a young IT-architect in India, Nitin Koshy, sent me an email asking for advice on how develop a career as an enterprise-architect. A nice challenge: much appreciated!

There’s plenty of purely pragmatic advice one could give, of course, but I don’t know the Indian context that well – for example, I don’t even know if anyone’s doing TOGAF trainings there as yet, though I guess someone must be doing so by now. But I thought I would concentrate instead on the same kind of advice in one of my favourite books, William Beveridge’s The Art of Scientific Investigation:

Elaborate apparatus plays an important part in the science of to-day, but I sometimes wonder if we are not inclined to forget  that the most important instrument in research must always be the mind of man. It is true that much effort is devoted to training and equipping the scientist’s mind, but little attention is paid to the technicalities of making the best use of it.

So in the same spirit about “the technicalities of making the best use” of the architect’s mind, I suggested the following ideas, in no particular order:

IT-architecture is a cross-disciplinary specialism: the enterprise IT-architect will bridge between the various IT domains, but the focus essentially remains centred around IT alone. By contrast, to the enterprise-architect, everywhere and nowhere is ‘the centre’: he or she must be a consummate generalist, interested in everything. So I would encourage you to lift your eyes from the screen and the imaginary worlds within IT-systems, and look around you. IT-systems describe a digital world, but they are also very physical: they exist in a real world beyond data alone. A real, messy, chaotic world, where computers need to be fed power and kept cool (the two huge demands of present-day data-centres), placed somewhere safe from dust and rain and flood, with all of their cabling and other data-links protected from birds and mice and wayward excavator-operators digging up the roads. And a human world, where real people have real emotions and do the real work, and where passion for code (and, sometimes, a confused passion for ‘control’) is what creates all of this in the first place.

So get interested in everything, in anything that happens. Allow yourself an explicit time in the day – as a meditation, if you wish – in which you allow yourself to notice whatever happens around you. See the four-dimensional shapes that people make as they move down the street, the surging textures of a moving crowd. Notice the momentary sounds and individual words that appear in the midst of the noise and tumult – they may not necessarily mean anything in themselves, they just are, yet noticing them builds a habit that creates space for noticing things that do matter. Watch an individual ant choose its path across the dust; then watch the patterns that a colony of ants will make; then crosslink that to the path you can see in the lifecycle of a single data-entity, the patterns you can see emerge from the flow of data. Be interested in machines as well as IT boxes: learn how a spinning-wheel works, a loom, a sewing-machine; the four-dimensional paths and movements built into the workings of a printing-press; the amazing complexity within an ordinary-seeming office-printer to deal with the physical variation of paper moving through the feed-path, of real particles of toner moving from the cartridge and thence to the paper, all held somehow within precise positions in space and in time. Be interested especially in people: it’s so easy to see them as machines, as ‘manual processes’, extensions of your IT-systems, yet remember to see them also as strange beings with choices unique to themselves, every one of them different, passionate, frustrated, bored, somehow surviving against all the unyielding pressures of entropy. Allow the world to be strange, new, like the world of an ever-curious two-year-old; and remember to keep those images and impressions and feelings with you when you come back to the ‘real’ world of deadlines and meetings and production-schedules and impatient clients who want it all done by yesterday!

Notice your own heritage and culture: notice what is uniquely India, what it brings to the world. So much of the global perspective is dominated at present by the worldview of ‘the West’, of Europe and the US: and it is easy to miss the cultural assumptions that are embedded in technology and business-practices, many of which may not fit well with local ways of working at all. (A significant part of my work here with US-owned multinationals in Mexico has been ‘cultural translation’: US culture assumes the predominance of the individual, whereas Latin culture places far more focus on the family, the collective, leading to some serious confusions around incentive-schemes and rewards for ‘personal’ performance and the like, with impacts rippling all the way through the entire architecture of the enterprise.) Notice your own culture’s enormous strengths: its proud yet unique tradition of mathematics, for example, or its amazingly inventive ability to ‘make do’, leading to world-leading innovations such as robust, lightweight, inexpensive, highly fault-tolerant medical-diagnostic systems for use in all those myriad small villages off the main roads with erratic mains-power and even more erratic network-connections. Notice where those ideas and innovations came from in your own culture – and then find that same place within yourself.

On enterprise-architecture itself, look wider than TOGAF and the other IT-oriented frameworks, to models that encompass more of the overall enterprise. Look at FEAF, the US Federal Enterprise Architecture Framework: note the two not-quite-blank sections in the PRM (Performance Reference Model) marked ‘Human Capital’ and ‘Other Fixed Assets’, and ask yourself what should go there, to complement the [IT-specific] ‘Technology’ in the centre. Look at DoDAF, MoDAF and other defence-oriented frameworks, and ask yourself how you would bring those same ideas back into the civilian world. (TRAK, an adaptation of MoDAF for the rail-engineering requirements of London Underground, would provide some useful ideas there.) For industry-specific frameworks, see SCOR (Supply Chain Operations Reference) or the Telemanagement Forum standards for the telecoms industry: eTOM (enhanced Telecom Operations Map), NGOSS (New Generation Operation Systems and Software) and SID (Shared Information/Data). Look also at how an any enterprise-architecture is put into practice in the real world: for example, balance TOGAF with ITIL (Information Technology Infrastructure Library), to see how IT-services are enacted by IT service-management.

In all of that, I would suggest to keep remembering that enterprise-architecture literally means ‘the architecture of the enterprise’ – not merely the architecture of the enterprise-IT. The IT exists within the context and needs of the broader organisation; and the organisation exists within the context and needs of a far broader shared-enterprise. An organisation is bounded by rules, roles and responsibilities, but an enterprise is essentially a human construct, bounded by aspirations, commitments, hopes, fears. We create an enterprise-architecture for an organisation, but about that broader enterprise. And ‘quality’ in all its forms is what arises from that broader enterprise: hence all those quality-oriented issues in architecture such as reliability, efficiency, resilience, safety, sustainability, security and the like. If you remember to keep that idea of the broader enterprise in mind whilst you work on even the smallest item of code, it will help to show you what an ‘enterprise’ really is – and hence the nature of enterprise-architecture itself.

The last point, perhaps, is to respect that all of this does take time – many years, if we’re honest. But you’re already a long way down that track: after more than ten years in ‘the trade’ you will certainly have learned a great deal about the difference between academic theory and real-world practice! And remember too that every item you notice is a step along the way: we never actually ‘arrive’ as such – as we do with an academic qualification or a framework-certificate – but somehow discover one day that we’re already doing that work, and never noticed the change.

So in a sense you are already an enterprise-architect: the only difference is one of scope (beyond IT itself) and scale (beyond the business-unit, and even beyond the organisation). So enjoy! – have fun!

I hope it’s been useful, anyway – and thank you also for asking the question.

My best wishes to you and to your colleagues
- tom graves

A great discussion yesterday with Mike Turner reminded me that there are two radically different roles for enterprise-architects:

• the internal enterprise-architect
• the external enterprise-architect

They’re both focused on ‘the architecture of the enterprise’, but it’s important not to mix them up, because they require different temperaments and different approaches to business-relationships.

The internal enterprise-architect is actively responsible for the ‘enterprise DNA’ of a single organisation. They typically either report direct to the CEO (who has the ultimate authority and responsibility for that ‘DNA’, but in practice probably doesn’t have the time to do much about it), or else are attached to the CEO Office or a senior-level strategy-group.

The key point here is that, to use Kevin Smith‘s term, this enterprise-architect role acts as “the glue between strategy and execution” – which means that they need direct person-to-person relations with people at all levels and in all domains of the organisation and enterprise. Developing these relationships takes time, and a lot of time at that – often ten or more years in a typical large organisation. Hence the best people for this kind of role are those who’ve “come up through the ranks” and built a personal network on the way, or – even better – have grown up with the company, “have been in from the start” or suchlike. (The CEO can and should do the enterprise-architect role for a start-up, but once the organisation grows beyond about a dozen people the role will typically need to be part of someone else’s explicit responsibilities, and once we get past the crucial social-network boundary of Dunbar’s number – roughly a dozen-squared – it needs to be a distinct role in its own right.)

This role is about how the idea of enterprise-architecture – that “things work better when they work together, with efficiency, with elegance, on purpose, in practice” – is expressed throughout this organisation, in terms of this organisation’s business-purpose.

The external enterprise-architect (or consultant enterprise-architect) is actively responsible for promoting the ‘idea’ and practice of enterprise-architecture itself. It’s important that they maintain their independence as much as practicable, though for practical reason many will work via the auspices of a consulting-organisation of some kind. Their person-to-person relations are with other architects – again in many different domains and at all levels, but across many different organisations and enterprise-types.

Their primary role is practice-refresh for in-house enterprise-architects: they help to keep the overall architecture up-to-date on methods, practices, and frameworks, and help to lift the architecture-maturity and architecture-capability of the internal team. They also act as external peer-review, to reduce the risk of an insular and often destructive ‘groupthink’ developing within an organisation. This role too requires many years of experience, but this experience will have been gained across multiple disciplines in multiple organisations and, preferably, multiple industries.

The internal enterprise-architect deals with architecture in depth; the external enterprise-architect deals with architecture in breadth. An organisation’s architecture gains most from an appropriate balance of these two roles – not one or the other, but always some of both.

The worst possible combination of these two roles is unfortunately that which many large consultancies try to promote: full long-term control of an organisation’s enterprise-architecture by an external consultancy. An enterprise-architecture works right at the core of an organisation and enterprise: hence assigning responsibility for the organisation’s DNA to an external party is not a good idea… You Have Been Warned!

Ideafarming.

Sometimes a word will pop up out of nowhere, like the mushrooms did yesterday on the grass verge just down the road on this small suburban block.

But ‘ideafarming’ is a good way to describe the work that I do:  like a old-style farmer, planting seeds for new ideas, tending them, nurturing them, watching them grow.

Perhaps not as exciting as fishing for facts; perhaps not as challenging as herding cats; yet in its own way definitely as much hard work as either of those, and it has its own quiet pleasures too.

Different styles of ideafarming, of course. Some go for a machine-like monoculture, repeating the same ideas over and over again to reap the maximum benefit before the ground itself is exhausted – at which point an overly-artificial hydroponics-style approach may be the only option left. Others are aggressive – almost obsessive, even – in their war against the weeds: “Any idea needs to be challenged, vigorously and early … to make it more resilient”, thundered one erstwhile colleague – a tactic which seems more like ripping every tender young shoot out of the ground to check if it’s growing. My own ideafarming is probably more organic in style: watching, waiting, letting things be, letting things grow together in unexpected ways, companion-planting between disparate ideas and the like.

Some ideas ripen quickly, to give a quick harvest – but those ideas tend to be the most perishable of all, and getting them to market in time can be a chancy business. Other ideas are more predictable, perhaps with a yearly harvest – but that can mean long gaps where the work is as hard as ever but still no return in sight. Others again may take years, decades, even centuries, before they start to yield their crop – the metaphoric grapevines, hazels, chestnuts, walnuts of the ideafarmer’s harvest. They all look much the same when their first shoots first push their way out of the ground – and yet each needs nurturing in their own distinctive ways. Often the nurturing consists of deliberately ‘doing no-thing’ – which is not the same as ‘doing nothing’; and sometimes what we most need to do may make no sense at all to ‘outsiders’ – such as the paradoxical advice that “in order to remember something you never knew, first set out to forget it”.

And we’re always at the mercy of the elements, too. City-folks may see the machinery that we ideafarmers use – the mobile-phone, the library, the computer as metaphoric combine-harvester – and think that that’s what does all the work; but the reality is that those machines do nothing on their own, they help us in our work, but they don’t make the ideas grow at all. If we’re fortunate, and skilled, and careful, we may indeed at times have a bumper harvest, a glut of new ideas; but sometimes – and sometimes even for years – nothing will grow. Stuck. No matter how much we might like it to be otherwise, it’s not something we can control.

So we ideafarmers tend to be of a taciturn temperament: quiet, reflective, often rather solitary, a bit scruffy, perhaps, even a bit eccentric in our ways at times. Observant, yes – because we have to be; careful; innovative, always trying something new, yet always aware of how things work out over the longer term, looking to the future by being carefully aware of the present and the past. Passionate about what we do – as anyone can see at any conference – yet often irritable with those who get overly excited about everything: after all, there’s not much room for excitement in a working life that for the most part consists of watching, very carefully, at the way the grass grows.

And it’s a working life that never stops: get up in the morning, walk the fields, tend the fences, watch for pests and predators, for termites and ‘term-hijacks‘, for wild ideas and other weeds that will run rampant if we don’t watch out for what’s happening to our would-be harvest; a moment’s rest on the porch at sunset, perhaps, but then it’s time to settle down to get ready for yet another day. We don’t have much time for the bustle of the market: the work is calling – never stops calling – for our attention, we know we have to get back to the farm. And ideafarmers don’t take vacations as such: the ideas continue to grow whether we’re there or not, so we’re always working even when we’re not at work. We don’t have much choice about that: ideafarming isn’t a job, it’s more a way of life, a way of being. In reality, it’s not just something that we ‘do’: we’re ideafarmers because that’s who we are.

Ideafarming. A strange job, but someone’s gotta do it, I guess?

Everyday Enterprise Architecture, the latest book in my Tetradian Enterprise Architecture series, is now available on Amazon:

• ‘Everyday Enterprise Architecture‘ on Amazon.com
• ‘Everyday Enterprise Architecture‘ on Amazon.co.uk

Note that Amazon have an unfortunate habit of listing print-on-demand books as ‘out of stock’: all that it means is that it takes at most one extra day for delivery.

The publisher-blurb is as follows:

All of architecture comes down to one simple idea: things work better when they work together, with clarity, with elegance, on purpose. Yet how do we express that ‘one idea’ in practice, within our organisations? With what results, and for what business-value? This book describes the down-to-earth detail of everyday enterprise architecture, to show what architects actually do to deliver value fast, across the entire enterprise.

Working step by step through a real ten-day architecture-project, this book explores the activities that underpin sensemaking, strategy, structures and solutions in the real-time turmoil of an enterprise-architect’s everyday work.

Topics covered include:

• • how to use enterprise-architecture to tackle executive-level business-problems
  • how to develop an agile architecture practice that can keep pace with the real-time pressures of the real business world
  • how to identify the business-reasons and business-value for each activity
  • how to thrive on the inherent uncertainties of the architecture process
  • how to use context-space maps to guide sensemaking and solution-design
  • how to apply architecture ideas and activities to describe what actually happens in a real enterprise-architecture project
  • how to enhance architectural skills, judgement and awareness, for continuous improvement across the enterprise and in the architecture itself

If you want your enterprise to flourish and prosper in the midst of relentless change, this is one book you’ll definitely need.

The book describes the actual thinking-processes and business-activities that typify real architecture-work at an enterprise-wide scope and scale. The structure of the book is a walk-through of a simultaneous pair of architecture projects, using an agile-style adaptation of the well-known TOGAF Architectural Development Method. Both of the projects need to be delivered in parallel, and fully completed within a ten-day period. One of the parallel projects focusses on ‘the architecture of architecture’; the other – adapted from real whole-of-enterprise architecture-consultancy assignments – tackles a serious business-strategy problem for a fictional bank.

The book also introduces a new sensemaking technique for enterprise-architectures, known as ‘context-space mapping’. The technique draws on systems-theory and complexity-theory to enable a much richer view of the architecture context, yet still deliver actionable results in tune with the timescales of the real business world.

The book-cover includes an illustration from the Dover Collection, indicating the kind of stress under which most enterprise-architects work! The aim is that the book should help to ease some of the overload, and make it easier to describe to others what it is that enterprise-architects actually do.

At present you can also download the full ebook version for free from the Tetradian Books website; note that this offer will only be available for a few more days, after which the the full ebook will be replaced by a  ’sample’ edition, containing contents and sample-chapters only.

(This is part of an ongoing series that explores alternate uses of a generic conceptual categorisation originally described in the well-known Cynefin diagram. This discussion is not about the formal Cynefin Framework; for details on the definition and use of the Cynefin framework proper, please contact Dave Snowden at Cognitive Edge. The term ‘beyond-Cynefin’ is here used solely as a placeholder to indicate this separation of interests.)

Here’s another collection of ‘Cynefin-like’ cross-maps that I’ve found useful for sensemaking in enterprise-architecture and related work:

• ISO-9000 quality-model
• Skill-levels
• Automated versus manual processes
• Asset-types
• Data, information, knowledge, wisdom

More details after the ‘Read more…’ link.

Read more…