I'm tired of many of these discussions because they're ridiculous. However, once more unto the breach dear friends.
First, lets take a map. I'm using an example based upon HS2 (high speed rail) in figure 1. Now, the map contains many components, all evolving (under supply and demand competition) from the uncharted space through a transitional space to an industrialised world. I mention those three different stages just in case a hoard of bimodalites come raging past.
The methods you need to use depend upon how evolved the components are. For a handy guide, I've put down the normal range in figure 2. In the uncharted space, you're discovering and so you need to reduce the cost of change. Hence Agile (or more accurately, the Agile principles) are best suited. By the transitional stage, you know roughly where you're going and you need to reduce waste and learn more on the environment. Go read Lean for this. By the time the same act becomes industrialised then you're into reducing deviation and here Six Sigma rules. So let us look at those figures.
Figure 1 - A Map (modified from HS2)
Figure 2 - Methods.
Now, most organisations (and by most I mean > 99%) have no map and therefore no situational awareness instead relying on story telling and SWOT diagrams. Hence the tendency to adopt one size fits all methods and all the other instruments of la la land including woeful strategy, meme copying, no mechanism of learning through context, masses of duplication and bias etc. If you want a good laugh, you should spend time in the boardroom when people discuss strategy ... any illusion of chess playing masters will quickly disappear. People are really shooting in the dark here and struggling because of it.
Since most people have no situational awareness, the best you'll get is a business process map or another box and wire which shows connections between things but no context. You'll get something like figure 3 and asked the question which bit should we outsource? In the past we tended to outsource the whole lot because we didn't have a clue.
Figure 3 - A box and wire
So what happens when you outsource the lot? Well, you'll try to put a well structured contract in place to make sure you know what's being delivered. But lets look at this box and wire in terms of a map. See figure 4.
Now this is a rough map (the only people who can actually map an environment are those actively working in it) but it'll do for this discussion.
Figure 4 - A map of the box and wire.
Now we can argue about the position of the pieces on the map but eventually we will get to something we agree on. Let me assume the above is about right and we've outsourced the lot to a friendly outsourcing supplier under a very structured contract because that's the "sensible" (chortle, chortle) thing to do.
What's going to happen is the stuff on the right (the industrialised bits) will hopefully be delivered effectively and efficiently by the supplier buying highly commodity components or well defined products. You certainly don't want them to be building a LIDAR like you're the first person to ever have one of these. Things like GPS, LIDAR and even geographical maps (though not included on the diagram here) are actually well understood and common and hence suitable for outsourcing, provision as commodity components etc. However, the stuff on the left in the uncharted space will change. We will be exploring this space, working out what do we actually need from a World Perception Server. The result of this change will of course be excessive cost control overrun through a change control process. Naturally the supplier will say that the excess cost is all your fault because you didn't specify well enough what you wanted in the World Perception Server etc but the reality is you could never specify well enough. Neither you nor anyone else could know what is required in the uncharted space. You have to experiment.
The problem with outsourcing in the past wasn't the concept of outsourcing but instead that organisations outsourced entire systems for which they had no situational awareness. This was foolish and of course outsourcing got a bad name except from the suppliers who cottoned onto the scam and made oodles of cash out of it. The simple reality is that there's nothing wrong with outsourcing if you break down complex environments into components and outsource those industrialised ones.
Which is where cloud comes in. Cloud is all about the shift of a bunch of product based IT activities to highly industrialised utility services. When you're using AWS for infrastructure e.g. EC2 then yes you're outsourcing infrastructure to AWS but in this case you're outsourcing a highly industrialised component to a utility service provider. Top marks, a dead sensible thing to do.
What you're not doing is the "old" form of outsourcing which means taking a whole bunch of components for which you do not understand the context and handing them to someone else in the hope they will take of it for you. For those going "people didn't really do this, did they?" ... oh boy did they and for endless reasons of gibberish e.g. from it's too difficult to deal with components and interfaces to it'll reduce risk. The only risk it reduces is the risk that the supplier won't make excessive profits. Trebles all round.
So, yes ... cloud is all about outsourcing highly industrialised components to utility service providers. No, it's not like the outsourcing of the past which was barking mad in many cases. No, the mechanics of this are very different and before anyone says something really daft like "Isn't cloud like renting a room in hotel" ... I'll stop there.
This "wisdom" was brought to you care of 2006. Shame on you if you're still getting this wrong. I'm fed up with being nice to people on this, please go work in another industry and stop giving IT a bad name. Or go run Donald Trump's IT office and bankrupt him. Tell him you need custom built servers, oh hang on ... custom built chipsets ... oh wait, no tell him you need an entirely new form of power to run the web site (i.e. a dyson sphere) and outsource all the exploration to someone under a "fixed" contract like it's an industrialised component. At least you'd be doing everyone a favour.
For all our sakes, stop doing this in Government IT. Please, just leave. Regardless of what you think, we are in economic competition with other nations. There's better places to spend taxpayers money than flushing it down the toilet by outsourcing without situational awareness. Oh, and before anyone says "mapping is hard" etc ... with a bit of practice you can create a really useful map in a few hours. You can then start sharing maps and getting rid of duplication and bias - but that's a post for another time.
Btw, all the mistakes above such as outsourcing too much, one size fits all methods, creating dual structures are mistakes I've made but learnt from.
For all our sakes, stop doing this in Government IT. Please, just leave. Regardless of what you think, we are in economic competition with other nations. There's better places to spend taxpayers money than flushing it down the toilet by outsourcing without situational awareness. Oh, and before anyone says "mapping is hard" etc ... with a bit of practice you can create a really useful map in a few hours. You can then start sharing maps and getting rid of duplication and bias - but that's a post for another time.
Btw, all the mistakes above such as outsourcing too much, one size fits all methods, creating dual structures are mistakes I've made but learnt from.
