Tag Archives: standards

Three points on the costs of COTS

It seems to be quite popular to move away from custom build IT solutions to so called COTS – commercial of the shelf solutions. The idea being, that to software solution fulfil a functionality which long has been commoditized and standardized to such an extent that it offers no “competitive edge” nor core value to the business.

For most companies and organizations the office suite would be a pretty safe bet for a piece of software which is magnificently suited for a COTS solution. Finding someone who develops an internal word processor in-house seems crazy as so many fully capable solutions exists in the market.

As time passes more software seem to be included in the parts which may be commoditized and custom solutions be replaced by standard solutions to provide an adequate and capable solution to areas served by custom solutions.

The drive to COTS software seem to be a hard challenge to many organizations, as the primary driver in most COTS adoption projects seems to be a drive from the accountants and a mistrust to the IT department to choose and deliver the best fit solutions to the rest of the business.

When listening for failed Microsoft Office implementations it sems fairly small, yet the number of failed ERP projects seem endless. The scope of this post is not to address when nor how to choose COTS solutions, but just make the point, that the choice of COTS is often naive and not fully understood ahead of the decision itself.

  • When adopting COTS you’re tied to the options and customizations offered by the chosen COTS software. You should never expect to be able to force the solution to be adapted to your organization and processes, but instead be prepared to adapt the organization and processes to fit within options offered by the chosen software.
  • Choosing COTS is a strategic commitment to the vendor of the software within the scope the COTS solution is adapted to fit within the organization. Once implemented within an organization, the adopting organization is often committed to follow the roadmap and direction the vendor chooses – as the cost of switching to another solution often is large and challenging project.
  • When adopting COTS you’re committing to follow along. All versions of software has a limited “life cycle” and as new versions are released you’re expected to follow along – in the pace that’s suitable for your organization and within the roadmap offered by the vendor (in terms of support and upgrade paths).

While COTS software seems like a cheap and easy solution to many areas within an organization, the three points above seems to be forgotten too often and causes problems with the stand COTS solutions again and again.

Coming back to Microsoft Office it seems all organizations are more than capable to restrain within the possibilities offered by Word, Excel and “friends”. As the Office documents seems to be the standard exchange format, there is an implicit drive to move the organization to current versions of the software and the new options offered by new versions.

When COTS implementations fail it seems often seems, that organizations are unwilling to adopt within the options offered by the COTS software chosen – and thus breaking the core idea of COTS as a commoditized solution.

It also seems many organizations seem to forget the commitment to follow the COTS vendor, and often end up using software versions dangerously outdated, as no budget exists to update or too many customizations have been made (see paragraph above) to make it easy to upgrade to current versions.

While COTS may offer solutions to many areas in the organization, please be warned – there is no free lunch. COTS does not only come with an initial implementation price – it also comes with commitment.

PHP Coding Standards

If you’re part of a larger team developing (and sharing) code, it is a pretty good idea to have some common standards. In the PHP work, such a set of common standards include the PEAR Coding Standards. While it may be a challenge to agree on standards, it can be done – the hard part is following the standards.

One excellent tool to help you check for standards compliance is the PHP CodeSniffer. We’ve had it running for quite awhile and it seems to work as advertised. We’ve made our own (“TDC”) coding standards which is a variation over the PEAR coding standards, and checking if you follow them is as simple as running a simple command line.While it doesn’t enforce following of the coding standards, it does make it a no-brainer to check if you do follow the common standards.

The output from the codesniffer could look something like this:

mahler@mahler$ phpcs --standard=TDC Example.php

FILE: Example.php
--------------------------------------------------------------------------------
FOUND 44 ERROR(S) AND 2 WARNING(S) AFFECTING 38 LINE(S)
--------------------------------------------------------------------------------
[LINE 2] ERROR: "require_once" is a statement, not a function. No parentheses are required.
[LINE 5] ERROR: "require_once" is a statement, not a function. No parentheses are required.
[LINE 7] ERROR: Space before opening parenthesis of function call prohibited
[LINE 9] ERROR: Space before opening parenthesis of function call prohibited
[LINE 20] ERROR: Line indented incorrectly. Expected 0 tabs but found 1.
[LINE 49] ERROR: Line indented incorrectly. Expected 1 tabs but found 2.
[LINE 51] WARNING: Equals sign not aligned correctly. Expected 1 space, but found 2 spaces.
[LINE 59] ERROR: Space after opening parenthesis of function call prohibited
[LINE 61] ERROR: Line indented incorrectly. Expected 2 tabs but found 3.
[LINE 61] ERROR: Expected "while (...) {\n" found "while(...){\n".
[LINE 63] WARNING: Equals sign not aligned with surrounding assignments. Expected 3 spaces, but found 1 space.
[LINE 74] ERROR: Line indented incorrectly. Expected 1 tabs but found 2.
...