Star Base Inc.

In part one I discussed the security issues between an enterprise and the application development teams. Part two will discuss standardization and its effects.

Standardization is a very important concept. It allows seamless communication, and quick deployment of technology. Standardizing on a singular operating system will eliminate the need for any interface or integration between application development teams. The lack of a standard process is a serious problem, but standarziation taken to the extreme is also a problem. Security is not the only reason application development teams can’t reach new technology. Someone in the organization has made a decision on what hardware and software is appropriate to use. Unapproved software is subject to disciplinary actions and even termination. This policy is in place primarily to keep non IT staff from downloading, but since there aren’t exceptions, IT suffers from not learning new techniques and technologies. Some software is exclusive to a single group and doesn’t need standardization. Some third party software only runs on certain systems, so it may interfere with your accepted software list. Change is difficult to accept. New software may improve one aspect of your business, but it may introduce a new error. One must carefully weigh the pros and cons of your new technology. You need a set of criteria to judge the effectiveness, so one can make an informed decision. The decision makers aren’t familiar with the application or the technology. If the introduced software produced a serious problem, it is the decision maker, not the application development team that would answer for it. It is understandable that decision makers use draconian measures to remove the issue entirely. On the other hand, if standards were set in stone, we would all still be using COBOL on mainframes.