The State of the Enterprise App Portfolio

When did you last move to a new house?

When you did, did you get rid of your furniture? Decorations? Pictures? Throw rugs? Probably not. You might have taken the opportunity to replace old and worn belongings with new ones, but the bulk of your household moved with you.

Enterprise app portfolios, it turns out, are like the things that compose your household. When organizations adopt new architectures and develop new apps, they don't throw away ones that already exist. While there's always some culling of the portfolio that's taking place over time, it’s generally true that apps put into service years ago using traditional architectures are still in service—providing they continue to offer business value.

For years this has been stated as fact, though there was little data to back up the claim. No one disputes the truth of the premise, but it's nice to finally have empirical data to support it.

In our State of App Services research, we ask about the trends and technology we believe will impact the future of app services. Cloud is one. Automation and orchestration is another. But perhaps the biggest impact on app services naturally comes from the applications these middle functions deliver and secure.

So, we asked about application architectures in use and the composition of the enterprise app portfolio. 

The results will likely not surprise anyone, though the rapid adoption of modern architectures—in particular microservices—may be more than passingly interesting.

You know from a previous post that the most prevalent app architecture across enterprise portfolios today is a traditional one: the three-tier web app (36%). Close behind, however, is its predecessor: client-server (34%). Mainframes and monoliths still make up 11% of app portfolios, but modern architectures (defined here as mobile and microservices) have surpassed them, with 14% and 15% of the app portfolio, respectively.

That's interesting but breaking it down into "traditional" versus "modern" architectures is even more fascinating. For purposes of this analysis, we define "traditional" architectures as include monoliths, client-server, and three-tier web apps. "Modern" architectures are mobile and microservices.

Using these categories, we find that most (76%) use a mix of both. 

The remaining 24% fall heavily on the side of traditional architectures, with 21% using only traditional architectures for their app portfolio. The rest we might call adventurous and rely only on modern architectures. While the average number of app architectures in an enterprise app portfolio is three, a testament to the long-lived nature of some enterprises is evidenced by the 18% of organizations that operate apps in every architecture. All five.

Even more interesting is that 11% of organizations employ just ONE architecture.

Organizations maintain heterogeneous app portfolios. As they adopt modern architectures, they continue to use and integrate with apps that live in the traditional architecture category. While we expect to see app portfolio composition shift over time as apps reach end of life and are replaced by modern equivalents, this shift takes time. In some cases, a lot of time.

I would expect to see a decline in client-server before a significant decline in three-tier web, with consummate growth in apps based on microservices. But I don't anticipate the dramatic death of mainframe and monoliths anytime soon, given the tight coupling of business and applications delivered via such architectures. The reality is that digital transformation is driving tighter integration between business and technology, and 'ancient' monoliths that live on mainframes often already exhibit such tight integration.

To wit, while overall less than a third (31%) of respondents told us their apps were critical to the business, for those with monoliths comprising greater than half their app portfolio, that jumps to 38%. Clearly, monoliths and mainframes continue to generate business value, despite their potential age.

The Relationship with App Services

So why does an app services and security provider care about app architectures aside from the obvious "apps need to be scaled, they need to be secure, and they need to be fast"?

Application architectures have always have—and will continue to have—a profound impact on the way in which app services are delivered. Traditional architectures, for example, are well-suited to traditional, proxy-based delivery mechanisms such as the application delivery controller (ADC). But modern apps, which rely heavily on APIs and distributed models of execution, introduce new delivery mechanisms that often better suit the operators of such apps. Container-native options as well as 'as a service' models are often paired with modern apps. Also, web and app-server plugins (a la NGINX modules) are increasingly attractive delivery mechanisms for app services.

The reality is that microservices are breaking up the network. In doing so, it's shifting the gravitational center of delivery architectures toward the app. That's pulling some critical app services (availability and security, in particular) closer to—and in some cases, into—the app.

That's going to change how we as an industry deploy and operate app services and F5, as a provider, delivers them.