Outsourcing Architecture?

The Harvard Business Review Blog Network published a rather interesting article on the reasons behind the failure of the Boeing 787 Dreamliner. One of the main causes seems to be related to how Boeing outsourced work.

Boeing undertook one of the most extensive outsourcing campaigns that it has ever attempted in its history. That decision has received a lot of press coverage, and the common wisdom is coalescing around this as a cause of the problems.

Outsourcing as such is not wrong or risky. Many success stories heavily depend on outsourcing: Amazon outsources delivery, Apple outsources all manufacturing … The key is what you outsource and what you keep internal.

Rather, the issues the plane has been facing have much more to do with Boeing’s decision to treat the design and production of such a radically new and different aircraft as a modular system so early in its development.

In other words, Boeing outsourced some of the architecture of the new plane. That was new for them. So far they only outsourced manufacturing of parts after Boeing designed them internally.

if you’re trying to modularize something — particularly if you’re trying to do it across organizational boundaries — you want to be absolutely sure that you know how all the pieces optimally work together, so everyone can just focus on their piece of the puzzle. If you’ve done it too soon and tried to modularize parts of an unsolved puzzle across suppliers, then each time one of those unanticipated problems or interdependencies arises, you have to cross corporate boundaries to make the necessary changes — changes which could dramatically impact the P&L of a supplier.

This equally applies to IT solutions. If you outsource parts of the solution before you have designed the whole, you’ll end up with problems whose solutions cross supplier boundaries, impact P&L of those suppliers and require contract negotiations. To avoid this, the entire solution has to be designed before suppliers are chosen and contracts signed. That includes the design of new components, changes to existing components and, often forgotten, integration with existing (“AS-IS”) components.

Either you outsource this entirely (all of it, you can’t be cheap and only outsource 95% of it) or first design the whole internally first.

In the creation of any truly new product or product category, it is almost invariably a big advantage to start out as integrated as possible. Why? Well, put simply, the more elements of the design that are under your control, the more effectively you’re able to radically change the design of a product — you give your engineers more degrees of freedom. Similarly, being integrated means you don’t have to understand what all the interdependencies are going to be between the components in a product that you haven’t created yet (which, obviously, is pretty hard to do). And, as a result of that, you don’t need to ask suppliers to contract over interconnects that haven’t been created yet, either. Instead, you can put employees together of different disciplines and tell them to solve the problems together. Many of the problems they will encounter would not have been possible to anticipate; but that’s ok, because they’re not under contract to build a component — they’ve been employed to solve a problem. Their primary focus is on what the optimal solution is, and if that means changing multiple elements of the design, then they’re not fighting a whole set of organizational incentives that discourage them from doing it.

For Boeing it is going to be a very costly lesson. But at least they’ll have a chance to learn. Large IT projects often fail for exactly this reason: modularize a complicated problem too soon.

One last element from the article … why did Boeing do this?

They didn’t want to pay full price for the Dreamliner’s development, so, they didn’t — or at least, that’s what they thought. But as Henry Ford warned almost a century earlier: if you need a machine and don’t buy it, then you will ultimately find that you have paid for it and don’t have it.

They wanted to safe on the development of the aircraft and thought that by outsourcing the design (the ‘tough problems’) they would keep costs low.

Morale of this: don’t outsource pieces of a puzzle before the entire puzzle is known (designed or architected).

How many times did you encounter this in IT projects?

Prevent, Detect and Recover

Most organizations spend a lot of money trying to prevent damage to information assets.  Typical measures are firewalls, anti-malware, authentication, authorization … But sadly most organizations forget there are three dimensions to proper risk management:

  1. Prevent. Measures to prevent risks from becoming reality. This is where typically most investments are done.
  2. Detect. Detect, after the fact, that something damaging happened to information assets. This is not limited to mere detection but also includes determining the actual impact.
  3. Recover. Undo the damage that was done, ideally as if nothing happened but minimally to a level accepted by the organization. A good detection, specifically of impact, is needed to properly recover.

It is amazing how much money is spend on the first dimension and how little is spend on the other two. Yet a good information risk management consists of a good balance between all three dimensions.

  • If you are not good at detecting damage to information assets, how can you know how well your prevention is performing?
  • If you can detect an intrusion but you have no idea what they did, how can you recover?

Prevent, detect and recover is not limited to attacks from hackers, human or technical errors are as damaging as hackers.

Imagine you periodically receive a file from an external party, this file is to be processed and will result in updates to the database. A responsible organization will take typical measures like signing and encrypting the file, verifying it’s structure using a schema … all aimed at preventing damage. But what if the external party made an honest error and supplied you with the wrong file?

None of the earlier measures will prevent the damage to your database. Even if you can’t automatically detect this damage, perhaps you’ll have to wait for a phone call from the external party, you can take measures to recover. Database schema’s and the updates could be crafted in such a way that you can “rollback” the processing of the erroneous file.

Information risk management should not be limited to prevention, but balance it with detection and recovery. It should also give sufficient attention to risks originating from human or technical errors. In fact, most damage will come from this and not from malicious users or hackers.

European Identity & Cloud Conference 2013

Last weekend I registered for the European Identity & Cloud Conference 2013 organized by Kuppinger Cole.

The agenda looks very promising with topics like:

  1. Managing Identities and Access to Information for Cloud, Mobile and Social Computing
  2. Privacy, Data Protection, IT-Law
  3. Cloud Governance
  4. Beyond BYOD, IT Consumerization & Mobile Enterprise
  5. Life Management Platforms, Personal Data, Customer Managed Relationships
  6. The Internet of Things (IoT)
  7. (Big) Data Governance/Stewardship
  8. How to Build your IAM/IAG Infrastructure the Right Way – and Support Business Today

I can’t wait until May and hope to see some of you over there!