Do the math: your new enterprise technology may be a decade old

Do the math: your new enterprise technology may be a decade old

Summary: The process of researching, requisitioning, purchasing, installing and testing software still takes years. This needs to be short-circuited (but in a good way).


A few years ago, the process of building and deploying enterprise applications would extend over a period of months. In recent years, that expectation has shrunk to weeks, if not days. Now, in many cases, solutions are expected within a matter of hours.  If you're in an enterprise with well-established but lengthy processes and procedures for specifying, designing, developing, testing applications, what would it take to move to this more hyper-speed state of things?

Jeff-Lawson-photo from Twilio website cropped 2
Jeff Lawson, CEO, Twilio, Photo: Twilio

Jeff Lawson, CEO of Twilio and a veteran of Amazon Web Services, has a few ideas on this. He has been studying the application development workflow for some time now, and points out that many applications are even more outdated than one may think. Lawson recently shared some of his observations on the challenges for IT leaders in the age of “now.”

Take the typical corporate call center, he illustrates. “The buying and implementation cycle on traditional call center hardware is often two years,” Lawson relates. “With a two-year buying and implementation cycle, the call center you needed in 2006 and finally got up and running in 2008, was likely written three years before, based on an product architecture designed three to five years prior to that. So doing the math, your new call center - is actually built on decade-old technology. And you’re only halfway through its amortization cycle.”

That's all well and fine – unless your competitors have discovered other ways to upgrade their technology faster. “In the time you’ve spent building out a call center, your competition built one in the cloud in a few weeks and has been focusing on enhancing their customer’s experience rather than deploying hardware,” says Lawson. “They win.”

Lawson is an advocate of the cloud and software-defined approaches as tools for business agility, noting that it provides a way to stay ahead with the latest technology developments – and more. “No matter what the area, those who look to software solutions will outmaneuver those who look to monolithic platforms,” says Lawson. “Among benefits such as rapid procurement, scalability and cost savings, the cloud and software let you adapt quickly to address business challenges and customer demands.”

Contrast that to “the servers in your closet where maintenance and customization is often achieved through costly professional services and cannot easily adapt to business's changing needs,” he continues. “As customizations mount in both expense and complexity, you’ve created a one-of-a kind solution that’s difficult to upgrade and improve and finding support is even more challenging because the guy who built it left your company three years ago. This giant and costly monolith is holding back both you and your business from solving real business needs.”

By contrast, he points out, cloud and software-defined solutions “are getting better and more advanced every day because they are updated constantly - often on a daily basis.”

The good news is that today's cloud solutions can easily be adapted or integrated into existing IT infrastructures – even those heavily leveraged with legacy assets. Lawson advises that enterprises start their cloud journey by “bridging the gap between existing on-premise resources and cloud-based solutions. Enterprises are finding that they can augment existing infrastructure and plug into cloud-based services to support their legacy hardware and to quickly innovate and extend capacity.  Application Programming Interfaces, or APIs, make it easy for enterprises to access a wide range of capabilities.”

All it takes is experience, he continues. “As companies gain experience with running software and cloud-based solutions, they begin moving more and more of their operations to these more agile solutions.”

The key is to move gradually, step by step, into the cloud. A good place to start is solutions that are naturally suited for the cloud.  For example, Lawson explains, “applications that can be easily augmented by leveraging cloud resources - those that can benefit from rapid scalability, both up and down, are a good first option.” The key point, he says, is, “don’t try to force-fit an application into the cloud. Choose a few, gain familiarity and get going.  Don’t wait to be 'all in.'”

Let your IT staff  the opportunity to experiment and prototype solutions using cloud and software-based solutions, he adds. “I am constantly amazed by what developers and IT departments can build when they are encouraged to use software-based solutions to solve business needs. I’m sure you will be too.” 

Topics: Enterprise Software, Cloud

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


1 comment
Log in or register to join the discussion
  • Change is a double-edged sword

    The author makes a subtle but dangerous apples-and-oranges comparison: Proprietary solutions are proprietary solutions, and open solutions are open. If a server closet system requires costly professional services for customization, then the same service in the cloud also requires costly professional services. Moving to the cloud does not magically enable an open environment. Similarly, many services have open solutions today that IT can customize at will, but companies opt to go proprietary instead due to the costs and risks of doing your own solutions programming and difficulties of maintaining bespoke customization. Allowing IT to do its own cloud development has the same risks.

    Cloud solutions, especially proprietary cloud solutions, do indeed offer a new mode of operation as the author calls out: Incremental development of a cloud solution does indeed allow a company to progress slowly to new technology and keep close to the design forefront. However, it also subjects mission-critical operations to incremental or catastrophic breakage with no notice. When a server solution in the closet is upgraded, everyone knows that there is breakage risk, and often the old version is kept running for potential fallback, but after a time the company knows the system is stable (enough) and can concentrate on work. What happens when a cloud provider pushes an incremental update that breaks a critical call-center workflow? Where is the fallback? Some cloud services are locked to versions just like closet server solutions for just that reason, losing the advantages of incremental advancement but also losing the risks. The author is right to call out advantages, but it isn't all peaches-and-cream unless your provider is unusually diligent.

    Finally, even versioned (proprietary or open) solutions do gain an advantage from running in a cloud rather than a server closet: It is technically trivial to keep the old version and workflow available as a reserve cloud instance while migrating through an upgrade. Sometimes the costs are negligible. That just doesn't compare to having to buy a second set of server closet gear.

    I don't want to slam on cloud solutions as a way to narrow the technology gap as the author suggests -- I believe in it and think it is the way of the future -- but one cannot ignore the possible failings as one reaps the improvements. A comprehensive disaster plan analysis for mission-critical services needs to know those risks and be ready to recover.