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:
One of the most essential tasks in enterprise-architecture is that of enabling conversations on architectural issues, with any groups of stakeholders, anywhere across the enterprise.
Our toolsets play an important role in those conversations. The right tool used in the right way can really help the conversation, help create new shared understandings across the silos and the specifics of each distinct discipline.
But the wrong tool – or even the right tool used in the wrong way – may instead act as a real barrier against awareness and understanding. Getting the balance right is critical to creating the clarity we need – yet the requirements, and the balance, are different for every type of architecture-conversation.
We’ve long had a good range of frameworks and toolsets for IT-oriented architectures. Some were aimed more at systems-development; others more at taxonomy and ontology and metamodel-development; others again at modelling dependencies across IT systems and ‘business/IT-alignment’; and yet others at requirements-traceability, governance and project-management. Yet they all had one thing in common: their whole focus was about precision, about certainty – because that’s what system design and development really needs.
But as enterprise-architecture at last begins to break out of the IT-centric box that it’s been trapped in for the past couple of decades, we start to hit up against some real limitations of those toolsets:
There’s also still no common exchange-language to transfer architecture-information between the tools that we already have – and even when we get one, we’ll need it to go wider than that, anyway. A lot wider.
When we look at how we actually work with executives or process-designers or security-architects or the like, the tools we most often use at present are a whiteboard or a sketchbook – nothing else has the flexibility that we need. None of the existing tools allow us to play ‘what-if?’ as well as we can on a whiteboard; and the precise formal rigour of model-validation is far more of a hindrance than a help in this kind of work, where half the time we don’t even know what kinds of architectural-entities are involved – the whole point is that that’s what we’re aiming to find out!
But we still need some kind of toolset-help here: images on whiteboards and sketchbooks aren’t easy to share – I’ve often seen people simply photograph the results and pass the image-files around as ‘the model’ – whilst office tools such as Visio and Powerpoint give a spurious illusion that the results have been captured with enough rigour to be re-usable (which they’re not), and are usually too slow and cumbersome for an across-the-table discussion anyway.
So here’s our challenge: develop a toolset for the ‘conversations’ end of the enterprise-architecture spectrum – one that will work on laptops and netbooks, on the new tablet and touchpad systems, and preferably right down to smartphones as well.
It needs to be able to cover any aspect of enterprise-architecture – from business-models to skills to security to process to disaster-recovery to operations to knowledge-management to applications to service-management to IT-infrastructure to building-infrastructure and anything in between.
It needs to be able to adapt itself to the needs and worldviews and language of each of those groups of stakeholders – and provide some means of translation between each group, too.
It needs to be fast, easy to use, engaging, enjoyable, preferably tactile too – yet have a fully-structured methodology and metamodel behind it.
It needs to allow freeform development of models and diagrams – yet still be capable of linking to the formal rigour of the ‘top end’ systems.
Coming the other way, it needs to help us explain the structures and reference-models that we already have in our ‘top-end’ systems – and explain the reasoning behind those models, too – whilst still keeping people actively engaged in the conversation.
And more and more, architects are beginning to recognise that spurious certainty is a real risk for the enterprise – so this also toolset needs to help our stakeholders become more comfortable with uncertainty and change.
Working with a loose consortium of colleagues – including Adrian Campbell, Kevin Smith, Milan Guenther, Nigel Green and others – we’ve done a fair bit of work on this already:
There’s a lot more to do to get this even to an alpha-release state in any format or platform; and whilst all of us, in the group so far, have ‘done our time’ in software-development and the like, none of us is sufficiently available (or, in my case at least, really up to the speed or quality needed) for professional-level app-development on current systems. 
So we’re going to need help to make this happen.
I for one would prefer to see this as an Open Source or at least freeware/shareware type of development, so as to get this out into as general a usage as possible. (As I see it, this kind of toolset should have many other applications outside of enterprise-architecture, such as in strategy-development, tactical planning etc.) But if some commercial developer wants to take it on, that would be fine too, as long as we can keep the final end-user cost down to app-levels (perhaps $10-30 at most) rather than the three-, four-, five- or even six-digit sums we sometimes see for other toolsets.
So: over to you. Any offers of help or advice? Any other comments or suggestions?
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.
Architects are designers too. Application-architecture designs link across an array of applications, process-architects design ways to link processes together, business-architects design business-models and their linkage into the everyday practices of the organisation. That much should be obvious, I would presume.
Yet in practice – and certainly as the scope widens – more and more of our actual day-to-day work consists of creating and enabling new conversations: architectural conversations between business and IT and anyone and everyone else in the overall enterprise. The ‘one idea’ of all architecture is that things work better when they work together, with efficiency, with clarity, on purpose: and to make that happen, we need to get people to talk with each other. Simple as that, really.
One practical problem we face is that the architecture tools that we have available to us at present are not that well-suited to that purpose. For some conversations, yes – but those tend to be the most technical of the conversations. For the ordinary-yet-important conversations with everyday stakeholders, we’re not well-served at all. And as we move more and more out of the purely technical domains and towards a true ‘architecture of the enterprise’, the more that gap is going to get in our way.
What we really need is something that’s probably impossible in practice: a single tool that will cover the whole spectrum from the loose, freehand sketching and storyboarding of architectural issues and requirements, all the way through to the tight rigour and discipline that we need in specifications for real-world design and implementation.
We also need that imaginary ‘one tool’ to cover another whole spectrum of usages, from centralised repositories and very large ’scorecard/analysis’ displays through to multi-screen desktops to single-screen laptops to tablets and touchpads right down to handhelds and smartphones.
The big, expensive enterprise-architecture toolsets such as System Architect or ARIS or Troux Metis tend to sit over in one corner of the matrix between those two spectra: they embody the formal rigour of software-, system- or process-design and simulation, and they need big repositories, big servers and big displays to deliver their best performance. These are also definitely not tools that should (or even can) be used by general users – a fact I know from painful first-hand experience of the months we had to spend tidying up the mess that our business-managers made of our repository after we’d foolishly allowed them to play with it for a single week…
Then there’s the mid-range: toolsets such as Avolution or BizzDesign Architect or Sparx Enterprise Architect, or Alfabet or Essential. All of these are well suited to laptops and other larger single-screen systems, and each tend to emphasise particular themes: metamodelling with Avolution or Essential, for example, or Archimate business/IT-alignment with BizzDesign or Sparx, or IT-infrastucture configuration with Alfabet. They all have some kind of internal repository, which in turn supports some kind of diagramming; but it’s not always easy to share – especially across a whole multi-organisation enterprise. And these are still tools for specialists – not something that we can use with everyday business-folk, as I discovered the hard way when I presented a set of BPMN diagrams at an executive-meeting…
Down in the far corner, though, there’s almost nothing: no usable toolsets for idea-thrashing with ops-staff, developers, executives and all the other myriad non-specialists. Office tools such as Powerpoint and Visio are just-about-okay for documentation after the event – though they provide little to no support for architecture-rigour at all – but they’re far too slow and cumbersome for real-time discussion. So it’s no surprise that for most architects I know, their most important tools are a whiteboard and a sketchpad – and not only do those provide no linkage to formal architecture-rigour, but it’s usual not even possible to record and share the results. Which means that we have almost nothing with which we can engage people in the architecture itself – in the discipline of the architecture.
But what would such a toolset look like? What aspects of architecture-discussions could it cover?
One project that I’ve been involved in (as a member of its alpha-test team) is Alex Osterwalder’s iPad app for his Business Model Canvas framework – perhaps take a look at the videos on Alex’s post. That’s also a key reason why I developed the Enterprise Canvas concept, to extend the same basic idea to the whole-of-enterprise scope. And there’s also a swathe of iPad or smartphone apps that cover themes such as sketching or mindmapping or outlining or project-management, that do at least enable us to record in a form which can be stored and re-used later.
The real aim, though, is to get to some kind of toolset that is freeform enough to be used in live discussions, yet beneath the surface embeds at least some of the rigour needed for architecture-development. There are some great hints towards this in an article in HBR by Michael Schrage, ‘How Your Smartphone Will Transform Your Elevator Pitch‘, which are worth noting in some detail here:
… His [business-idea] was undeniably clever, but aspects of his business model weren’t clear to me. He had his elevator pitch answers down pat, but I wanted to learn more. Unprompted by me, Osman whipped out his smartphone and handed it over. I was watching a decent video clip illustrating his product’s features and functionality. I could tap to hear testimonials. I could tap to play with a simulation of the software. In a matter of moments, the device had transformed Osman from an entrepreneur I was having a conversation with to a guide and narrator of an interactive experience. My focus and attention alternated between what he said and what appeared onscreen. Sometimes he’d take, touch, and hand back the device; other times, I’d point to something onscreen and ask another question.
The object — and our interaction with it — became an intimate part of our conversation. We couldn’t have discussed either [his product] or his answers to my questions the same way without it. An idle part of me wondered how cool it would be if our conversation (and my questions) could be recorded and time-stamped along with what was appearing onscreen. Osman refused to allow his smartphone to decay into a sales tool or product pitch — although those elements were baked into the material — and instead used the device as a medium to both reinforce his conversation points and invite new questions and comments from me.
I can say without hesitation that this felt technically and interpersonally different from “laptop-on-the-table” presentations I’d experienced 1,000 times. We were standing up, drinking coffee, chatting, and taking turns holding, viewing, and manipulating this device. The kinesthetics, eye contact, questions, and interruptions revolved as much around the device as us. We would have been worse off without it.
And, further on in the article:
Elevator pitches are important. The ability to boil down the essence of your innovation into a tasty forty-second sound-bite remains essential. Only now, the pervasiveness, ubiquity, and visuality of mobile devices quantitatively and qualitatively changes the ecology of interpersonal interaction. It’s no longer about what you say and how you say it; it’s increasingly about what you hand over.
What do you hand over that transforms the conversation? What do you hand over that visually and interactively adds value to your spoken words? What do you hand over that complements and supplements your pitch? What do you hand over that invites and inspires the curiosity you want? What do you hand over that makes you more persuasive?
… “Hand-it-over” innovation pitches can be seamlessly slipped wherever your prospects desire. Indeed, an excellent measure of “hand-it-over” effectiveness is whether the person who you “hand-it-over” to actually asks you to send what they’ve been seeing and interacting with.
So let’s summarise some of the key themes there:
That’s what we need for that part of our enterprise-architecture work – a toolset that enables us to engage directly with our stakeholders. And it needs to go both ways, too: to take a model or diagram from the formal ‘big-system’ part of the toolset-spectrum and share it and discuss it; and also enable and capture discussions about requirements, about trade-offs, about different understandings and paradigms and worldviews and expectations and assumptions across all the myriad of different perspectives in the enterprise. Both ways. About anything – about any aspect of the architecture.
Which also means that we must have some kind of language to enable us to move information up and down through that spectrum, across different devices, different systems, different toolsets. (It seems very unlikely that one vendor will ever cover the whole range that we need – but the information itself must be able to move around in any form that we need, yet always anchored back to the formal rigour required by each architecture-domain.) So that’s another hurdle to cross, because no such language exists at present.
So, given all of this, how could we improve on the venerable whiteboard and sketchpad? How could or would we record that kind of interaction? And how can we support a form of diagramming that is as interactive and illustrative as a whiteboard-session, yet still enables the underlying rigour? The specialist EA toolsets may be too cumbersome for this kind of interactive use, but surely we can create something with more rigour than Powerpoint or Visio?
That’s our challenge here. Comments/suggestions, anyone?
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:
It’s been quite a while since I wrote about my own policy on how I use Twitter.
In Twitter, many people aim to follow just about anyone who follows them. Quite a few people seem to think that this is a matter of etiquette, that it’s rude to not follow someone who follows you.
And yet here I am, a fairly ordinary, nothing-special kind of guy, with a fair few more than five hundred followers at last count, but only following rather than less than a hundred. In terms of those views about etiquette above, it might seem like I’m more than a bit rude to the Twitter community. So if my follow/not-follow seems unfair to you for that reason, I do apologise.
But it’s not about rudeness, I promise you – in fact it’s simply a matter of managing Twitter-overload. Let me explain.
As I understand it, many people just let the Twitter-stream go by: wash past them in a swirl of unending opinions and experiences. (If someone is following literally thousands of people on Twitter, I can’t see how they could do otherwise than let the stream wash past.) This would mean that the only option is to trust to serendipity: that the right Tweet, the meaningful Tweet, will somehow jump out of the stream, demanding attention at just the right moment.
I know that works for some people, perhaps many people, but it doesn’t work for me. Instead, I treat Twitter as my main business-intelligence tool. I assume that every Tweet is potentially meaningful – which means that I read every single Tweet that comes my way. I manually check just about every link presented in those Tweets. And I read probably at least half the articles linked-to in those Tweets – not just skim-read, but read carefully enough to make (I hope) useful comments on them.
In short, it’s a lot of work. As it is, it already occupies at least a couple of hours every day, and often more. That’s why I’m very careful about who I follow, because I have to – I don’t have any other choice, if I’m to stay sane and get any other work done in the day.
I’m an ‘aggregator’: I collect information, annotate it, and pass it on. I reTweet an average of about ten Tweets a day, sometimes more; many other Tweets that I receive (totalling more like thirty a day) will end up, often with extensive annotations, in my weekly ‘A week in Tweets’ blog-posts. That’s why I tend to restrict my ‘follows’ to those who are other ‘aggregators’ – people like Oscar Berg, Sinan Si Alhir, Craig Hepburn, Trevor Snaith and Pat Ferdinandi, to arbitrarily pick a few examples – yet who tend to post only a relatively small number of focussed Tweets. I also follow a few specific ‘thought-leaders’ in a much wider range of disciplines, but again, only those who post a relatively small number of Tweets.
I do believe I deliver a useful service in annotating all the Tweets that I reTweet or re-post. (Several people have told me this directly, which is kind of them.) Yet the only way I can do this is by keeping down to something manageable the numbers of Tweets that I have to deal with – which at the moment is around 150-200 Tweets a day. Hence the tight restriction on who I follow, and how many people I can follow.
The simplest annotations I do are the addition of specific hashtags. I’ll admit that a few of these may not be readily comprehensible to everyone, particularly:
My longer annotations always occur after the link (if any), and are preceded by a ‘<’ sign. Occasionally I’ll have to abbreviate or edit the original Tweet to make room, but otherwise I try to keep them intact. And wherever possible I try to include the Twitter-ID of the person who provided the original Tweet. (I notice that quite a few people don’t bother, but to me the attribution is an important point of professional etiquette, and also important for those who need to follow citation-trails in future.)
One other point: blocking. Like everyone, I receive quite a few ‘follow’-requests that are from spammers, time-wasters and people who are just trawling for auto-follows in the belief that quantity is more important than quality. (It isn’t. 
) I check every follow-request, and allow or block accordingly. There are also a few people whom – politely, I hope – I will block on the grounds that my work will be irrelevant for them: for example, someone from a building-supplies store who misunderstood the context of ‘architecture’ that I work in. In general, that check of the initial follow-request is the only time that I will block a potential ‘follow’. In fact I’ve only had one case where I had to block someone who’d been following me for quite a while – and that was because that person had become openly abusive to me and to others on my Tweetstream, and was frankly beyond a mere nuisance.
So that’s it. If I don’t follow you, it’s not because I don’t think that what you say is interesting – because it almost certainly is interesting. It’s just that I’ve found that this is the only way I can cope with the flood of information and still stay sane (or vaguely-sane, anyway… ). If there’s something that you think I should know about, please Tweet me direct as @tetradian – because, again, I do read every Tweet that I see.
Many thanks to all, anyway.
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?
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?