The Buy-vs-Build Shift (part 1)

7 September 2012

When a new IT solution is needed in an enterprise, maybe because the business is changing or maybe because an existing manual process should be automated, the people who are in charge of implementing the solution usually quickly get to the question: should we build the solution or should we buy a package? For a long time the accepted wisdom has been to always buy when possible and only build when no suitable packaged solution exists in the market.

In this article series, which will eventually be published in this book, I want to explore the reasons behind the existing preference for buying and, more importantly, I want to challenge the accepted wisdom and explain why I believe that the changes that have occurred in software development over the last decade have shifted the answer to the buy-or-build question away from buy and more towards build. I am not going as far as suggesting that build should be the new default but I think building software should be considered more often and it should be considered even when a suitable package exists.

Part 1: Traditional reasons for buying

In my experience the case for buying software is often not made on the back of arguments that show why buying is a good idea. The usual route seems to be to analyse why building is a bad idea. This in itself says something. It is as if building is the natural answer and only problems with it make it necessary to take a different approach. So, what are these problems that have led people to preferring to buy a package?

Software development is risky

The most common argument against building software is the understanding that building software is risky. There are stories abound of failed software projects and of software projects running late, exceeding their budgets not by a few percentage points but by many times the originally anticipated cost. One way for an organisation to address this risk is to buy the software for a pre-determined price from a vendor. This shifts the risk of budget overruns to the vendor, and if the software has been completed before the purchase is made, as is generally the case with packed software, then there is not even a risk that the software will not be ready on time.

The obvious question is whether there really is something inherently risky in software development that has caused so many projects to be unsuccessful. On the one hand software development is a comparatively young discipline, at least when compared to architecture, in the building houses sense, or to industrialised production of goods. Consequently, there is less experience, practices are not as established, and many ideas and concepts have not been turned into repeatable processes. On the other hand, though, software is flexible and infinitely malleable. With the right techniques it should be possible not only to produce exactly what is needed, but it should also be possible to use parts of the software before the whole is finished, and it should be possible to adapt the software to a changing business environment, all of which are would reduce the risk of a large capital expenditure.

From an organisational perspective the real question is even slightly different: whose risk is actually reduced by buying software? In many organisations the department responsible for building or buying software, the IT department, is separate from the department that uses the software, the business. The IT department is often measured more on delivering on time and on budget than on the overall cost or potential realised. So, for the IT department there is little to no incentive to build because buying shifts all the risk in areas that matter to the IT department onto the external software vendor.

For the business, however, the situation is quite different. Not only is it possible that custom software may have been cheaper, therefore providing an earlier return on the investment, but it is also possible, and not uncommon, that the software package does not do exactly what the business needs, leading to decreased productivity and lost opportunities. Of course, these concerns should be addressed in the decision making process. Unfortunately, the process is normally run by the IT department, which is set up to care more about different risks. As a result it is possible that the selection and decision process minimises the risk for the IT department but does not optimise the solution for the organisation as a whole.

A good example of this conflict is the introduction of a CRM solution at Australia’s largest telco. A system was bought from one of the market leaders, clearly reducing the risk for the IT department, but as a newspaper reported “[…] dealers at the coalface of the telco’s retail chain are still saying the clumsy customer and billing platform at the heart of the company’s multi-billion IT transformation is costing them business.”[1] Minimal risk for the IT department clearly did not translate into an optimal solution for the business.

If the business may really be better served by building, is it possible to take the risk out of building for the IT department? To start with, major breakthroughs in development methods over the past decade have resulted in much more predicable software delivery. Processes built around the agile value system deliver working software in small iterations, not only releasing functionality incrementally, but also giving the business a chance to provide feedback and, if necessary, allowing the developers to adapt the software. This greatly reduces the risk that the software does not meet the needs of the business. Software development teams have gained the ability to react to changes and develop software iteratively through techniques and practices as those described by the Extreme Programming and Continuous Delivery methodologies.

More intriguingly, it is possible to reduce the risk by shifting the goal. What if the main goal was no longer to deliver a large number of function points in a pre-determined time and budget? What if the core goal was to deliver the most needed functionality at any given point in time as efficiently and effectively as possible? Again, agile practices would clearly help, but how crazy is this idea? In 1982 Tom DeMarco opened his hugely influential book on Software Engineering with the line “you can’t control what you can’t measure”. Interestingly, in an IEEE paper in 2009[2] he writes: “For the past 40 years […] we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.” I could not have said this any better.

Software development is inefficient

Another common argument against building software is that it takes a lot of time and effort to implement. A business function that can be described on a couple of pages requires several hundred lines of code, which take a developer weeks to write and test, and yet more time to be deployed into a production environment. Complex systems that can only be described on several hundred pages require years to be implemented. One obvious answer would be to live with the inefficiency but at least to reduce the time by putting a larger team to the task. Unfortunately, it has become more than obvious that the speed of software development does not scale with the number of people on the team. At some point the communication and coordination overhead cancels out any further brainpower.

In the same way that buying a package shifts risk to the vendor, it shifts the problem of efficient delivery to the vendor, too. The buyer simply has to run a tender and procurement process and oversee installation of the software package. (I will return to installation in part 2.) Moreover, when multiple parties buy the same software the vendor can spread the cost of development across all buyers, thus reducing the impact of the inefficiencies for each buyer.

Is software development really so tedious and inefficient as proponents of buying suggest? And what could be done to make software development more efficient? In his 1987 paper Fred Brooks explains why “there is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity”. He adds, though, that “many encouraging innovations are under way” and that “a disciplined, consistent effort to develop, propagate, and exploit these innovations should indeed yield an order-of-magnitude improvement.” I believe that he was right and in the 25 years since he wrote this paper huge gains in developer productivity have been achieved.

Brooks makes an important distinction between essential complexity and accidental complexity. Essential complexity is the complexity of the business problem the system is implementing. It might seem that there is nothing an IT team can do to reduce essential complexity. They cannot and should not change the business. Interestingly, though, in projects with long cycle times (years) there is a tendency for the business to be somewhat speculative and request all functionality that they can think of because of the worry that if they leave something out of the requirements it will not be delivered for a very long time. With prioritised iterative delivery the business can halt a project when all features that are actually needed have been completed. Of course, this does not really reduce essential complexity but it does reduce the amount of features that are implemented, and based on my experience, quite substantially so.

Returning to Brook’s distinction, accidental complexity is the complexity caused by the tools and techniques used to implement the system. This is complexity that would not exist without the implementation. As Brooks predicted no order-of-magnitude reductions in accidental complexity have occurred. For example, there is no widespread use of expert systems or graphical programming environments, and it is not for a lack of trying that such tools do not exist. End-user programming, or automatic programming as Brooks called it, is not in widespread use either, maybe with the exception of Excel spreadsheets. However, domain specific languages are a promising current development that has the potential to achieve some breakthroughs in this area.

One area that Brooks underestimated are integrated development environments (IDEs). The capabilities a modern IDE provides in areas such as code navigation and automated refactoring have resulted in impressive productivity gains. Automated refactoring in combination with test-driven development have made it possible for developers to achieve high internal software quality with less effort, thus not only increasing the efficiency with which code is written initially but also making the pace of development more sustainable as the codebase grows.

Developer workstations have become substantially faster, allowing for more complex IDEs and tools. Improved compilers, for example, create more optimised code without developers having to worry about details such as register allocations. The major productivity boost in this area comes with the fast internet connection, though. Rather than experimenting or discussing problems on mailing lists and newsgroups, developers can now access online communities that provide answers to many common development issues within minutes, either because previous discussions of the problem are easily searchable and accessible or because peers answer in real-time using internet relay chat (IRC).

The improvements in hardware obviously do not only affect developer workstations but they also impact production environments. In many cases it is now possible for developers to trade some wastefulness of resources at runtime against increased productivity at development time. For example, instead of spending effort on writing code to manage memory, developers can reduce the accidental complexity associated with manual memory management by employing an automatic garbage collector. There is a line of argument that on modern hardware automatic memory management even increases efficiency due to higher locality of reference and better resulting cache use, but even if automatic memory management is slower, the trade-off is worthwhile in all but a few specialised areas.

Lastly, Brooks and many others in the early nineties envisioned a thriving commercial market for components, creating a middle ground between buying complete packages and writing the entire solution. By and large such markets have not been overly successful. There are exceptions, but in general these markets have been superseded but something even better: open source frameworks. Many developers and development organisations have found that sharing the source code for basic building blocks did not harm their organisations, by helping the competition, but instead helped the organisation by gaining free development capacity from other collaborators. A further benefit of frameworks that are created directly by the practitioners is that their feature set is determined by actual needs and not driven by feature checklists. Innovation extends to the public sites on which the frameworks are maintained, enabling ever more flexible and effective ways to share code.

Software development is not our core competency

Over the last 30-40 years software solutions have reached more and more areas of businesses but it is important to remember that they started as tools providing operational efficiency in certain areas. It is maybe that background that has led many organisations to believing that software development is not part of their core competency. Sometimes people refer back to examples from the early twentieth century when factories had their own electricity generation facilities. The analogy is clear: factories switched to electricity off the grid as soon as that was available because generating electricity was not at the core of their business. Their core competency lay elsewhere, in the production of cars for example. So, why should an enterprise that, say, specialises in managing insurance have competency in software development? In fact, with cloud computing the question that is being asked is whether many companies should have any competence in IT, or whether they should move it all into the cloud, much like the factories moved their energy problem to the grid.

This issue is different from the two issues discussed previously. The assessment of risk and efficiency is changing because of advances in the way software is developed and delivered. The question of competency is mostly affected by how the businesses are changing. Software solutions are no longer just tools that make it possible to run a certain business process more efficiently. Software solutions have become enablers of completely new ways of doing business.

About 25 years ago a newspaper benefitted from electronic desktop publishing, but, still, this only made the process of laying out the pages more efficient. There was little reason to write bespoke publishing software. Today, as much of the business has shifted onto the web, the software behind the newspapers’ websites has become strategically important to their business. For example, the audience is no longer just the loyal reader of the paper. It is equally the person who arrives at an article via a search engine. If the website can provide easy access to related content, the visitor will stay longer, see more adverts, and therefore increase revenue for the paper. Providing compelling content is still a task for the editors and writers, but making it available at the right time in the right context is a function of the software.

The newspaper example is just one of many. The trend for software to become a strategic enabler for the business can be found in many domains and verticals. Now, if a piece of software is strategic to a business, the result of choosing from the same set of packages as the competition should be obvious: little or no competitive advantage. As discussed before there may be less risk for the IT department by buying a package, but it certainly will make it much harder for the business to get an edge over the competition who can chose from the same packages. Even worse, though, reacting to change or implementing a brilliant new idea will take much longer if a product and an external vendor are involved. Cycle-time, that the time between having an idea and seeing it running in production, can be reduced by having a well-oiled IT function that uses practices and techniques from Agile methods and Continuous Delivery.

It seems that even if software development was not a core competency for most companies it is rapidly becoming strategically important for many to make software development a core competency. This may require some painful changes and a shift in corporate culture, but ignoring new realities has rarely helped either.

In part 2 I discuss issues with buying, traditional issues and new issues that have emerged over the past 5-10 years.


[1] Mitchell Bingemann, “Dealers still fuming at ‘clumsy’ Telstra system”. The Australian, 2 June 2009.

[2] Tom DeMarco, “Software Engineering: An Idea Whose Time Has Come and Gone?” IEEE Software, July/August 2009.


  1. Kari

    10 September 2012, 17:56

    Before starting to read, let me say that the font you use is almost unreadable. I am going to copy the article to an editor and read it there.

  2. Einar

    10 September 2012, 18:19

    Change font. Note the complete lack of ‘please’ in front ;)

    The article is interesting, but the font just hurts. Can’t read past a couple of lines per paragraph before giving up.

  3. Randy

    10 September 2012, 18:45

    +1 on the font :/

  4. David Lojudice S.

    10 September 2012, 18:50

    commercial market for components: heroku add-ons! agregated by heroku or not, these cloud services are now all over the stack, from infrastucture to business services.
    It may not be that common to see it been used on corporations, but it is a matter of time. For those who already does used it, are now able to (1) cut infrastructure time / cost / burocracy (2) have as many functionalities as your money can buy, as Brooks had predicted (well… almost :D)

  5. Travis

    10 September 2012, 21:02

    “It seems that even if software development was not a core competency for most companies it is rapidly becoming strategically important for many to make software development a core competency. This may require some painful changes and a shift in corporate culture, but ignoring new realities has rarely helped either.”

    I would be interested in seeing you elaborate on how an established non-software business can go about making software more central to how they do business and compete.

  6. Clojure « Daniel Kokott

    10 September 2012, 21:14

    […] d. 10/09-2012: Jeg blev opmærksom på denne artikel idag af Erik Dörnenburg: The Buy-vs-Build Shift (part 1). Den beskriver hvordan argumenterne for at købe standard produkter frem for at bygge selv, er […]

  7. Erik Doernenburg

    10 September 2012, 23:57

    Apologies for the font. I started using custom fonts and was foolish enough not to test on Windows. Should be better now.

  8. abstractspoon

    11 September 2012, 08:35

    I wanted to read this but after the first paragraph I found the font too punishing on my eyes.

    BTW, to me the font is very blocky with thick stems and a compressed width.

  9. Wout

    11 September 2012, 11:30

    This article needs some numbers and facts to support what you’re saying.

  10. Geoff Vader

    11 September 2012, 11:40

    I’ve two points to make:

    1. I think that as younger more tech aware managers start running companies and departments traditionally run by baby-boomers the idea of building software is less mystical and therefore something that’s becoming more accepted. The development of mobile ‘apps’ is also kinda bringing the idea of SW development to the masses.

    2. In my experience it is often IT departments that do want to build and it is the business that wants to buy. Although this contradicts what you said in some way it’s often the case that IT gets blamed for failed projects even if it’s bought software. So they might as well build it and be the masters of their own destiny. There is also an increased chance they’ll deliver exactly what the business wants. The trouble is the business has already been targeted and sold a promise by some software sales guy.

  11. Erik Doernenburg

    11 September 2012, 12:25

    @Wout What kind of numbers and facts are you after? I wrote this as an opinion piece describing what I think is a bigger trend. It is based on observations and experiences I made as a consultant over the last decade. If you trust me that I didn’t just make it all up, what numbers and facts should I provide?

  12. Richard

    11 September 2012, 13:25

    I think this article, really hits the mark.

    I have worked in a number of environments where either bespoke software would have been cheaper than a package, but no real investigation of requirements has been done, and either money is paid for unrequired functionality, or the software does not do as required.

    Alternative a “configurable” piece of software has been bought, which is then configured at great expense by the software house’s consultant. And then the company is trapped as new versions do not support these features and reconfiguration is required.

    On the font front :-) for me it was hard to read because of the harshness of white and black, but then I suffer from Irlens.

  13. Andrew Johns

    11 September 2012, 14:03

    +1 for Geoff Vader’s comments, it’s frustrating how often IT gets overlooked in businesses where IT projects are directed by a non IT focussed director, who recruits Information Architects to devise solutions to problems, but the result is usually to introduce a system that isn’t right for the business.

    IAs and businesses will talk of IT being reluctant to change, that they’ve been assured by the solution provider that it can do everything they want, but this is rubbish. Most IT staff I know are happy with new technology, even if in the short term there is an overhead to learn about it. IT staff usually spot a fundamental flaw in the proposed system quite early on, that somewhere down the line, a requirement will come up which requires you to shift away from the bought solution and back to a built one anyway, but their voices aren’t normally heard by upper management. It’s fine when you’re dealing with a small system with minimal cost, but when you are talking about a large cost solution, the risk of using an off the shelf solution rather than a bespoke one becomes much greater.

    Even for those businesses where the core competency isn’t IT, it’s better to hire someone to build it from scratch, based specifically on your needs, rather than hire someone who will is planning to bring an existing product and tailor it to your needs.

  14. mtcoder

    11 September 2012, 14:26

    Another key component is easier development options. What use to require mainframe level programming is now stuffed into a drag and drop control. This pulls down the level requirements of the programmer, and provides a wider and cheaper pool of application developers that can handle 95% of the market needs. No they won’t be able to code some insane application, but most businesses just need some basic automation, that custom fits their needs. Key example just recently we went to look at point of sales software. I suggested let me try and build it, nothing fancy about popping a cash tray, they all just take a sequence of code to pop them open. Shortly later on I had a working system, with about half the features in the pack we were looking to buy, but at about fourth the cost and it’s a custom fit, that included things no software offered, cause we aren’t mainstream retailer.

  15. J. J.

    11 September 2012, 14:54

    There is another reason for buying software over creating. The hunter verses herd mentality. In order to create software, your managers have to have a clear, and decisive business process in mind. They must know their industry from the inside out. Only then can the IT staff translate this vision into a tool to facilitate their desired process flow. This allows the company to use its resources to hunt for the best business techniques and revenue opportunities.

    If the management does not have this maturity, then purchasing software allows managers to follow the best practices of the industry. This is best called herd management. It’s safety lies in the fact that management failure can then be blamed on the software imposed process. This is a safe path for new managers, and can be correct choice when the software requirement is not critical to the actual profit making function of the business. An example might be when starting new internal support department.

  16. Peter John

    11 September 2012, 15:31

    Buying can get you to production quicker. But you lose a lot of control over the system. You have limited control of where the system is going. And if you have multiple systems from different vendors you will find it difficult to keep them in sync.

  17. Will D.

    11 September 2012, 15:46

    @Geoff Vader: As a borderline boomer (born in 1957) there is nothing mystical about software development top me, I’ve been doing it for over 30 years. The issues, I believe, revolve mainly around project management and the unrealistic expectations set up by Microsoft and friends.

    Project management back in the pure waterfall days often resulted in multi-year projects that never came to fuition. I once worked on a project that was the fourth iteration in nine years attempting to replace an application. The backlash to that has resulted in the Agile religion is, as often as not, an excuse to work in an undisiplined manner with little attempt to get it right the first time because we can always do it over and over. Meanwhile, the user community demands almost immediate access to a semi-functional UI which results in applications based on a thin facade eventually sitting upon an shaky after-the-fact foundation.

    Thanks to Microsoft marketing, managers are lead to expect applications resulting from dragging a few pictures around an IDE. They muddy the water by pushing (without distinguishing) both their RAD technologies and SOA. The instant apps with direct database access do not adhere the principles of a Service-Oriented Architecture.

    Finally, weak IT management, who either cannot or will not push back against the paradigm in which the start and end dates are determined before any analsys is started results in projects that must be completed in the time available instead of the time needed. Those organizations that rely on consultants (of which I’m one) are far too quick to abdicate their fiduciary responsibilty over them. And there are far too many consultants with agendas that are not in their clients best interests.

    Thirty years ago I learned “Garbage-In, Garbage-Out” and I think that most of the disappointment with home-grown applications can be traced to that principle.

  18. Indeed

    11 September 2012, 15:57

    Change the font, please. :)

  19. Slam the Man

    11 September 2012, 16:39

    Having worked on both sides of this IT equation as an in-house developer and development manager in a Bank and then to the Software vendor side of the fence I think I have a pretty good understanding of the issues.

    The business usually sees internal IT as a bottleneck as they are always too slow in delivering what is required. This is usually due to being under-resourced. It is often hard to justify having enough in-house developers when software development is not a core business activity. Business departments will usually have a budget allocated with which they are entitled to spend on internal resourcing of projects or external vendors usually in the form of software packages. They seem to usually all share the same mentality that buying a software package means they will have their software as easily as installing Microsoft Office. The thought of having to then have a team of consultants install and configure the software over months or years never enters the equation, neither does integration with other pre-existing systems.

    Sometimes IT might be invited to weigh in on the software package decision but they are soon excluded as they start putting up too many roadblocks like “all of our current systems are windows and SQL Server yet the new package is Oracle on Solaris, how are we going to support it? How are we going to do data exchange/integration?”, etc. Also the packages quite often use proprietary data stores or structures to make moving away from it as difficult as possible so even the simplest data extract for reporting requires a consultant. This makes perfect business sense for the vendor.

    I have witnessed first hand multi-million dollar disasters that have enormous sums of money thrown at them to make them work to try to save face which then have support contracts bound in to the terms so in-house developers cannot touch it even when we know exactly what to do. While working at a bank, they would fly in 2 developers from over east for every interest rate change which would cost $50k every time when that would have paid for the annual salary of a developer (at the time) who could have been committed 100% to the system (written in Visual Basic).

    The main problem with these projects, whether in-house or external, is usually due to the “big-bang” delivery approach. Small, incremental bites, including working prototypes has always had the best success rate. As an external vendor I can say this is the lowest risk approach and while the client may end up spending more than their original budget, they keep coming back as the are happy with the delivery mechanism that keeps them looking like a winner to their internal management.

  20. zizz

    11 September 2012, 17:34

    Interesting. I do agree that off the shelf is not always the answer and what is key is the best solution for the requirements.

    I think a lot of the trend to off the shelf stems from the problem of it being difficult to find very, very good developers and project managers.

    I’ve been lucky that i’ve got a good track record of delivering to time and to budget, but the problem is i’ve been called in to many software projects where they have been failing because of poor development/project management and asked to recover them. This is giant shame because when done right it gives small companies and charities massive efficiencies. One system i have worked on has been built has saved over a hundred thousand pounds over it’s life to a small charity.

    The main problem is – are there enough good developers to go round non-software companies to achieve the build of what these companies need.

    Can’t wait to read more!

  21. Anonymous Coward

    11 September 2012, 19:47

    I think it’s a bit more complex than that. You shouldn’t buy software, you should buy software development services.

    If you buy software, you get what’s available, not what you need, and the many small deviations from what you need, coupled with the closed nature of commercial systems quickly become painful and expensive.

    If you start developing software in house, you need to set up/acquire staff, infrastructure, processes and knowhow which is expensive. The Standish Group’s Chaos Report is well known, and there’s a very small chance that you’ll be able to evade statistics better than companies for which developing software is the core business.

    Buying software development services, however, saves you most of the headaches of both developing software in house and buying software. Ideally, you get exactly the product you need, while not having to set up anything, and you get to keep all the business-specific knowhow built up in the process – provided you do it right.

    What does “doing it right” mean, in this particular case? Just a few simple things most companies fail to observe.

    First, when you outsource software development, you don’t do it to save money, you do it to get access to knowledge and skills you don’t own. Being cheap will get you just that: low quality services. Therefore, shop carefully and thorough. Selecting the wrong provider for a software project often means restarting the project.

    Second, since you rent skills and knowhow you don’t possess, use them for what you got them. The provider you hire has most likely implemented solutions like the one you need dozens of times – or else you probably didn’t hire the right provider. OTOH the provider has no way of getting to know all the quirks and intricacies of your business processes other than you telling him about them. Therefore provide them with a problem to solve, not a solution to implement, and invest the time and effort to understand the solution they provide. Not doing this is the safest way to kill such a project.

    In direct relation to the idea above is the fact that the service provider knows better than your IT department what works. They get to peek into the IT infrastructure of dozens or hundreds or even thousands of customers. Of course, they won’t lay out every single detail of the IT infrastructure of all of their customers for you, but they will definitely use all this knowhow when they’ll come up with a solution for you. Your typical IT department has no way to get their hands on such knowhow. This might not seem right for many companies. I’ve seen lots of companies going “all of our infrastructure must use”. This is plain stupid. For one, you’ll always need something that’s too expensive to develop, but only runs on RoR while you’re standardized on Python, therefore uniformity in the IT infrastructure is an unachievable dream. Second, most successful companies run a heterogeneous infrastructure, allowing them to get the best tools for specific tasks regardless of technology.

    Third, the provider has refined and optimized his processes for software development beyond what any internal IT department usually does, simply because better processes are in a direct and strong relation with the bottom line for a company doing software, whereas your internal IT’s processes have a much lower impact on your profits (unless your business is IT). Also, the processes which work for the internal day to day IT chores, or for the occasional iternal and small project will most likely be an awful fit when you do a larger project with an eternal provider. You don’t have the necessary expertise to organize such a project, the provider has acquired it via the many projects done until you came along. Therefore, listen to them, and do things their way. Unless you hired the wrong provider, you’re going to win big on this.

    There’s also an indirect benefit from outsourcing software development: better transparency and more direct feedback – which many companies use to strangle the service provider, instead of reaping the benefits. Working with an external provider will require more formal checks and controls, and people on both sides are more likely to apply them rigorously than in case of an internal project or in case of the purchase of a packaged system.

  22. Anonymous Coward

    11 September 2012, 19:50

    Sorry for the misspellings – the tablet’s keyboard still needs a week to get here.

  23. Mike

    12 September 2012, 03:19

    Good article. A few thoughts I’d like to throw out there:

    1) IT as a strategic enabler. I don’t think it is just IT creating new opportunities: I think it is the nature of what it deals with. Electricity doesn’t really carry any knowledge around it just makes things go, steam, wind, burning something could just as easily power the factory.

    What makes IT different is the I part: information. Businesses thrive on it decisions (hopefully) are based on it, markets to go after, relationships to build with customers etc. IT makes that information analyzable.

    2) Open source frameworks: I’d agree with frameworks. But applications are another thing often. Too often open source projects stop at the point where the developer loses interest. So the feature list contains the parts of the product that the developer wanted, or worse the parts of the product that were fun for the developer to work on. One of the first things to go is useability in my experience. A developer is fine stringing together obscure command lines to make things go, a well designed UI that guides the user through the tool … not so much.

    3) IT shouldn’t simplify the business … not so fast. While it is true that the IT department shouldn’t tell the business what it can and can’t do. “I don’t care that your customers all use Linux and you want it on the desktop here “WE WON’T SUPPORT IT” (caps intentional, IT often speaks with the voice of God about things that are really possible but they just don’t wish to do).

    On the other hand though: a lot of businesses are complicated because no one really thought of a better way. Think of Amazon. One of the earlier e-retailers: shop online so you need minimal inventory and no time wasted getting hundreds of stores laid out each season. Then someone (maybe in engineering, maybe marketing) said “Hey why are we shipping books everywhere. We have a website what we need is a nice device that people can read things on so they don’t have to wait for the mail.”

    I’m not saying IT necessarily came up with the idea for the Kindle but there are a lot of businesses interacting with customers and suppliers in a particular way because “that is the way it is done”. The business system is often complicated not because it needs to be but because it historically has been that way. IT can sometimes step in and say “why don’t we just let the customers tell use what they want and build it that way rather than build it and hope they like it” (Dell), how about using information like a person’s location rather than expecting people to seperate the viewing “coupons” from where they are/want to be (Groupon, sites offering suggestions based on location etc).

    In short IT shouldn’t dictate to the business what business they should be in but at the same time business structures and practices are not handed down from heaven and unquestionable.

  24. Steve Whitty

    17 September 2012, 11:14

    I would like to challenge your opening assumption:

    “For a long time the accepted wisdom has been to always buy when possible and only build when no suitable packaged solution exists in the market”

    This is an out-dated view of Business Transformation, companies that still follow the Reuse-Buy-Build mantra probably lack a decent in-house Solutioning function which is probably due to the lack of a good Architectural function.

    As to the Buy vs Build argument, again, a good Solutioning process that investigates the available options that would satisfy the actual Business Requirement would probably include options that covered Reuse, Buy and Build as well as various hybrids. An important element of this process would be the ability to understand the risks and costs (TCO) of each solution.

  25. Buy vs Build: Driving from the problem at Mark Needham

    17 November 2012, 17:57

    […] colleague Erik Doernenburg has written a couple of articles recently discussing the reasons why people buy and build IT solutions and one part in particular resonated with me: it is also possible, and not […]

  26. Core Competency at Mark Needham

    24 November 2012, 13:44

    […] my colleague Erik Doernenburg has a slightly different take on this where he considers whether software development as a concept is a core competency and explains how for publishing companies it now needs to be […]

  27. Barrett Raymond

    31 December 2012, 10:16

    Bespoke software development in standard isn’t directed at the plurality of the market but to particular vendors and corporations or groups.

  28. Taming the Hippo (CMS) Beast |

    12 January 2013, 18:06

    […] a product, or the platform will often dictate and limit your ability to do things. My colleague Erik Dörnenburg has been writing more about this […]

  29. The Case for Packaged Software | - Insights from an Intrapreneur

    29 October 2013, 13:01

    […] many opinions when it comes to custom vs. packaged software. Erik Doernenburg made a great case for custom developed software. He laid out the following […]

Leave a comment