Leverage, Buy, Build - the EA Simplifiation Motto

One of the key principles of Microsoft EA is Leverage - Buy - Build.  Meaning: if you want to invest in a capability, you have to invest in an existing enterprise system if it provides that capability (Leverage).  If there isn't one, then you buy a COTS package.  (Luckily, Microsoft sells a number of business COTS packages, like Microsoft Dynamics, so naturally, inside Microsoft, they get first pickings), and then lastly, you build a solution.  You should reserve the decision to build something new ONLY for those situations where building it will give the company a competitive advantage.

That's a pretty steep bar.  We set it last year, and I think we are still learning it... it is starting to completely sink in now that we are planning the next fiscal year's IT budget.  All of the projects are being reviewed, and any that writes code has to show that the code goes to competitive advantage. 

That can be difficult to do.

The easy part is Buy.  For a company flush with cash, it is simple to buy a solution.  No one will complain about the cost, really, when you consider that a purchased package is nearly always 10% of the cost of developing it from scratch, so if there are "extra features," no one will care.

On thing that is hard, for Microsoft IT, is Leverage. 

We have notoriously independent business units, and they don't want to 'depend' on one another.  So any mention of 'using another groups' code' is usually met with scorn.  This attitude has seeped into IT so deeply that it is hard to change, but change we must.

So I'm currently working on a situation where one group has a tool, and a lot of expertise, in an area where another group has a manual process.  Now, the group with the manual process wants a tool, but they don't want the tool that already exists... Oh, no, they want their OWN tool. 

IT is not built that way.  We are more like a Japanese car company.  We build something new, and it isn't pretty, but we improve it year after year, and after a while, it is darn good.  So, if there is a tool with some age on it, it may be the best tool in town.  On the other hand, it may be written in VB6 and badly in need of a rewrite as well.  Even so, it is better to invest in an existing tool, even an old one, that it is to create a new tool from scratch when the business capability overlaps.

Otherwise, you have this:

   Team A had old tool Foo, while Team B has new tool Bar.  Team A wants to replace Foo, but they don't want to move to Bar because the new tool has only half the features they are used to.  Team B won't move to Foo because it's old and because they just finished investing in Bar, and they want to get their benefit for the investment.

This merry-go-round never stops.

So, when Team C says "I want Jellybeans" and you know that they mean Foo, make them onboard to the Foo tool, upgrading the tool to meet their needs as well as the needs of its existing users.  Refactor.  Replatform.  Reuse.

Over time, the number of tools in the portfolio drops.

And that, my friends, is the point.