In the past year, I have had conversations with no less than three network operators in which each has listed the development of their own digital signage platform as a serious option. (Long time readers will know that I am not a fan of the term “content management system”  for a number of reasons, but that is the term each used.) Generally, when you hear end user organizations speak about writing their own applications, the logic seems to boil down to the notion that it will save money and that it is not that hard. In reality, there are only two legitimate reasons to even think about writing your own software.  The first is that the needs of your company cannot be met with existing solutions. I would argue that a very close, objective mapping of the marketplace and internal processes be undertaken before concluding that your business meets that criteria. The second is that you are in possession of intellectual property that would provide your company with material competitive advantage when implemented in a software product, and you cannot risk making it accessible to others. In that case, does using the IP require starting from scratch, or is an integration project more effective? There is an awful lot to think about before turning one’s back on a fairly vibrant marketplace. Deflecting resources away from core competencies could be quite the mix up.

http://www.youtube.com/watch?v=gdM4EnALnwo

Rolling your own may have worked for Bob Marley, but even that didn’t end well. Here’s a shot at some thoughts and questions to consider if for some reason secondhand smoke causes you to equate developing an enterprise digital signage platform with a call to Domino’s. The primary arguments fall into three buckets: cost, time and risk. At times, they are very much intertwined.

Cost:

  1. The actual cost of getting a first version completed can not be known with precision. For an organization without a sophisticated IT function, doing it professionally would require outside consulting to develop requirements and specifications, manage the project, and of course do the coding and testing. And that is just for starters. An organization with big IT resources would probably have the project management skills, but would still want the perspective of consultants to help develop and write specifications. Just choosing the outside help involves time, cost and risk.
  2. Whether the project is done in-house or outsourced, the cost of development and test environments will have to be absorbed.
  3. Proper test scripts and procedures must be developed (to include every version of hardware in the field). Nontrivial, unless you plan to debug in the field.
  4. A production environment will need to be put in place, including back-up and failover. Decisions and investments will need to be made to provide for optimal cost-performance balance.
  5. Not only will server side application(s) need to be developed, but player side software as well. Critical architectural decisions on both sides will not only drive cost, but also time and risk.
  6. Documentation will have to be created and maintained, which could be especially tricky or costly if the project is outsorced.
  7. A content distribution network (CDN) will need to be put in place and tested.
  8. An internal systems group will have to be hired, housed and maintained.  This would include management, operations, tech support and development, and would represent new and significant overhead for most network operators.
  9. In some cases, thoughts of rolling their own will arise when a network’s monthly SaaS fees rise to a level that becomes a financial target. There are ways to mitigate monthly expenses while still remaining focused on core competencies. Switching from SaaS to an Enterprise licensing scheme can dramatically reduce monthly expenses, and while up-front costs would be high, they may in fact be less than the all-in costs of a development effort.

Time:

  1. The proper planning cycle for a project of this scope would be at least 90-120 days.  This is before a single line of code is written. And that clock starts ticking only after you identify the resource(s) inside your company who will drive that process, even if consultants and contractors are involved.
  2. Proper testing of the product when it approaches code completion would also take 90-120 days. Fixing of bugs would take an unknown amount of time, as the testing cycle restarts with each iteration. Are we having fun yet?
  3. Say you budget a year to get something developed, which is a reasonable place to start. What exactly will you have a year from now? What are your contingency plans if it is not ready?
  4. How will you plan to manage  the addition of evolving requirements? Has any business gone a year without a adding to its functional wish list for its core systems? Will users be left wanting when the first version is produced, or will the design/code/test cycle restart itself to accommodate new requirements? Tick, tick, tick.
  5. Completion of a development project does not stop the clock. Guess what? A plan for converting the existing network in the field must be developed and executed.

Risk:

  1. Decisions made at the outset will impact every aspect of the project for years after: development environment, operating system(s), hardware choices, virtualization, and more. How will those decisions be made? Can you think of anyone who made choices they’d like to take back? I can.
  2. How will you know that the requirements and specs are complete and reflect more than what you have today?
  3. What is the cost to your business of the inevitable delays? Will you bear the risk of releasing something before it is ready?
  4. How much senior management time will be redirected toward this project, and at what opportunity cost?
  5. What if the resulting product is not as good as what you have now or could have acquired in the marketplace?
  6. What advances will you miss out on by not being part of a commercial product roadmap impacted by the requirements of other networks?
  7. A development effort may be far outside core competency of the business, making it very risky to assume excellent results. “Good enough” implies only parity with what was replaced. How many retailers wrote their own merchandising systems? How many manufacturers wrote their own ERP systems? Why is that?
  8. If a less-than-perfect decision was made in acquiring current software, what has changed that will make a from-scratch development effort more successful?
  9. Does developing your own software in a marketplace full of commercial options make investors more eager to invest, or more likely to pass?
  10. Does adding a new cost center make you more attractive than operating a lean and focused business?
  11. If growth through acquisition is on your roadmap, having a proprietary system in place may very well make integration costs higher than a properly designed commercial offering.
  12. It is interesting to note that many of the oldest networks in place (run down the long-time DPAA members for a partial list) run on bespoke software, largely because they saw no viable commercial alternatives when they needed one. In many cases, they are now stuck with what they have, and some have found that what they have is not commercially viable itself.

Considering the path of homegrown software should be a reason to pause and reflect. It would be quite rare in our industry that a diligent make-or-buy analysis would end up on the “make” side. As the late, great Marley might advise, “there’s so much stumbling blocks right in our way.” Irie.

Did I miss some obvious arguments against writing your own digital signage software? Are there good reasons to consider it? Let me know in the comments!