Coming from Great Britain to live and work in the USA it still strikes me as curious that people would describe how they had “built their house.” In the UK – where people would say “bought a house.” When you are getting a new house, in both locales home buyers would pay someone to build it. The contractor would offer choices of kitchen and bathroom fittings, floor plan, interior layout, landscaping and so on.
In the field of electrical systems interconnect software over the years I wonder how customers have bought or built a software suite. Even where the most substantial part of the work is done by a commercial off-the-shelf product – you can find home-grown utilities.
Fact number one is that there will always be a mix of insourced and outsourced data processing in this domain.
There are plenty of reasons there are substantial advantages in selecting a commercially available best-in-class offering to do the job. Don’t build what someone has already put the effort and R&D into. That’s one maxim which many CFO’s have in mind.
Nevertheless a perception that grows on my customers is home grown ideas and home grown code is best. I’ve previously written – over a year ago now, about how it is relatively simple to assess your organization’s needs in evaluating software. So why do potential customers use home grown tools so extensively after a decade or more of vendors offering – for example with Mentor Graphics’ CHS – maturing, expanding coverage and improving year by year – release by release?
The answer seems to fall into one of three alternatives:
1) The functionality is not good enough in some respect to compete with a custom solution written by experts in-house (equivalent or greater competitive advantage or functional coverage can be achieved at same or lesser cost). Quite often the internal computing and information services staff who have a reputation as innovators and problem solvers also take leading roles in criticizing and questioning the efficacy the vendor’s products. Looking at what tools “should” be used in the future is not a zero sum.
2) Bought-in software to a greater or lesser extent fails to live up to promise. Implementation is problematic, change in process is more difficult. As part of the compromises forced by hard reality custom code, consulting-ware and necessarily in-house utilities get introduced, like the mortar around bricks in a wall. Over time the make-in-house drift becomes stronger for it is easier to devise a short-cut step with your IT group on the doorstep – than wait for an enhancement process of the vendor to work in your favor.
For short let’s refer to this view as the pragmatic-expediency decay of lofty expectations scenario. No – just kidding.
3) Each organization with an electrical design process is a 1-off. A generic tool designed for the whole industry means that there is configuration and customization to fit to the processes and needs of the individuals deploying the software. Then you have an industry-wide “best practice” imposed and this leaves no room for the leading lights, the smartest people, the ones at the leading edge of competitive advantage. Prowess in operating an off-the-shelf software system, as an early adopter company or later is not, where the competitive advantage lies. Winning new business, getting ahead of the competition means innovating with your own expertise and capturing that know-how in your own intellectual property and inside your own software tools.
Good choices and successful implementation makes for a tremendous difference.
I think there are truly good reasons to balance all three beliefs with an alternative counter-belief. These views are honestly adhered to and that they are held by principled and talented people of good faith who add value to their organizations. A legitimate question to ask is: would you add as much value if working with the same vim and persistent energy to ensure the success of a class-leading commercial off-the-shelf tool using an application programming interface?
If the vendor is at fault and has supplied a substandard solution, or the wrong tool was selected and the core business value and attention of leadership is elsewhere you still have to get the product out of the door somehow. Sketches on napkins, spreadsheets and hiring more employees loom darkly in the imagination of executives and managers, give the engineers at the sharp end that sinking feeling. When will they see daylight and their families again? Then comes along a saving programmer writing code like a glitter fountain firework showers sparks on bonfire night. Who later would want to to be courageous and look at the advantages of superceding what is built internally and buying an off-the-shelf replacement?
In future posts I’ll explore more aspects of the “build your own” or “buy and own” choices. This can be a prickly subject to discuss. Prestige, careers, profitability and reputation are based on the right choices. If you want to flirt with controversy and enter the debate via comments, be my guest.