In the evolution of anything, product or service, a point is reachedwhere it is easier or cheaper or faster to buy it than make/do ityourself. Think of pioneers in the North American West whobuilt/crafted almost everything they needed: house and barn, furniture,fences, etc. Today, if you have hand-made ‘arts & craft’ furniturefrom the 19th century, get thee to the Antiques Roadshow to learn howmuch your windfall is worth.
As I have and will continue to note, human beings have been buildingphysical things large and small for millennia, and it is the nature ofmodern manufacturing and construction that these things are now made bycompanies for human beings to buy. Software is still very new, and itis not a physical thing, but we have already reached a point where youcan buy software for almost any business domain or function .
How did this happen? Like anything new, building the first instancesof software was hard work and usually took a long time to get it right,all making the effort expensive as well. However, once you have workingsoftware, you have a huge advantage over manufacturers of physicalthings; software can be copied instantly at virtually no extra costbeyond storage media. So, the more entrepreneurial among us thought“could I recoup some of my development costs, or even make a profit,selling this software to other companies?”
In many cases, the first main customers for a lot of software wouldhave been direct competitors, so that did not make sense at the start.However, many new companies were often spun off specifically to sellsome software, or the key developers left to form a company to quicklyrecreate and sell the same software. In other cases, very commonfunctions soon appeared as software products, like General Ledgersystems, that lots of companies could buy.
From then on, IT Projects were almost always faced with the “Buildor Buy” choice. The resulting decisions were often couched in theculture of the company and/or its IT department. Some companies startedbuying packaged software early on, while many to this day stick to a“not built here” syndrome which denigrates anything from ‘outside’. Thedecades have shown, however, that the average company will buy somesoftware, or suffer greatly if it attempts to always build its ownsoftware; only a few decidedly non-average companies can do that.
However, buying software is not like buying a Chevy. If a car modelonly comes in a 4-door design, you can’t ask the salesman to change itto a 2-door version. However, that’s what happened often when softwarepackages first entered the market. Early products were often based onone view of the business domain, the view of the people (or theircompany) who built it. So, packaged software was never a perfect fit topotential buyers. The value of buying, however, kept customers in themarket, who were then faced with a new choice: change the softwarepackage to meet your unique requirements, or change how your companyoperates to match up with functions of the package.
Neither choice was appealing. Changing a package meant doinganalysis and programming, exactly what you were trying to avoid; changethe package enough and you would also lose the ability to implementimproved versions from the vendor. Changing your business to match upwith the package… well, I don’t think I have seen that ever happen,even when that was the plan to start with; something always turns upthat the business can’t live with, so the changes begin.
But, the value inherent in buying over do-it-yourself was so greatthat vendors and customers survived the teething pains of packagedsoftware. It was not long before the vendors figured out that softwarecould be made more flexible to meet different customers’ needs.User-defined fields were offered, and look-up tables for codedescriptions, until it became apparent that packaged software had to betruly configurable, and this is where the word ‘meta’ started toappear, implying at least one if not many levels of generalization, sothat customers could define their own business to the package throughdata, rather than change code.
Packages for Life and Health Insurance had to pick up on this fast,as nothing differentiates insurance companies more than their ownunique products, so a general product definition function and datastructure had to be offered. (Insurance is actually a lot likesoftware, being intangible and subject to continuous change asactuaries come up with new twists.)
My own most recent experience has been with a Human Resourcespackage. The unit I worked for within my multi-national employer wastracking employee sick time, vacation and overtime using everyone’sinitial favourite, Excel Spreadsheets. I was assigned to look for asolution, preferably something that could be acquired at minimum cost,and not use any (other) IT resources.
As a function, HR is common to all organizations, so I expected tofind many packages to choose. I did, but not a huge number as a fewvendors seem to dominate the time-attendance niche. Armed withRequirements I gathered from a representative group of Managers, Ievaluated the available products and settled on one of the dominantvendors; their product was totally configurable from our perspective,could meet all our requirements, and was priced based on number ofusers so the cost was justifiable for the benefits we expected to get.
Now, configuration of a software system is really just anothersoftware skill in which it helps to have some experience. We decided tobring in two of the vendor’s application consultants to do the actualconfiguration based on our requirements, which took about a week.Otherwise, I was the only person on the project, I used the ITdepartment as my acceptance testers for 2 weeks, and then we went live.
Such configuration is the main feature of all the latest versions ofgood software packages, so now you don’t have to make the choice aboutchanging the software to meet your requirements; the software embodiessuch change.
Next Time: “…, Build for Re-Use”
