Ok, a bit of history to begin with. When I took over running Fotango (a Canon Europe subsidiary), it was a loss making organisation. It took me a year to make it profitable. We grew the business by taking our skills and applying them to relevant areas. In the end we were managing, developing and operating over a dozen major systems with millions of users.
However, we had constraints. The two most challenging of which were head count and profitability. We had to operate on a basis of no head count increase (this was due to a parent wide rule) which forced us to automate more, re-use and find ways to create space for development. The second constraint was we had to be profitable - every month. The later is a real headache when you have millions in the bank but can't invest. Any investment we wanted to make had to come through operational efficiency which in no small part was why we end up implementing some of the first web based private infrastructure as a service, auto configuration, continuous deployment and self healing tools between 2003-2005.
In the board room, James and I used a map to determine where we could attack, to plot our path. I've taken a version of that map and rolled it forward to mid 2007 in order to illustrate some points. The map is provided in the following figure.
Now the map gives us position of things in value chain (from visible user need to hidden components) versus movement (i.e. how things evolve). On this map is one of the lines of business we had.
From the map, there are several points we could attack.
Point 1 - Attack compute provision as a utility. We actually had a system called Borg which ran our private IaaS. We had offered this to other vendors and planned to open source it later in 2007. Whilst we couldn't build a public IaaS (due to the capital investment required and the constraints we had), that didn't mean we didn't want to see a fragmented market of providers in this space.
Point 2 - Attack platform provision as a utility. We had actually embarked on this route based upon the earlier maps and launched the first public platform as a service known as Zimki. We had all the capabilities necessary to build it and back in 2005 we had anticipated someone else would launch a public IaaS. I thought it was going to be Google, turned out to be Amazon. The importance of a public IaaS for us is it would get over our investment constraint. We planned to open source the space in late 2007, had the components for an exchange and a rapidly growing environment etc. The play itself was almost identical to Cloud Foundry today.
Point 3 - Attack CRM as a service. We had looked at this in 2005, decided we didn't have the skills and others were moving into the space.
Point 4 - Attack Apps on Smart Phones. Back in 2004 we were working on mobile phones as cameras, however there was no way to anticipate the development of the iPhone. In 2007, we might have made a play in this space based upon past skills but we had effectively removed those parts of the value chain from the organisation. We had to concentrate on somewhere in 2005, we had the constraint of resource growth, we had to make a choice. That choice was the platform play. But in 2007, it could be an option.
Point 5 - Build something new. We certainly had the capability to experiment, we used hack days and other tools to come up with a range of marvellous ideas. However the resource constraint meant we needed to industrialise the platform and get ourselves and others to build on top of this. We could use ecosystem effects to therefore sense and identify future success.
Now, I've simplified a lot of the thought processes along with the actual map, but the point I want to make is that we had multiple points of attack - the WHEREs. The WHY was a discussion over which we could exploit given our constraints such as resource & investments along with capabilities. This gave us our DIRECTION.
Each node or point on a map actually breaks down into a more complex map of underlying components. Some of those were novel (the uncharted) and some were more commodity (the industrialised). We knew how to apply multiple methods (agile, six sigma etc) appropriately, how to build and exploit ecosystems and a vast range of tactical games we could use.
However, once we determined our DIRECTION, we moved deliberately along that path. Yes, we had very fast deployment and development cycles. Multiple builds in a single day to live for components was nothing special. However, that tempo wasn't uniform. Releases in the uncharted space would happen continuously. In the more transitional space (between uncharted and industrialised) it slowed down considerably and by the time you reached industrialised then releases could be monthly, much more regimented. We had been running as an API shop since 2003 and we had long learned the lesson that you couldn't go around changing the APIs of the deep underlying components ten times a day without causing friction and cost in the higher order systems.
This is why those more industrialised, lower order components we'd look to move to outside and stable utility providers. Unfortunately, though we anticipated their development, none existed in 2-2004 - 2005. There wasn't an Amazon, Scalr, RightScale, Chef or any of the other infrastructure, management, configuration and monitoring environments. We had to build all this just to get to the platform layer and our speed depended upon stability of lower order interfaces.
Take something today like Netflix. They could not have existed if Amazon changed the core APIs of EC2 twenty to thirty times a day. Stability of the interfaces of lower orders is critical for development of higher order - this is basic componentisation.
Now Fotango's story ended to due to a sorry tale of strategic advice which is why you often find me in conferences throwing rubber chickens with the words "Situational Awareness" at big name consultancies as they mumble "blah, disruption, blah, digital, blah, cloud, blah, ecosystem, blah, innovation, blah". Especially at Big Data conferences where they seem to gather to flog blobs of "wisdom" to the unsuspecting masses.
However, there are some things I do want to remind people of.
Have a DIRECTION.
This is one of the most important parts of mapping & improving situational awareness. You not only need to learn to use multiple methods (e.g. agile, lean and six sigma) but you also need to understand the landscape and steer your way through it. Maps are dynamic and yes, sometimes you have to pivot based upon changing conditions. However, Agile is not a solution for an indecisive and variable management. When moving in uncharted space you steel need a DIRECTION and adapt to what you discover. You don't need a captain who can't keep a decision for more than five minutes without changing. If the reason you're using Agile is because your manager is going Fire! Aim! Change Course! Don't Fire! Did we Fire? Fire! No, Don't Fire! Change Course! Change Course! Don't Fire ... wait .. FIRE! ... No! Change Course! Then you've got bigger problems than methods.
Move APPROPRIATELY fast.
Yes, continuous release processes are great for exploring uncharted spaces and building higher order systems. However, you need stability of interfaces at lower order systems (which includes not just syntax but semantics). For anyone who doesn't understand this, hire a crew of electricians to replace all the sockets in the buildings & data centre with sockets and transformers to supply power equivalent to a different region. Call it a 'release' and watch the expressions of horror when nothing works / plugs in. After they scream murder at you and finally get around to setting some stuff up, send your electricians around to replace it all with another region. Do try shouting at everyone that you were only being adaptive & innovative whilst they beat you with their dead computers.
Focus on USER needs
That's the first step of mapping and hardly worth repeating because you should be doing this. Of course, if you weren't actually doing this you might run around changing plug sockets to a different region. Ditto some of the changes I see in the online world.
Before anyone says "Oh but we can make special adaptors to cope with the change" which invariably leads to a host of different competing standards and then someone creating the standard of standards ... just give up.
Use APPROPRIATE methods
I'll use one diagram and go - enough said.
If anyone feels like going 'Have you considered using dual operating / twin speed IT / bimodal" or any of the other "organise by the ends" brigade. Don't even go there.
