Behind-the-Firewall Enterprise Apps

Today, an increasing amount of custom software targets an outside audience. But I’m not seeing a drop-off in demand for new and updated software used by internal staff.

To be sure, just because something isn’t internet-accessible doesn’t mean it’s on your own infrastructure. Enterprise apps might run on-premises, in a colocation facility, or even in a public cloud with isolated networks and a private connection.

Let’s talk about the apps themselves. You’re getting requests for new standalone apps. Demand comes when teams outgrow their complicated Microsoft Excel spreadsheet solutions, for instance. Or, when new business dictates fresh tools to collect, edit, and share information. A lot of enterprise applications also extend existing commercial software. This might be interfaces that add functionality to an existing Enterprise Resource Planning (ERP) system, mainframe environment, or industry-specific software. Think of a simplified intake form that lets employees add product inventory without accessing the complex back-office system of record.

You’re creating all of these enterprise apps in a few different ways. Many of you still crank out desktop apps using Windows Forms or WPF. Web apps are clearly becoming a default option. And there’s the workflow-driven custom apps built in “low code” platforms like OutSystems and Pega.

Real-Time Processing Systems

Why all this enterprise attention on developing software? Because we expect the companies that we deal with to make our lives easier. Nowadays, that’s through technology. One way companies deliver value through technology is by reacting faster to changing customer needs. This puts a premium on systems that provide up-to-date insight into your business.

Do you want to find out tomorrow that you’re out of flu shots in one of your sickest cities? In a hot real estate market, can you afford to discover newly listed homes a week after they went up for sale? What happens if you discover your hotel is grossly overbooked after a partner website sends over a dozen reservations at once?

The heyday of nightly batch processes and weekly data file uploads is over. Your business units are asking for real-time systems that quickly ingest and process data. Now, there’s still a place for complex batch analytics. But increasingly, companies use those to complement real-time behavior. For instance, you might generate machine learning models using the rich data in your warehouse. Those models then become accessible to your messaging or event stream–processing engines as new data arrives.

Here’s a class of application for which you might find yourself using more bleeding-edge technologies and architecture patterns; use an event stream processor like Apache Kafka or Amazon Kinesis for high-speed ingest. Or stand up lightweight message brokers like RabbitMQ or NATS to route data to target systems. Maybe you’ll introduce TensorFlow to build and train machine learning models. How do people get the results of this real-time processing? Your web applications might use SignalR for server-to-client push scenarios, or you could introduce notification engines like Microsoft Azure Notification Hubs to send mobile alerts. When you start building real-time processing systems, there’s a great chance that you’ll discover a whole range of new technologies and architectures.

Public-Facing Web Applications

Unlike a decade ago, you’re probably spending a fair amount of time building web applications used by outside users, whether customers or partners.

For many companies, this represents a big departure from the software they’re used to building. Instead of creating internal applications supporting hundreds or thousands of people, you’re building internet-facing apps targeting an unpredictable global audience. You’re asked to build not only static sites to advertise new brands or one-off promotions, but also full-featured platforms for collecting data, selling products, serving up media, or aggregating information from dozens of sources. And all of this for a population expecting 24×7 availability and split-second latency. Gulp!

The predominant way to build these public-facing web apps today is to rely more heavily on client-side JavaScript rather than stashing compute-intensive logic on the server. Data retrieved from API calls is asynchronously loaded on the page. All of this requires a different architecture for storing, updating, and retrieving data—not to mention the adjustments to web application and API design. But I suspect you’ll find yourself creating more of these types of applications, not fewer. Now’s a great time to absorb and implement modern techniques for these applications.

Mobile-Friendly Solutions

There’s no doubt that the mobile experience is crucial for nearly every business today. It’s a deciding factor for plenty of consumers when they’re choosing banks, grocery stores, airlines, and even health clubs. The information available at our fingertips is breathtaking. Is your company delivering its key consumer, partner, and employee services via mobile?

When I say “mobile,” I consider both native apps and mobile-friendly web experiences. Your stakeholders probably ask for both. Embracing the native application model is powerful but brings with it new considerations for application coding, software delivery, and notification strategy. If you’re satisfied offering a web-only experience to customers, you still need to consider low-bandwidth consumers, response time, and spotty connections. Either way, your architecture and toolchain is undergoing a refresh to accommodate this increasingly dominant way of consuming your company’s services.

APIs for Internal Apps and Partners

What’s powering all of these modern applications—web, streaming, mobile, or otherwise? Application programming interfaces, or APIs. APIs make it simpler for applications to talk to one another. You interact with APIs constantly whether you know it or not. Every time you see an embedded YouTube video or Twitter tweet, post a message to a Slack channel, or read email from an Exchange Server, it’s thanks to APIs.

We often associate APIs with public RESTful web services invoked over HTTP. But APIs can be private, use non-HTTP TCP ports, and exchange a variety of payload formats. Heck, the operating system on your computer is full of APIs.

Your business stakeholders want more collaborative systems. No software is an island. You could create a tight coupling between application databases, but that hampers your flexibility later on. You could directly embed native API calls to communicate between systems, but again, that’s unwanted coupling. No, I’d be willing to bet that you’re creating more web service APIs than virtually any other type of software right now. As you construct more decoupled microservices architectures, you invest in well-designed APIs that abstract away the details of the underlying system.

Building web APIs requires a handful of new considerations. Do you need an API gateway for mediation? You know, for things like authorization, token transformation, caching, and rate limiting? Will you have a database per service, or figure out how to share data stores among various services? Can your web service handle unexpected traffic from mobile clients, partner systems, and internal applications? The web services you built in 2007 are probably in need of a refresh to handle today’s demands!

Summary

In this chapter, we looked at the categories of software that your company cares about most right now. Some of those represent things you’ve been building for years, like internal applications. Others, such as streaming systems, are fairly new in most companies. Is there a set of criteria you can measure against as you consider how to modernize .NET applications to fit into this new world? Yes, and in Chapter 4, we look at what it means to be “cloud-native” and why you should care.