Re: Does everyone need to build?
I completely disagree with this article and take exception to almost every premise in the article. In my experience, the opinions of this author come from someone who has very narrow experience, has worked at only a few companies, and comes from a service industry. Companies buy because it's ultimately the right business case - cheaper, less risky, and has a higher probably of actually getting something live. I also believe there are business cases for build when the need is very unique, the scope is reasonably small (so the developers can really get their arms around the problem), the pre-built compents are not readily available, and/or there is an opportunity for innovative, disruptive technology to drive sales, brand awareness, or customer loyalty.
The primary argument about losing talented engineers when following a more buy centric path is just plain out wrong. Following a buy centric path, you need technical resources to configure the product, adminster the system, complete enhancements using the vendor provided tools, etc. The ability to learn marketable skills with SAP, or Oracle, or Salesforce.com or underlying platforms like Netweaver, Fusion, and Force.com are great attractors of talent.
Also, commenting on the notion of companies having to reengineer their processes to meet the software. This simplistic view comes from those who have little to no experience implementing package products. With the maturity of tier 1 (and even to a large extent tier 2 and 3 products), many variations in the execution of a particular process can be supported in the software without changing code. That's why you need configuration resources. So, many existing business processes can be supported within the package software. It is also a good thing for a company to periodically evaluate their processes and simplify them and/or adopt best practices or standard practices. Where there is a true need for retaining a unique process that is unsupported by the software, you have the option to build using the vendor's platform(s) or their APIs and a much broader assortment of development tools. I have worked with about 30 companies over my career (and seen benchmark data and project profiles on coutless others) and companies are not nearly as unique as they think they are. If you pick the right product, there should generally be less than 20 or 30 business scenarios that can't be changed because they truly provide some type of competitive advantage and are not supported by the package software. The other 100 to 300 scenarios (of an implementation) can be supported either thru configuration or some reasonable adjustments to the processes. And that's the whole value proposition of packaged software.....why should I pay substantially more to custom engineer and build something that's readily available and workable.
Products/manufacturing industries has been using package software with great success for over 30 years now and the trend in the last 10 to 15 years is for these technologies to cross over into service industries. The trend is continuing both with on premise and cloud solutions and the companies who have historically been users are not retreating from these products. With so many companies using the products, and more companies adopting them, that would tend to prove there is a reasonable business rationale for buy (including talent retention).