By Stuart Boardman, KPN
Enterprise transformation is a topic central to The Open Group’s agenda these days, so I don’t suppose the following assertion is exactly radical. The success of transformation starts by understanding the drivers for change, the goals of the transformation and the factors that can be expected to have a positive or negative influence on it.
Transformation doesn’t necessarily have to involve innovation but it often does. Sometimes innovation is itself a driver for transformation. For some organizations innovation is a fundamental part of their business model. Apple, for example, wouldn’t have survived without it. You can have the best user interface and the grooviest products but to reach a wider market or indeed to get your existing market to buy new stuff, you need to keep innovating. And to do that well you have to enjoy doing it and you have to understand how it works.
Once upon a time, giants like the old IBM and the old Microsoft didn’t need to do that, because they owned so much of the market. But that’s changed too, because, partly as a result of their own competition, there is now an ecosystem of all kinds of players (from a Google or an Apple to the huge number of startups and app developers), who can and do come out of left field with disruptive innovation. And this isn’t only true in the technology world.
These days it’s hard to read about innovation without coming across the concept of emergence. Emergent innovation develops through interaction in an ecosystem and cannot simply be explained by looking at what each individual member of the ecosystem does. This kind innovation is in a sense serendipitous and is never going to be achieved via the traditional R&D approach. It’s cheaper and faster than that and, exactly because of the way it has developed, more likely to be of immediately applicable value. Achieving transformation with emergent innovation is about the ability to recognize, adopt, adapt and “productize” that innovation. This applies equally whether the innovation is outwardly (product/service) or inwardly (operations) oriented.
Back to transformation. We need, as I said, to be able to understand the factors that will positively or negatively affect the success of our transformation. If we haven’t properly understood them, they might turn out to be very urgent drivers for (re)transformation.
At the beginning of this century mobile communications providers were trying to transform their business models and operations in order to get their share of the internet revolution. They wanted to reach a new market and to escape the trap of becoming just a “bit pipe” for other people’s value added services. The operators spent a lot of money on 3G. The equipment manufacturers spent a lot of money developing new phones and interfaces. By 2003 we already had all the necessary technological capabilities and there was no shortage of marketing but it simply didn’t take off.
Why? It wasn’t really cost, because, when the iPhone arrived a few years later and turned everything around, data was still expensive (and the phone even more so). And it wasn’t really speed or usability, because the download speed was adequate for the services on offer and there were some pretty nifty devices. It just wasn’t very interesting. There was simply not enough valuable content available to justify the outlay. So the operators just reverted to milking the reliable voice and text cow.
When the iPhone arrived, what really made the difference was the ecosystem that came with it. Suddenly there was a world of app developers producing things people didn’t know they needed but discovered were cool. And there was the App Store that made it easy to get your product to market and easy for the customer to discover it. Yes, of course it was a groovy device and a revolutionary interface but without the ecosystem it would have been restricted to a market of Apple fans and people with lots of money to spend on looking hip.
So then what happened? Well the mobile operators (those who could get their hands on the device) finally started getting a return on their investment in 3G. What was largely a new group of smartphone manufacturers (HTC, Samsung, LG etc.) rushed to produce their own versions. And then Google came along with Android and we finally had a really large ecosystem built around innovation.
With that came another form of emergence as the users and the app developers started discovering all kinds of things you could do with these devices and the information available on and via them. That had a negative influence on the mobile operators’ revenues, as people used a whole range of IP based services (with the Mbs paid for in their monthly bundle) to avoid the expensive voice and text services. This was something the operators had ignored, even though they’d predicted years before that it would happen, which of course was exactly what provoked the earlier attempted transformation. In other words, they failed to understand what was going on in their ecosystem and how it might affect them.
All organizations inhabit an ecosystem consisting of their customers, partners, suppliers and in many cases legal and regulatory bodies (and arguably their competitors too). Ecosystems are really the heart of this blog, so here’s a definition. An ecosystem is a collection of entities, whose members are (at least partially) interdependent. Specifically we’re looking at what Jack Martin Leith calls a Business Ecosystem. Jack’s definition is further amended by Ruth Malan to “A business ecosystem is a network of organizations that affect each other, possibly indirectly.” What we see today is that for many (maybe most) organizations the ecosystem is becoming bigger and more diffuse. Apart from the examples above, this is apparent in the extended enterprise, Cloud and social business – and the effect is amplified by emergence.
Now one of the things about an ecosystem is that not all the members are necessarily aware of each other. But as the definition makes clear, they all have an influence on and are influenced by the ecosystem as a whole. Each organization has its own view on the ecosystem, which really defines its enterprise. That doesn’t mean it can’t be affected by what goes on elsewhere in the ecosystem.
A little while ago Peter Bakker published a provocative little blog with the title “Infrastructure Architecture is way more important than Enterprise Architecture.” After a flurry of comments and replies, I understood that Peter was talking about the infrastructure of complete ecosystems. He used the example of the infrastructure of the City of New York. It consists of all the road, rail and waterways, the transportation services (passengers and freight), construction and maintenance services, energy supply, port and harbor services and planning, regulatory and licensing activities. And that’s leaving aside the electronic communications infrastructure and the voice, data and TV services that run on it. These products and services are delivered by multiple providers (commercial organizations, the city council and other public bodies), who are all part of an ecosystem, which also includes the users of the infrastructure (people and organizations including of course the providers themselves). So yes, this infrastructure is much bigger than any one of the enterprises that contributes to it and it is critical to the health of the ecosystem (the efficient functioning of the City of New York) in a way that no individual member could be – not even the City Council.
But that information isn’t much use to us unless we can do something with it. So I set off on a journey to see if I could find a way of modeling such an ecosystem as a sort of Enterprise Architecture. That probably sounds a bit grandiose but you need to see this as just a set of techniques, which could help us create a usable and meaningful overview of an ecosystem – something you can project your proposed changes onto.
It’s not about details. Even if I thought one could capture all the details, the result would be unmanageable and therefore unusable! So the detailed view is constrained to the individual enterprise from whose perspective one is viewing this.
The journey’s just begun. I’ve built the basics of the story, which is about the mythical city of Metropolis. I’m sticking to this city infrastructure example, because it’s familiar to everyone and doesn’t need too much background explanation. I’m now looking at the techniques that might be useful in achieving this. I’m looking at and have started working on Customer Journeys. If you’re interested, you can find some text here and images here.
I think it will be very useful to create a Business Model Canvas (or some similar technique of your preference) for some or all of the organizations involved. In the most cases we’d be looking at generic organization types. So for, example, there won’t be a canvas for every single bus company but the fact that there usually are multiple passenger transport companies means that competition is an important factor.
So we probably need an additional model, which is capable of taking that into account – like Tom Graves’s Enterprise Canvas. I’m also considering a service model (what are all the relevant services, how do they interact, etc.). Stafford Beer’s Viable Systems Model may be a good way to capture the system as a whole, so I’m working on that now. I’d be only too pleased to exchange ideas about the whole approach with anyone who doesn’t think I’ve taken leave of my senses – and maybe even with those who do! My thanks to Jack, Ruth, Peter, Tom and Charles for the good ideas and encouragement. Please don’t blame them, if you think it’s rubbish.
So finally – you might be wondering what this has to do with the sewers of Vienna. If you’ve seen The Third Man, you might figure it out. For those who haven’t: in the film Orson Wells plays Harry Lime, a wanted man in the Western sector of post-war Vienna. He fakes his death and disappears to the Russian controlled East – and continues his operation in the West using the sewer system to get across (under) the city avoiding all control posts and remaining effectively invisible. It’s just a somewhat lighthearted example of an innovative (one might say emergent) transformation of an infrastructure to serve a totally different purpose. And it does illustrate how you can get caught out if you don’t understand your ecosystem properly.
Stuart Boardman is a Senior Business Consultant with KPN where he co-leads the Enterprise Architecture practice as well as the Cloud Computing solutions group. He is co-lead of The Open Group Cloud Computing Work Group’s Security for the Cloud and SOA project and a founding member of both The Open Group Cloud Computing Work Group and The Open Group SOA Work Group. Stuart is the author of publications by the Information Security Platform (PvIB) in The Netherlands and of his previous employer, CGI. He is a frequent speaker at conferences on the topics of Cloud, SOA, and Identity.
An ecosystem should be looked upon as an extended enterprise I think, basically aimed at reducing transaction cost.
@Frans. Yes, you could argue that an extended enterprise was an ecosystem. I wouldn’t. There’s no one correct meaning. It’s just a question of being clear about one’s own usage. From my perspective (and I think also that of the folks I cited in the blog) an ecosystem is not identical to an enterprise – of any sort. If it were, I would have to think of another word to describe what I’m calling an ecosystem. Also in the specific instance I’m describing, it’s clear that the ecosystem has no commonly defined aim. We might want it to but that’s a whole other discussion. It’s a fine example of what Beer called POSIWID – the purpose of a system is what it does.
Of course ecosystems can exist at many levels. I’d like to say they were recursive but I’m not sure that’s always true. An enterprise can of course have an internal ecosystem. That’s just not the focus of this article.
Putting the record straight. That’s Stafford Beer not Stamford Beer. Must have been sleeping when I wrote that bit.
This a purely symbolic comment.
I found your article thanks to Jack Martin Leith’s Twitter stream. I must say I was pulled in by the title “The Sewers of Vienna”. At first, I thought sewers had something to do with men who “sew”, tailors, with thread & needle. So it vaguely echoed a Grimm’s tale, “The valiant little tailor” and triggered my curiosity.
I googled sewers and discovered a less romantic meaning, still, I thought I would share this with you, as it resonated with your “Enterprise canvas”.
Also, I come from a town, Lyon, famous for its “traboules”, used by the silk workers during the middle-ages.
“Traboules (from Latin transambulare via vulgar Latin trabulare meaning “to cross”) are a type of passageway across and underground the town”. They were used during World War 2 by French resistants to prevent Germans to take control of the town.
Another story to weave to your great tapestry, The Traboules of Lyon?
Thanks Marion. Indeed another good story. People’s inventiveness is so often ignored by those in charge – sometimes (as in this example) that turns out to be a good thing.
“Achieving transformation with emergent innovation is about the ability to recognize, adopt, adapt and “productize” that innovation.”I don’t under stand it… Can you give me more information? Great article!!!