Another week, another twittering of Tweets and other connective coincidences of the … oh, whatever you want to call it. Usual categories, usual possibly-useful items, usual ‘Read more…’ link:
I fear I’ve overdone it this week – almost twice as many as usual. Still, that’s what I collected as the week’s Tweets and links, so here y’is, y’all. Usual categories, after the usual ‘Read more…’ link.
Been having a fairly intense (but good 
) discussion on the LinkedIn Enterprise Architecture group, about standard economics and its impact on enterprise architecture. This is one of the many side-threads popping up off Kevin Smith’s now long-running discussion on “EA is not the glue between IT and ‘The Business’, EA is the glue between strategy and execution”. I don’t know whether this set of posts from various participants will make much sense to anyone else, but it seems worthwhile to post it where others can see it if they wish.
(Note that I’ve done a small amount of editing of the original posts by trimming and snipping ['...'] and, in one case, concatenating posts from the same person. I believe I’ve kept the sense intact in each case, but if not, please let me know straight away? Thanks.)
For me, in this case, the start-point was a post by Harold ‘Hal’ Stull:
When in doubt I always think Econ 101. An organization manages three resources (capital, labor, and material) to produce a product. If a customer pays more for the product more than the value of the resources consumed, the company shows a profit for its risk and will continue operating. As an architect of any kind, I have to discover the “Who, what, when, how, where, and why” of the client’s operation and add something that may possibly increase the perceived value of the product to his customer or reduce the resources needed to produce it.
I also try to stay away from absolutes: Truth, Best, Optimum, Consistent, etc. I can do a whole lot with organizational and interface symantics. I would never say “ontology” in front of a client, but being able to work with higher abstractions helps me choose and squeeze value from tool kits. (But I see there is another thread for that topic).
As you’d probably guess, given some of the other posts on this weblog (such as ‘Economics: the worst term-hijack ever?’), I kind of jumped at Hal’s comment about ”When in doubt I always think Econ 101.”:
Hmm. That assumes that ‘Econ 101′ makes sense and works in the real world, which it doesn’t. That’s the problem.
You say: “An organization manages three resources (capital, labor, and material) to produce a product.”
The answer would be “Sort-of…”. More accurately, Econ 101 treats all of those items (including non-financial capital, such as conceptual and/or social capital) as ‘possessable objects’ that are the ‘property’ or ‘possession’ of an individual or of an organisation-as-corporate-person. Unfortunately this would take a long post to explain, but in essence the ‘possession’-based concept of economics is a parasitic overlay on the actual economy, which operates on mutual-responsibility rather than possession. The quickest summary is that Econ 101 is inherently dysfunctional and inherently unsustainable: so if we’re to build an enterprise-architecture that will work for an organisation, we need to focus on the responsibility-based economy behind the possession-based delusions of Econ 101, and not allow ourselves to be distracted by those delusions.
To give one very quick example, most conventional ‘business-models’ that I’ve seen assume a very simple Econ 101 market-sequence of:
attention (via advertising) > transaction (via sales) > profit
For enterprise-architecture, we need to deal with a much broader range (e.g. including non-active stakeholders [e.g. government, community, non-clients] and also anti-clients and others who are active participants but who are not involved in sales-transactions), and a much more complex market-sequence, such as:
reputation > trust > respect > attention > conversation > relationship > transaction [ > profit] > reputation > …
We also need to understand that ‘the enterprise’ is not the same as ‘the organisation’: an organisation is bounded by rules, roles and responsibilities (e.g. legal responsibilities), whereas an enterprise is bounded by vision, values and commitments (see my presentation ‘What is an enterprise?‘)
True, an organisation is a type of enterprise, but for most enterprise-architecture the relevant enterprise is typically at least three steps larger in scope than that of the organisation in scope. (We develop an architecture about an enterprise for an organisation.)
Using the assumptions of Econ 101 will guarantee that we will deliver an ‘enterprise’-architecture that will fail in the longer term. To build an architecture that works, we must think wider than that.
Another week’s worth of Tweets and links – rather more than usual, this time. Same categories as usual, though, following the usual ‘More info…’ link:
Another slidedeck that I should have uploaded to Slideshare ages ago: a quick (8-slide) answer to the question ’What is effectiveness?‘.
Understanding overall effectiveness is a core concern for enterprise-architectures, and for all of its subsidiary domain-architectures within the enterprise. The key idea here is that there are five distinct dimensions to effectiveness:
Businesses tend to focus obsessively on efficiency, almost to the exclusion of everything else; but we won’t achieve effectiveness overall unless we rotate our attention continuously across all of those dimensions, in a consistent and balanced way.
Here it is, anyway: another one to Share and Enjoy?
Finally got round to uploading to Slideshare my old (2006) slidedeck ‘Introduction to SCORE‘.
SCORE (Strengths, Challenges, Opportunities, Responses, Effectiveness) is a kind of ‘upgrade’ to the good ol’ SWOT strategy-assessment framework.
I developed SCORE perhaps a decade ago when I got fed up of the limitations of SWOT, especially in enterprise-architecture assessment. There are a few minor-yet-significant changes to the language, but the main change is addition of a new focus on impacts on overall effectiveness, and the explicit search for usable metrics. I’ve also reworked the method so that it’s used in an iterative, re-entrant way rather than solely as a ‘one-shot’ checklist.
The slidedeck includes a worked-example, based on a real project that we did for a utilities company several years ago.
Here it is, anyway: Share and Enjoy?
One of the comments on the previous post on the unacknowledged risks of ’cooperative IT’ triggered off an essay-length response that really deserves its own post. So here it is.
The comment that started it off was from Ric Phillips. (I’ve trimmed it slightly, but you can see the original here.)
The innovations that led to mini-computers led to the increasing importance of information processing based on the technology’s ability to capture and model transactions (atomistic events). It really did change the nature of work and organisations and made a new kind of information available.
It wasn’t really the advent of PCs that changed things. If the information about the world that could be stored in them and used had not changed radically they would have simply replaced the niche occupied by terminals. But they allowed people to simulate sheets of paper and type writers. And spreadsheets – which were existed prior to software and were done on very large sheets of paper. Later came sound files, photographs, building designs, industrial machinery, complex electronics (like audio mixing decks) and a thousand other things that are now simulated in software.
In this wave computers became personal productivity tools. The changes to how personal productivity expressed itself in our lives when assisted by the new ‘virtual’ things PCs could provide is what changed our jobs, our professions and be extension our lives.
The internet started out as an extension of publication and communications models that already existed. But (in this case much more slowly that in previous transformations) our activity on the internet started to capture large amounts of information that previously wasn’t subject to computation – social information, information about opinions, subjective value, and what we might call (tentatively) knowledge.
There are intersecting trends (consumerisation for example). But mobile computing, ubiquitous data, web 2.0 and so on are all converging to create a new domain of information – information that allows us to model and manipulate in computers new and extremely complex things. Once again this will transform organisations. But this time maybe even whole societies.
I don’t see this as an impending disaster. Our world is changing again. As a strategic profession EAs need to get their heads around this. We are leaving the era of ‘information processing’ and ‘ICT’ and entering the era of social computing and Knowledge Technology.
Reading it again, I now realise that this critique has completely missed the point: all it’s doing is extolling the virtues of each of the transformations in technology, yet seemingly ignoring any possibility that there might also be vices associated with those virtues. Yes, each of those transformations are real and valuable to some context, and that is indeed a key driver for change. Yet the change itself is not the risk, and neither is the technology: it is the dependence on that technology that creates the risk.
So, as I put it in my response, I strongly agree that “mobile computing, ubiquitous data, web 2.0 and so on” are not in themselves an impending disaster. The same applies to their initial impact on organisations and “maybe even whole communities” – in general I see those impacts as desirable, even if certainly not something we can ‘control’.
What does worry me is what happens next. As an EA I’ve spent many months at clients tracking down all those small private-to-a-workgroup spreadsheets and databases and log-files and the like that were a) business-critical and b) unmaintained, undocumented, not backed up, inherently fragile [such as trying to use MS Access as a multi-user database, which it was never designed to do], unregistered, and in many other ways a real business risk. Whenever some key person changed jobs, or a single hard-drive failed, or a sysadmin triggered an automated application-upgrade, or any other of a myriad of seeming-trivial events, that business-unit would literally lose that part of its mind – and an entire business-process, affecting an entire cross-functional workstream, would grind to a halt until someone could work out what had gone missing and how to set up yet another kludged workaround.
When the business-application is non-critical, kludges usually don’t matter: it’s how people learn, it helps get things done, and it’s exactly what ’shadow-IT’ is for. The new mobile technologies and the like are brilliant for this – just as spreadsheets and single-user databases were (and still are). Everything’s fine as long as they’re essentially used in the same way as Lego bricks or a Meccano set or the like – a ’serious toy’ that can be used to knock out a quick prototype to test out an idea, or perhaps even to keep around as a vaguely-useful tool and talking-point. And as long as they’re used for that kind of purpose, it shouldn’t matter much when they do fail – especially if we can use that failure as a way to learn what to do differently next time. In other words, we accept failure as part of the deal – it’s ’safe-fail’.
But don’t try to use a ’serious toy’ for anything that’s business-critical. It’s not inherently wrong, but it’s simply not ‘fit for purpose’: they’re not robust enough, resilient enough, agile enough, secure enough, and so on – which means that as a system we cannot set them up to ’safe-fail’ in such a context. Sure, you could use Lego to build a house (it’s been done), or Meccano to build a bridge (that’s been done, too), but the effectiveness of doing so is questionable at best, especially over the longer term.
It’s the ‘-ilities’ that usually matter most in architecture. The functional requirements for a system are usually much the same at any scope or scale, but the qualitative or so-called ‘non-functional’ requirements are what will usually make or break the system in practice. Building an IT system that can handle half a dozen strictly-sequential requests in half an hour or even half a minute is relatively trivial; building one that can handle thousands or even millions of parallel, interleaving, fragmented, potentially-incomplete requests every second is not trivial at all; and yet the functional requirements are essentially the same. That’s the difference between a ’serious-toy’ prototype, and serious engineering with serious architecture and serious service-management and support behind it.
What we have right now in mobile-computing, ubiquitous-information and cloud is a whole bunch of serious-toys desperately pretending to be more than they are, and – more worryingly – being sold and used as if they’re more than they are. Sure, the function is there – but that’s easy. It always is. Getting them beyond that ’serious toy’ stage is not easy – and because it’s hard work to get there, it hacks into the short-term profits, too, so it’s not exactly popular amongst the money-obsessed.
So we have here all the ingredients for a ‘perfect storm’: more and more of individual people’s lives and livelihoods being placed onto platforms that are inherently unstable and unsustainable, because little or none of the work to make them stable and sustainable is as yet in place or even in progress. If you’re not already seriously worried about what will happen when large chunks of our society literally lose their collective mind and memory through the failures of these kludged-together toys, you’re not thinking hard enough about the architecture of the enterprise… 
The lessons of history are plain to see, and it’s also plain to see that the level of unaddressed risk has been raised each time, with even the earliest-period risks still not fully addressed even now. You Have Been Warned?
A bit late again – got a bit distracted. Never mind, here’s another week’s-worth of Tweets and links, sorted into the usual categories, after the usual ‘Read more…’ link:
Twitter-correspondent Craig Hepburn posted a Tweet this morning pointing to Dion Hinchcliffe’s excellent ZDNet article, ‘CoIT: how an accidental future is becoming reality‘, about the current rise and rise of ‘consumer IT’ or ‘cooperative IT’:
It’s a story as old as the IT department: New technology arrives in the market, it makes some type of work easier to accomplish, the business asks for it, and IT reacts and delivers it. Not always however, and usually somewhat slowly. It was this way with PCs, it was this way with the Internet, and now IT is faced with what is turning out to be a veritable perfect storm of technology and social change. …
Today’s highly mobile, social cloud has set everyone’s expectations for how easy, powerful, and simple IT can be. The genie will never be put back into the bottle.
For once I’m going to stand firmly on the side of the IT-folks on this one – because no matter how wonderful this looks right now, this is not good news at all. Looking at this with a futurist’s eye, I’m wondering how long it will take before we wish we could put the genie back into the bottle… because what I’m seeing here is a full-on disaster-in-the-making. Or rather, a double disaster-in-the-making, given how much this will interact with the ongoing disaster that is ‘cloud-computing’…
One of the first lessons any futurist learns is to look back at history, to seek out any equivalent occurrences in the past. And the blunt fact is that we’ve been here before… not just once, but several times already. Each time that we came back to the same place – if perhaps from a slightly different direction – it’s clear that the fundamental lessons were not learned, in fact were wilfully ignored; and each time it took a lot of effort, a lot of skill, and a lot discipline, to tidy up the mess – just in time for the next batch of overly-excited idiots to trash the place all over again. This is the dirty end of Gartner’s ‘hype-cycle’: someone has to tidy up the mess. And yes, “it’s a story as old as the IT department”, because in every case so far, that ’someone’ has been the much-derided IT department – and also enterprise-architecture, in its broader sense, beyond IT alone.
Go back sixty years or so, to the first beginnings of mainframes and ‘big computing’. Watch the hype-cycle at work: slow adoption, then a huge take-off in ‘data-processing’ (we didn’t get round to calling it IT until quite a bit later). It will solve every business problem! Control the world! Unlimited information on tap, right here, right now! Except it wasn’t quite as simple as that… turns out it was a lot of work to get standards happening (COBOL, the IBM-360 architecture, and so on), and then all the boring stuff about requirements, governance, maintenance, data-cleansing, service-management…
Twenty years later, it’s the mini-computer boom. It will solve every business problem! Now even medium-sized businesses can control the world! Unlimited information on tap, right here, right now! Except that it wasn’t quite as simple as that… turns out it was a lot of work to get standards happening (the C language, the Digital PDP-series architecture, and so on), and then all the boring stuff about requirements, governance, maintenance, data-cleansing, service-management…
Ten years later, we get the microcomputer revolution. It will solve every business problem! Now you too can control the world, right here on your desktop! Unlimited information on tap, right here, right now! Except it wasn’t quite as simple as that… turns out it was a lot of work to get standards happening (disk-formats, file-formats, data-architectures, the IBM-PC architecture, and so on), and then all the boring stuff about requirements, maintenance, data-cleansing, service-management…
Yup, you’ll be seeing the pattern here. The exact same sequence applied to the rise of the internet ten years later, the web five years after that (with a merry little hiatus called the Dot.Com.Bomb), the rise of cloud over the past few years, and now the rise of Hinchcliffe’s mobile IT or ‘CoIT’. In every case, there’s the same wild hype, the initial push from outside the IT-department (as ’shadow IT’) which gets the basic idea going to point where it’s usable.
(And to be fair, if that push hadn’t happened, those new developments would probably never have been usable: as Hinchcliffe implies, it’s actually quite rare that innovations arises from within the IT department itself. Because that isn’t it’s job: IT’s real job, unfortunately, is to tidy up the mess that will inevitably follow…)
In every case we see the same exuberance… then the slowly-dawning awareness that it isn’t quite as simple as that. It turns out that there’s a lot of work that’s needed in order to get standards happening – otherwise the new ‘revolution’ turns out to be something that can’t be shared, which means that the whole thing fizzles out quite quickly because we need that sharing to happen. We need clear standards for hardware, software, data-architectures, information-architectures, interchange protocols and much more besides. We need distinct disciplines around requirements, governance, maintenance, data-cleansing, quality-management, service-management and a whole swathe of other areas. And all of those, it’s now clear, need to allow for customisation, agility, security, versatility, adaptability, resilience and the like – none of which are easy to balance with conventional ‘control’-style disciplines.
So here I am, looking at the rise of Hinchcliffe’s ‘CoIT’ – particularly cloud-computing and mobile-apps. And what I’m seeing is an architectural disaster waiting to happen, if not unfolding right before our eyes:
I could go on… and on… and on… there’s no shortage of other nightmare-level architectural risk-factors that aren’t being addressed at all. Other than by the much-maligned IT-department, that is (who unfortunately tend to be able to see only the IT-related risks, which represent only a relatively small proportion of the whole); or by the few enterprise-architects who actually do think about whole-of-enterprise scope (and who are mostly derided, by the hype-merchants and their ilk, as doomsayers who’ve lost the plot). Not funny… Oh well…
Yes, it’s true that the excitement (or the oft-forlorn hope that it will finally be better this time?) is what gets people going to create new ideas; so yes, the exuberance does matter. Hence, in turn, I suppose, the hype does matter too. And safe-fail experiments are also always a good idea, because they show us where things will break but without causing much damage in the process. ‘Safe-fail’ can get quite extreme, too: for example, think of the buildings in a fireworks-factory, with very solid walls, very lightweight roofs – because when you know there’s a high risk that things can go badly wrong, you can indeed design for that fact. Yet there are also many types of structures that we can’t allow to fail: anyone who’s lived through a major earthquake or major storm-event will know that fact firsthand… Architecturally we need to be able to tell the difference between those two extremes, and design accordingly.
Yet that’s exactly what’s not happening here with cloud or CoIT: architecture of any valid kind, it seems, has all but been abandoned in the usual wild rush towards The Next Best Thing… So might it not be wise to take a brief pause for thought at this point, before we rush headlong into yet another insanely-expensive IT-disaster? Or is that too much to ask of anyone whilst the hype is in full flow?
This one’s about uniqueness and serendipity and ‘chaos’, and I’d better say straight away that it’s a lot more tentative and exploratory than many of my posts of late.
I’m seeing a theme in enterprise-architecture and the like that’s always been there in the background, but seems to have recently started to become a lot more visible to a lot more people. It’s difficult to pin it down precisely, but it can be seen sort-of sideways-on in many other themes:
Or, to illustrate, a couple of items from today’s Twitterstream:
This isn’t about emergence, or the ways in which unique or ‘chaotic’ events can be used to guide sensemaking and pattern-identification in complexity: others are better-qualified to explore that domain than I am. Instead, what I’m seeing here is almost the inverse of emergence: rather than deriving a pattern within complex events, we choose and use a pattern to guide our choices in inherently-unique events. Not just serendipity, but serendipity by choice – an architecture for uniqueness.
One item that comes to mind here is Gooch’s Paradox, identified by the psychologist Stan Gooch: “things have not only to be seen to be believed, but often also have to be believed to be seen”. To enable serendipity to occur, we first have to be a mental space that allows it at all. In that sense, beliefs themselves become tools.
Another is a quote from The Art of Scientific Investigation:
The truth of the matter lies in Pasteur’s famous saying : “In the field of observation, chance favours only the prepared mind.” It is the interpretation of the chance observation which counts. The role of chance is merely to provide the opportunity and the scientist has to recognise it and grasp it.
In a truly unique context – and it seems to me that every real-world context must always be in some part unique – there is only chance: there is no actual connection between anything and anything-else, other than that which we give it. Everything is coincidence, in an exactly literal sense of ‘co-incide-ence’: any meaning that we may ascribe (or not ascribe) to such coincidences is our choice.
Yet from Gooch’s Paradox, this also seems to be able to run backwards: we have the meaning first – predetermined beliefs from our culture or ’scientific law’ or the like – and then find coincidences to match. The belief determines what we see – which can lock us out of an ability to see anything else.
So in a business-context, for example, the beliefs that we use to filter what we see need to be tight enough to allow us to make useful sense of what’s happening around us, but also loose enough to allow true serendipity to happen – where the context itself seems to be giving us what we need. Hence Pasteur’s “chance favours only the prepared mind”: a preparation that has the right balance between precision and openness.
Which leads us to the idea of an architecture of uniqueness, an architecture designed to enable and enhance opportunities for serendipity.
Improvisation is one obvious component of such an architecture: a deliberate practice in working with uncertainty, in real-time.
Another component might be some variant of meditation, where continual, consistent repetition of the same actions or conceptual behaviours provides a stable ground within which useful ideas and events can coalesce. (This is the exact inverse of Einstein’s famous remark that “insanity is doing the same thing and expecting different results”. That dictum is true enough in a predictable world; but in an inherently unpredictable world – any context which is truly unique – anything we do will always lead to different results, hence repeating the same action over and over may be the only thing that will keep us sane! )
Sometimes we also need to deliberately ‘trick’ people into a state where serendipitous events can occur. For science-fiction buffs, this is very well described in Noise Level‘, a classic 1952 short-story by Raymond F. Jones: a group of scientists and engineers are asked to ‘reconstruct’ a supposed anti-gravity device, and actually manage to do so – only to be told at the end that the whole thing had been a kind of hoax, to show them how to open their minds to new possibilities that their conceptual filters would otherwise prevent them from being able to see. The method was a deliberate trick, but the end-results were no trick at all: nicely recursive, in that a very practical real-world technique is embedded in a fictional story about a fictional story.
There’s also the key role of visioning – a real enterprise-vision, that is, not the usual useless marketing-puff ‘vision’ – as a principle-based anchor for real-time decision-making amidst inherent uncertainty: the role in the military of ‘Commander’s Intent‘, for example, or John Boyd’s OODA (Observe, Orient, Decide, Act) cycle.
And there’s much more, such as the distinctions between analysis and emergence – which only ‘make sense’ outside of real-time – contrasted to the real-time spectrum between the simple and the chaotic; or the need for some kind of boundaries between the ’special world’ or chaos – where anything is possible but can send us into panic the moment we go off-balance – compared to the ‘ordinary world’ of rules, regulations and supposed certainty.
So what’s your opinion on this? What can we do to make this work? What strategies, tactics, models, methods would we need for this ‘architecture of uniqueness’, and architecture to support serendipity? And how would we apply this in enterprise-architectures and elsewhere?
Over to you, if you would?