Over a million developers have joined DZone.

5 Trends Driving Change in App Architectures

DZone's Guide to

5 Trends Driving Change in App Architectures

· Integration Zone ·
Free Resource

Discover how you can get APIs and microservices to work at true enterprise scale.

From mainframe to client-server to web-based to cloud-oriented, application architectures have evolved.  Now, the cloud services market will be over $100B in 2012 (source Gartner) and IaaS is set to grow 45.4% – extremely fast in a tough world economy. This growth means companies are prioritizing cloud services and evolving application architectures very quickly. From the viewpoint of our customers, we see five key themes driving change in IT application architectures:

  1. Systems of Engagement
  2. Pervasive Frameworks
  3. Expanding Application Usage Types
  4. Data Explosion
  5. Cloud Economics

1.     Systems of Engagement

Today, every business is a software business. It doesn’t matter if you’re in the most low-tech industry imaginable; the better you can use software to engage customers, partners, suppliers, and employees, the greater your competitive advantage.
Businesses worldwide are realizing this fact. They are shifting their attention from Systems of Record — the packaged applications for CRM, HR, and supply chain management that underpin their business process — to Systems of Engagement. These are new applications that often connect to existing Systems of Record, but are designed to be widely used, highly compelling, very productive, and a game-changer in terms of growing revenues and driving down costs.

Some notable examples of Systems of Engagement include:

  • Southwest.com – this web application and its iOS and Android siblings are designed to ensure strong user satisfaction and high conversion of visitors into buyers. They’re more widely used than the system of record (traditional ticketing applications) used by travel agents, and because they’re self–service they help drive down costs.
  • Uber – this mobile application for iOS and Android transforms the experience getting a taxi. No longer do you need to hope for an empty taxi to pass by or wait on the phone for 15 minutes to find a cab. A couple of clicks on your mobile phone, and Uber sends the closest taxi to you. It’s much more efficient than the system of record (dispatcher software) it replaces.

If Systems of Record power the business, Systems of Engagement are the business. Look to hear more about them, as they’re predicted to be one of the top CIO issues for 2013.

2. Pervasive Frameworks

But application frameworks impact much more than productivity.  Application frameworks are the first of a cascade of decisions about how an application is built. For example, if we’re a Java shop, we don’t just choose Java and Spring. We also choose containers to run that Spring code. We choose databases and messaging that Spring supports out of the box. We choose monitoring and management tools that support Spring and our databases, messaging and application containers. We choose operating systems that support all the components running on top of them. And we choose virtualization solutions that are tied into our monitoring and management solutions.As companies increasingly understand the importance of Systems of Engagement, they look for ways to improve their developer productivity. Application frameworks do just that. By reusing code, components, models, and patterns, software developers improve code quality, reduce the time and money it takes to produce software, and make code more valuable and extensible through APIs.

Determining a complete application stack is a complex set of questions and tradeoffs. Because frameworks have a profound effect on developer productivity – and thus the economics of any software project – they are the high order bit in any discussion around application architecture. The same goes for the myriad of mobile application framework options available for JavaScript as mentioned in this article on how vFabric powers mobile back-ends.

3. Expanding Application Usage Types

Someone once said, “80% of success is showing up”. For businesses, this translates to making your application available on the platforms people use most. But those are vastly different from what they were just five years ago. Consider the following:

Companies have to be on mobile, tablet, and social platforms in order to reach today’s customers. As a result, we believe that a large number of new Systems of Engagements development work are projects to build apps that run on mobile devices and leverage social networks. Technologies such as Spring MobileSpring for AndroidSpring Data RESTJSONMQTT, and Oauthare critical for this work. Also it’s critical to understand the intricacies of building applications on social application platformsowned by other companies, which can change on short notice.

4. Data Explosion

We’ve all seen the research about data growth being a challenge.EMC sponsored a study by IDC that outlined how the amount of digital information grew 62% in 2008 – almost a Zettabyte.  For 2010, it was over a Zettabyte.  To explain the sheer size of a Zettabyte, it is the amount of information in 75 billion fully loaded 16GB Apple iPads. This many iPads would fill Wembley Stadium 41 times.

Data growth isn’t just coming from the number of Instagram images being uploaded per day (i.e. 5+ million), data growth is coming from increased smart phone and tablet usage, widespread business analytics, database duplication, greater regulatory requirements, large amounts of sensor- and device-generated data, greater data integration, the rising interest in user tracking data, more consumer use of online gaming and video, greater volumes of emails and attachments, sensor data (from our oceans and farms), and more.  Whatever the cause, the sheer volume of data goes beyond the scalability of traditional RDBMS.

Without an elastic and cost-effective way to scale the data layer, app teams may drown in the data they originally wanted to produce from the app.

5. Cloud Economics

Economics analyzes the production, distribution, and consumption of goods and services, and cloud application architectures are fundamentally different from traditional architectures in the way they are produced, distributed, and consumed economically.

Virtualized computing is often assumed as part of cloud architectures, and given the economics cited by VMware and others behind server consolidation, many companies have put in virtual-first policies for new applications.  This means that any new application would have a target platform based on virtualized infrastructure to help avoid the costs of server sprawl and low server utilization. Yet cloud economics push application architectures further in three additional ways:

A. Lower Transaction Costs: Think about the time you enrolled, set-up, and turned on your first online application.  Whether it was a hosted e-commerce or CRM app, a PostgreSQL database, or an EC2 environment, it felt like driving a car for the first time by yourself.  You’d think, “wow, I just created this in minutes and now I am using it.”  You didn’t have to create a project plan, request budget, install, write code, or even talk to anyone for approval.  You might take it for granted now, but this was profound at the time.  The fact is, you could now do something in minutes that used to take days, weeks, or months.  Application architectures that afford this level of self-service are perfect examples of lower transactions costs and business agility. Yet, these types of nimble application architectures don’t happen on their own.

B. Greater Efficiency and Effectiveness: In order to achieve greater agility (e.g. burst computing, APIs), infrastructure deployment, monitoring, and operations must be more automated and streamlined. Applications have different requirements, different functionality, and different architectures to be truly elastic and support spikes in consumption versus spikes in downtime.  For example, your monitoring solution might realize a CPU threshold has been met and automatically provision a new app server on virtual infrastructure or extra computing capacity might be needed temporarily (instead of a human doing this manually). These burst-computing models often assume an app runs in a hybrid model across public and private clouds.  For apps to deliver these types of capability, architectures must be planned with these requirements in mind.

C. Utility Models: Accounting for operational costs as a monthly service usage fee (like a metered utility) requires a different financial model.  When costs are based on variations in utilization, app architectures must take virtualization, server footprint requirements, open source software, and lightweight app containers into account. Both purchased software, open source, and internally developed programs need to run cost-effectively while underlying hardware is fully utilized. In addition, applications must have robust and consistent monitoring for utilization to make the accounting function transparent.  The priority of cost-accounting steers app architectures.

Come learn more about how the vFabric Platform addresses the needs of IT in the face of these trends at APP-CAP1644 “The Changing Nature of Applications and the VMware vFabric Cloud Application Platform” at VMworld in Barcelona

About the Author: Al Sargent leads vFabric Suite product marketing at VMware. A VMware employee since 2010, Al has helped make the vFabric Cloud Application Platform become one of the fastest-growing application infrastructure suites in the industry. Prior to joining VMware, Al was co-founder of cloud computing startup Sauce Labs, a software testing platform as a service (PaaS). Previously, Al held product roles at Oracle, Mercury Interactive (acquired by HP) and Wily Technology (acquired by CA), and holds one patent (#7730193). He holds a B.S. Symbolic Systems from Stanford University, and an MBA from UCLA Anderson.

APIs and microservices are maturing, quickly. Learn what it takes to manage modern APIs and microservices at enterprise scale.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}