The Modernization Imperative
Oh, those up-start startups. They think they can push services out to market faster than large enterprises because they’re smaller and more agile. Well, they’re in for a surprise.
Many big companies are embracing application modernization efforts, which allows them to be just as agile as their newcomer competitors and, as a huge benefit, take advantage of years of previous system development—and the accumulated knowledge that accompanies it.
“Digital disrupters are hitting businesses such that they need to be able to move faster or they’ll be out of business. Hence the assertion that you have to respond to demand much faster to meet the needs of today’s economy,” remarks Rosalind Radcliffe, IBM chief architect for DevOps for Enterprise Systems.
Revise, Iterate, Improve With DevOps
Some confusion may exist about exactly what application modernization is—and there’s no one answer. For example, one aspect is the application itself and modernizing it no matter where it’s running. Applications should expose APIs and microservices instead of trying to hook everything together as if they were a monolithic offering.
APIs, which allow software components to communicate with each other, are a significant part of modernization, and the larger API economy lets developers monetize them by allowing third-party applications to adopt them.
“If an organization that develops APIs opens them up to the larger development community, even to those startup companies that may be competing with them, they’re still providing back-end value. They’re still making money,” Radcliffe remarks. “In this API economy, you want to be first. You want to provide stable services that are used in all these small applications that are popping up.”
Application modernization also involves the processes surrounding the application, which allows developers to improve development and operation procedures, including standard DevOps practices such as automated testing, continuous delivery and integration. These operational development modifications can make it easier to build and then expose applications to quickly gather pertinent feedback.
“Overall, many people include as part of modernization a continuous feedback loop to make sure they’re not building and delivering a monolith,” Radcliffe says. “They’re building small functions that allow them to rapidly receive feedback and then revise, iterate and improve—or throw away and start all over again. Because these are small functions rather than large-scale applications, it’s much easier and effective to push them out for automated testing and examine the results.”
Another factor involved in modernization is being able to take advantage of currently available development skills, such as developers or recent college graduates who may have experience with different languages or solutions than those used in an organization’s typical development environment. Because they’re not working on monolithic applications, they can easily see how seemingly diverse pieces can fit together as a whole.
Application Modernization: A Common Goal
Application modernization offers organizations quicker time to market, keeping up with, if not surpassing, their competitors in new services, and leveraging years of past development, all of which can benefit the bottom line.
Enterprise developers are often cognizant of this, knowing how their applications can be leveraged to meet the demands of a faster digital economy. They recognize, for example, that some of their applications, which may have been in service for years, are monolithic and can benefit from re-architecting that allows them to follow more modern development paradigms.
“If an organization that develops APIs opens them up to the larger development community, even to those startup companies that may be competing with them, they’re still providing back-end value. They’re still making money.”
—Rosalind Radcliffe, IBM chief architect for DevOps for Enterprise Systems
“Organizations that have developer support and executive buy-in make the transformation the fastest,” Radcliffe says. “Even when developers aren’t starting the push, executives can. They can find a team that’s the most open to change and then give them permission to try something different. Either way, everyone from the C-suite to the IT department has to be committed to the overall goals if modernization is going to be successful.”
Modernization shouldn’t take place in individual development silos, however. If this happens, businesses may not achieve the goals they’ve set for themselves, thus dampening initial expectations. Employing DevOps lessens siloed development, improves agility and reduces the time needed to address feedback, all of which allow companies to respond to the market faster while building engaging user experiences. They can also enjoy a startup-like culture that brings business, development and operations together. If this is successful, modernization initiatives are more likely to receive further, long-term funding.
“Although this isn’t going to be completed in a quarter or maybe even a year, you’re getting value all along the way—no matter how long it may take. This should be looked at as an almost open-ended, continual process and budgeted with that in mind,” Radcliffe says.
Workload Scalability
Despite best efforts, businesses can’t anticipate all the different ways they may change in the future and what affect that’s going to have on their systems. Designing and optimizing services so stakeholders understand what services can and cannot offer allows for planning, as well as future-proofing systems.
If businesses are using large-scale systems, they’re going to scale one way. If they’re using the cloud, they may scale another way. The key to designing services is understanding how they can grow to deal with specific workloads as business needs change.
“You need to be aware of what you’re dealing with. Just because you made a modular component doesn’t necessarily mean it’s designed to scale,” Radcliffe remarks. “What more experienced developers bring to the table are thoughts about scalability, reliability and nonfunctional characteristics some younger developers might not first consider. That partnership involves understanding that, yes, that’s really nice, but when a million transactions need to hit this thing in a second, you can’t read that whole table into memory because, well, that’s just not going to happen. So, there are many different things you have to deal with when it comes to workload balance and scalability, and you need to consider them up front.”
Developers may build a service that has a lot of value and is highly consumable, but it should be understood that each use case may require different workload scaling. This doesn’t have to happen up front, but the service should be flexible enough to accommodate future scaling, should it become necessary.
Providing Value
It’s important to recognize that even large enterprises can be agile. It’s a matter of getting past typical development barriers to allow development teams to be faster to market, collaborative and take advantage of the DevOps process. Aside from the technical aspects of this, modernization also represents cultural changes, altering the ways people are used to doing things.
“It’s not something you’re going to do overnight,” Radcliffe says. “It’s a journey. It’s a cultural transformation. It’s an investment in the future of the business. By conducting automated testing and changing services as needed, you can more efficiently provide value. But it takes some money to get from where you are today to that improved environment. You can’t assume you’re not going to spend any money on this. But you should learn from the lessons of others. Look at other organizations’ failures and successes—and understand what’s best for your organization.”