Digital Transformation: Rules for Thee, but not for Technology?

“Change is the one constant,” says Hericlitus, and my years of experience in the technology industry have underscored that reality. We find ourselves once again in a period of fundamental change, this time driven by the XaaS/Cloud revolution, which is even more fundamental than the mainframe to modern distributed systems of the 1990s.

The challenges that business leaders face today are skyrocketing technology budgets, talent shortages, mounting technical debt, and uncertain business results. For the past 20 years, digital transformation has meant applying technological advances to every aspect of the business except for the technology department itself. As odd as it may sound, however, it is time for CEOs to bring digital transformation to their technology department.

Technical novelty is not what is required for digital transformation of industry; it's the adoption of existing technology to digitally enable businesses that is lacking.

Despite popular belief, we are still at just the beginning of the digital transformation era, one that will  require an almost complete transformation of the technology workforce as a result of the availability of and move to XaaS/Cloud services.

Digital transformation of industries will continue, and while some are further along than others, (e.g. financial services, healthcare), the pace of change in technology will always outpace the rate of business adoption. Its advance—technical novelty, as it were—will not lead to digital transformation of any industry; the adoption of existing technology to digitally enable businesses will. Create all the technological advances you’d like, but until businesses adopt them fully, they’re useless. 

If I asked IT departments about the internet in the mid 1990's, they would have most likely warned against it. If I asked server engineers in the mid 2000’s about virtualization, they would say I shouldn’t trust it for mission critical applications. If I asked most CIO’s about Amazon cloud in 2012, they would have warned me about the risks of lack of control. If I ask many current CTO’s about leveraging PaaS options instead of custom code, I would hear that it doesn’t meet our unique requirements and lacks the “flexibility” of a custom solution. 

Shocked as you may be by my youthful appearance, I’ve been asking these questions for three decades. What I’ve learned is that many technology decisions are based on the options that exist within the capabilities of the current technology workforce, not the solutions that have already emerged that could be leveraged and cause disruption. Once the technology teams are in place, natural bias and resistance to change emerges, and advancement actually becomes a threat.

20+ years ago, talk of technology as a utility abounded, and we are now living in that prophesied reality. Forrester and Gartner are both predicting that 70-80% of all code will be built with APaaS solutions (Application as a Service—APaaS, or so called ‘Low/No Code’) during this decade, and we are already moving in that direction. Google, Amazon, and Microsoft will no doubt own the space in the future, and the technology workforce will look entirely different than it does today.

Business leaders, this means that software development, IT, and other technology teams must be rethought from the ground up. While digital business transformation is enabled by technology adoption that changes the way products and services are marketed, sold, delivered, and supported, don't forget your technology workforce will also need to be disrupted to an even greater extent. because of the advances in technology now underway. 

This is a net positive and will allow for more resources to drive innovation, data insight, information security, new customer acquisition, and existing customer service, with the excess fueling the bottom line. It’s only fair that, after decades of those of us in the technology industry disrupting everyone else's jobs, we take a healthy dose of our own digital transformation medicine.

Shooting Where the Rabbit Was

"It is change, continuing change, inevitable change, that is the dominant factor in society today. No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be." - Isaac Asimov
 

Early on in my career, when making a strategic decision on a technology or in creating a technology strategy, we would consider the tradeoffs, constraints, expected future changes, and business objectives, then arrive at decision with the business. After 3 years the decision often looked ridiculous. By ridiculous, I mean the advances in technology, pricing, and the change in available options, invalidated many of the assumptions that went into the original decision.  

I have noticed that many evaluations of technology options are static in nature, and fail to account for the dynamic changes that are almost certain to occur within the timeframe of the analysis.

So why is this a problem? It's a problem because we are in the 6 Months to stupid world, we don't have 3 years in many cases. Example: A vendor tells you that you can save 50% on public cloud by moving to an onPrem private cloud. Dig in a bit deeper, and you find that the estimated costs associated with the cloud provider are unchanging for the lifespan of onPrem alternative. 

It is possible that cloud providers will not lower prices, in the sense that it is possible to survive a fall from the 30th floor. The dilemma is that just about any technology asset has at least a 3 year life span. While the pace of change in the past made this a somewhat acceptable time horizon,  making a wise 3 year decision in the current environment is increasingly risky. 

Technology costs are going down due to competition, technology upgrades, new pricing models, and disruptive solutions. So make sure your analysis includes dynamic assumptions on pricing and available options. If I could predict specific innovations that will be coming within the next three years, I would be working at a hedge fund instead of opining on Linkedin. However, it is almost a sure thing that if you are making a 3 year decision, it better have a 6 month ROI.

What further compounds the problem is that IT organizations have a major conflict of interest in determining the "best" path forward from a business perspective. Having IT evaluate cloud options is tricky because the technology vendors' business model and the IT workforce are exactly what is being disrupted. So if the question is; "Should we host these applications and data in the cloud or refresh our infrastructure?" A static analysis of the alternatives will help those resistant to change show that staying with a legacy approach is less expensive, and have the added benefit for them of not disrupting their career. Of course this is not necessarily a business benefit. 

Business leaders need to remain engaged with their technology executive and understand the tradeoffs involved in major technology decisions and strategy. The business should be drawing the line in the risk/cost tradeoff, not just the technology leader. You don't have to be a technologist to understand the tradeoffs involved, 0r know that the technology game is changing rapidly.  If the only tradeoff you are typically discussing with IT is "sign this PO, or bad things will happen," you need to get a second opinion. Otherwise you might just be shooting where the rabbit was.

Finding the Brown M&M

Finding the Brown M&M

"He who knows how will always work for he who knows why." - David Lee Roth

I hate to admit it, but I used to be a fan of David Lee Roth. As in Van Halen, as in flying-through-the-air-spinning-back-kick David Lee Roth. The concerts were Epic for not only the music, but the aerobatics of the lead singer.

Legend has it that the contracts for a Van Helen concert were huge and complex, including detailed requirements for rigging the steel trapeze cables used for the aerobatic show. The contracts not only included this information, but everything you can imagine, down to the candy left in David Lee Roth's dressing room. In fact, it was so specific that it included the requirement that M&M's be left in a bowl in his dressing room, with the added requirement that all the brown M&M's be removed.

The first time I heard about this, it seemed to be consistent with the high maintenance narcissism of the lead singer. But this requirement served a very important purpose. In a typical tour, he may be performing in a different city every night. So if your life is on the line, how can you quickly tell whether the contractors have actually followed the detailed instructions laid out in the contract? Especially those terms relating to the cables you will be depending on to fly around the stage while you sing the lyrics to "Jump". You just look for the brown M&M's.  If you find them, you know you need to pay attention and the contractors probably did not follow the contract.

In the business world, we have our own brown M&M's to find. I find them everywhere around me in my professional life. I mean those things that make me want to drill down further,  question the assumptions, or think that someone has not read the contract. One contract, is that technology exists to meet the needs of the user or business, and not the career aspirations or interests of the technologists. If you see a brown M&M, its an indication you need to dig a bit further. 

An example of this I hear often is that an organization cannot move to the cloud because of security or compliance concerns. I once heard that IT told the business that they can't go to Google @ Work because it was not secure. Mmmm, brown M&M for sure, especially the word "can't". There may be many reasons you might decide against Google @ Work, but the word "can't" is not appropriate. I tend to believe in the saying, "there are no solutions, only tradeoffs".  The business gets to choose the tradeoff, not us.

As I dug further into this particular example, I found it was more that IT did not want to go Google. Office 365, onPrem Exchange, or Google @ Work all have their strengths and weaknesses, and the obvious winner from a purely IT perspective would be the option that introduces the least amount of change. The problem is that it really is not about what's best for IT, Development or Engineering, its about the business and the users.

Change can be scary. It can mean you get blamed for the negative experiences related to the change, your job becomes more difficult or is eliminated, your team becomes smaller, you have to retool to remain competitive in your career, or you simply won't be able to do the types of things you have come to know and love.

When someone tells you that you "can't" leverage the cloud because of compliance or security, use PaaS because its too restrictive, implement DevOPS, or use any of the other disruptive approaches and technologies out there, you may have found the brown M&M.

Cart (0)