In all of life, we try to avoid the difficult things and handle the easy things first. Sometimes, leaving the hard things is a good idea. We sometimes realize there is an easy way to deal with the hard problem, or someone else deals with it. Sometimes it’s a bad idea. Leaving a sore tooth until it needs a root canal is a bad idea that causes lots of pain.
There are many times when I’m on consulting engagements when I ask CIOs, “How much of an understanding do you and your management have about how your company makes money, thereby having a staff that knows where the money comes from and where it goes?” One of the scariest responses that I have had to that question was, “Why would I want to do this? I don’t have enough time to do what I need to do now.” My answer to that scary response is that by doing this, you will accomplish the task of having an IT organization that knows how to see opportunities to differentiate the company from the competition. Continue reading You Need IT-Business Integration, Not Alignment
Strategy for cloud automation: there are a lot of articles about the cloud and cloud computing, but I have not seen too many that discuss different strategies to consider when it comes to the automation in your environment. I did come across a nice post called “Legacy Job Schedulers: 3 Effective Exit Strategies to Consider,”1 by Jim Manias from Advanced Systems Concepts, Inc., that had some interesting points and thought it would be a great topic for discussion. Continue reading Strategy for Cloud Automation
As we look at the number of new product announcements made by tech companies each day, we notice that a large percentage never quite achieve success. In some cases, the sizzle is better than the steak, and in others, the market doesn’t need or want a specific product.
Containers and other technologies are moving administrators, developers, and even operational folks up the stack. In other words, we have abstracted out the hardware and abstracted out the operating system; next, we will abstract out middleware and eventually everything but the code to run. However, when we do that, we no longer train people to be systems engineers; we no longer have the ability to do root cause analysis. We have seen this many times in recent years, and it may just get worse. Root cause analysis is part knowledge and part tools, but most of all an understanding of the system underneath the code. We are fast approaching a time when this skill may become a lost art.