In this episode, Our customers depend on them, and our businesses depend on them. Without modern web apps, most businesses would not survive. I’ll present the first in a two part series on the principles for modernizing your enterprise web application.
And then, what does any of this have to do with my son and his wage reporting application?
The following are links mentioned in this episode, and links to related information:
Modern web applications have a lot riding on them. Our customers depend on them, and our business depends on them. Without modern web applications, many businesses would not survive. Modern web applications must scale to meet our biggest needs without suffering outages or other availability issues. In order to meet and exceed this high bar, we must build, manage, and monitor our applications using modern principles, processes, and procedures.
There are five guiding principles that a modern application requires in order to meet these expectations.
Modern applications are large and complex, too complex to be handled as a single entity by a single team. Instead, multiple teams are required to develop, test, support, and operate these applications. This complex task is impossible when the application is a single monolith.
To handle a large complex application, split the application into multiple independent services. Then, you can assign different pieces of the application to different teams, allowing parallel development and operation.
By keeping modules isolated, they can be built, tested, and operated in isolation. Application problems can be more easily correlated and isolated to individual services, making it easier to decide which team should be called on to work on an issue when a problem arises.
Scaling is not just about the amount of traffic an application receives, but about the size and complexity of the application itself. Using service-based architectures makes scaling the application easier and allows larger and more complex applications to be dealt with reasonably.
In future segments, we will talk about the remaining four guiding principles that are required for enterprise applications to modernize. In the next segment, principle #2 is about team organization.
Our applications *are* getting more complex, and becoming more intertwined with the fundamental operation of our business. As such, the expectations of our customers are growing, and the demands for reliability, scalability, and functionality from management are keeping pace. Only by modernizing our applications can we make our applications meet the needs of our customers and our business.
Architecting your application as a service-based application is only part of the answer to modernizing your enterprise systems. Once you have your application split up into services, it is essential that you structure your development teams around those services. It is critical that a single team owns each service.
And when I say “own”, I mean complete ownership...front to back...top to bottom.
This includes development, testing, operation, and support. All aspects of the development and operation of each service should be handled by one and only one team.
There is a model for application management that stresses these ownership values. STOSA, which stands for Single Team Owned Service Architecture, provides guiding principles on team-level ownership, providing clear boundaries between services and promoting clear understanding and expectations between teams. We will talk about STOSA and the operating principles behind the STOSA model in much greater detail in future segments. Until then, you can read more about STOSA at stosa.org.
Now that we have team organization and ownership taken care of, the next principle is to focus on the policies and practices that those teams use to build and operate their services. For modern applications, teams must make use of modern devops processes and procedures to build and maintain their services.
Many organizations claim that they “use devops,” but ultimately they do not operate their organizations in a true devops manner.
True devops techniques require a complete organizational flush of all processes and systems in order to incorporate the principles of devops within the entire organization. You cannot accomplish this transformation by simply “creating a DevOps team,” though many organizations try.
DevOps is a cultural transformation. And only by undergoing this cultural transformation can an organization truly build and operate modern applications at scale. Without DevOps, your application will tend to stale in some spots and the work you have done to separate and “service-ize” your application will be for naught. You will not be able to build and maintain your applications unless you adopt...and truly become...a true DevOps culture within your organization.
There are many good sources of information on DevOps. But, certainly, no DevOps bookshelf is complete without The Phoenix Project. You can find a link to The Phoenix Project in the shownotes.
In upcoming segments, we will talk about the remaining guiding principles that are required for enterprise applications to modernize.
More information on these five principles is available in my article published in InfoWorld, “How to modernize enterprise web applications”. A link to this article is available in the show notes.
My son has an app on his iPhone that he uses to record his income for some of the government benefits he gets. Once a month, he has to run this app to simply enter the amount of money he’s earned that month. He simply enters the number and his social security number into the app, presses submit, and he’s done. That’s it.
The problem is, the application on his iPhone only works between the hours of 8am and 5pm, Eastern Standard Time, Monday through Friday. If you try and use the application any other time of the day or night, the application pops up an error message and says the application is offline right now, and you can’t use it.
How many of you can operate applications like that? How many of you can make it so your customers only use your mobile applications during business hours, and prohibit them from using them at any other time?
I know the answer…none of you. It is simply not possible in today’s modern world. People expect our applications to function, and they expect them to function all the time. Anytime they attempt to use your application, they expect it to work, without exception. 24 hours a day, 7 days a week…always.
That is what’s required of modern applications. There is not acceptable downtime. I sometimes here people say they have “nearly 100% uptime!”. But then when you dig in deeper, you find out that they bring their application down for a “maintenance window” every Sunday evening. How is that 100% uptime? The answer is, it’s not. In the modern world, we have to perform all of our maintenance live, and we have to have our applications up and operational all the time.
In our customer’s minds, there is no excuse for anything other than that.