Electronics only fail when they are turned on…

I met a boat captain recently, and he was a great instructor. He showed us how to operate our boat more effectively. There was, however, one thing he said that I found interesting. He said, “electronics only fail when they are on.” That truly applies in the boating world. Frankly, you only have one set of devices operating on your boat. You don’t have multiple radar arrays; you don’t have multiple sonar systems and so on. You may, and if you go anywhere near the ocean should have multiple VHF radios, but the reality is for most boaters the cost of redundancy is greater by far than the risk of failure.

On larger commercial boats you have redundant systems. The reality of any system is it produces inside the box thinking. For example in the cloud world, the failure of a single cloud provider for a period results in the rise of the cloud to cloud failover. We need a system that can be running in two cloud providers at once. You, in fact, may if your system requires the cost of a true five-nines solution. But the problem with that is that your failure point is the operational integrity of your solution and not the actual performance of the cloud provider.

That got me thinking about the reality of redundant systems and what that means as we go forward. The reality of IT is that it is cheaper to have an single system that fails than it is to have multiple systems that are linked (or clustered) and don’t fail. Two boxes increase the availability of the solution, but it also doubles the cost.

Years ago I designed a system to help customers consider their application portfolio. Sadly it still applies, in part because the problem still exists. No one ever deployed a solution that wasn’t mission critical! Taking a hard look at your application portfolio isn’t easy. In fact, for many companies, it has never been done. Only taking the pleasure boating mentality towards the systems deployed would be a huge difference.

What do I have to have? (this is where we get into governance and regulatory requirements). There are two sides of having to have, one is regulatory, and the other is productivity. Have to is the operative word here. There are capabilities deployed in organizations today that is wasted. Solutions that are useless in fact, because they are implemented but not being used optimally. My favorite is the reality of PDF printers on corporate desktops that are running Office 2013 or later. There is an integrated PDF printer in Office applications. Why at that point have two?

I call the concept a capability map. It is truly an enterprise tool. So many customers I have worked with in the past ten years do not have one. A capability map though is more than many organizations are willing to embrace. You see it is a mixture of governance and operations. I call the concept the GovOps Tree. I have looked at building enterprise portfolios for the past ten years. During that time I have been told “they are too expensive” they “take too long.” My opening statement was “electronics only fail when they are on.” That statement, in the boating world, is truer more off than it is not right. In the world of IT, it isn’t true. In fact, it should never even be possible.

If we balance the application portfolio of the organization effectively, we become more in tune with the overall IT direction. That overall alignment then allows us to understand what is coming, what we have, and what we can change quickly.

In the enterprise architecture world, EA’s are trying to understand what the company needs from an IT and business perspective. Without a full portfolio and the governance that says you cannot deploy something with the EA approving or at least fully understanding, the reality of shadow IT and IT sprawl remain impactful. Yes, it costs money to understand your portfolio. But every time someone says I need to dot his, and your system says “we have that.” You increase the overall productivity of your organization. Every time you increase productivity you decrease the cost of deploying a new solution to replace, augment or improve a process that you’ve already fixed.

Electronics only fail when they are turned on. Frankly, it is a failure not to know what is being used in an organization. Every pocket of shareware running in your organization is one more problem waiting to happen!