Information technology and assurance both are commonly seen as negative costs in a budget. Deploying a new or replacement server is seen as “sunk” cost for very little gain. In the same vein implementing costly security packages before an attack seems imprudent. “We haven’t had security issues thus far” is a slogan to be plastered on the side of Silicone Valley. Sticking with legacy platforms and code bases to dodge the upgrade bullet only serve to hit you with cost later down the road. As a good friend of mine Marc states “plan to do it right first or plan on doing it again later.”
As IT/IA professionals it is our duty to track and provide these metrics. There is a platform I support that runs on Red Hat 3 due to some legacy PAM modules. The software ends up driving architecture changes to multiple sources. Take for example authentication, backup, or the more expensive hardware choices. It is incredibly difficult to find compatible servers that contain certified HBA that interface with certified drivers to a SAN. Rather than having the ability to pick the right tool or vendor we are force to go with the ONLY vendor still willing to support such an old platform.
The down-select in vendors and products leaves us with proprietary solutions that are much more expensive than industry standards. Here comes the “sunk” cost as you look to upgrade. “Well Gosh we paid so much for those MFM controllers…” And so the cycle continues.
It is against human nature to incur changes that make additional work. In the course of a task we would much rather continue to purchase legacy equipment than make the leap. That is where IT/IA leads need to provide ASTUTE guidance. This requires a long-term and standards oriented approach as you are afforded exactly one opportunity. Woe to the admin who suggested a move to floptical and then had to deal with piles of worthless media and upset admins.
My rules are as follows for ensuring that architecture is sustainable:
- Never utilize a technology that is vendor owned in your core infrastructure
- Tie yourself to a company and you are now directly impacted by their pitfalls
- A product must have been on the market for longer than 6 months
- This used to be a one year window for me, but with technology and competition there is a great deal of testing prior to deployment of new apps. With that said, be safe
- Longevity of the project or company
- If the product is open-source I read the mailing lists and get a feel for the health of the project before deploying. Likewise I look at the stock ticker or Google news of a company before purchasing.
- Open Standards do not infer valid product selection
- Do not select products that are only being produced by one source. This situation is just as bad as #1 unless you have the knowledge to implement those standards in your own product.
- Security on the front end or it will never happen
- Can’t secure your product for 1.0? Then it never will be secure. In today’s world you cannot deploy products that lack basic security controls. SNMPv1, telnet, ftp, group accounts, and many other things exist because of laziness. To implement them requires drastic architecture changes. This means you are basically buying a new product when they do. See #2
- Size of team
- I have met some incredible engineers. These are the types that by sheer determination create a masterpiece of technology against all odds. Do not buy their product. Make them an offer or attempt to buy the company. One man can provide a decent amount of vision, but one driver with a lack of vision can take them out.
- Community of fellow users
- Is there a website that has mailing lists or forums where fellow users exchange information? Kudos if the website is vendor supported, but not necessary if the community augments this. No product I have ever
- Documentation
- The most I am willing to do is sign up for your documentation site, even that is borderline unacceptable. Documentation should serve as the wallpaper plastered in server rooms and night stands of competent admins. It is unacceptable to shelter poor documentation behind the guise of proprietary information. If you aren’t willing to describe the bucket of 1’s and 0’s, I am unwilling to provide you with my buckets of dollar bills.
These are of course not set in stone, but when asked this is my going in position. Exceptions can be found, but do not justify the expense you will pay. As mentioned earlier – Pay for it now or pay for it later.
