Architecting for SaaSification

The day is coming when companies will be loose combinations of software services with loose coalitions of people delivering on digital promises. Are you ready?

shutterstock 1899656938 futuristic architecture skyscraper office building curve glass window
nuchao

Transformation to SaaS (software as a service) is driven by both business and technological factors. From a business perspective, software companies seek reliable recurring revenue instead of spending on research and development up front and hoping customers buy the product or upgrade on the back end.

From a technology perspective, software users often do not have the expertise and resources to maintain the infrastructure necessary to run a complex software product like, for example, a distributed database. In exchange for recurring revenue, the producer takes on the burden of operating and maintaining the software for the customer.

Clearly, SaaS makes a lot of sense for the maker of a distributed database. But what if your business isn’t software, per se, but manufacturing, or logistics, or insurance, or some other business service? SaaS might still make sense for you. Welcome to SaaSification.

The line between what is software and what is a business service has long been blurred. The market views companies like Uber, Grubhub, and Amazon as technology companies. Meanwhile, Yellow Cab, Domino’s, and Walmart—companies that deliver the same types of consumer services, and also have websites and apps—are not considered tech companies. Nor are most companies that provide business services, even though those services might be delivered through software.

Traditionally, companies think of themselves as either consumers or providers of technologies or services. However, businesses can be both. There is a considerable amount of research on how this new world will work, but it is still emerging. There is not yet a real marketplace for businesses to buy services beyond just IT (e.g. AWS Marketplace), and decades of attempts to set them up have fizzled. Thus there is still time to get ahead of the curve.

Even if a business does not prioritize selling its internal expertise to other businesses as a service, SaaSification has benefits. The ability to try new ideas, launch new services, and fail fast is one of the keys to the success of the Ubers and Grubhubs of the world. Launching, failing, or succeeding fast requires change to be easy. Evolution can be fast and simple if your business capabilities are packaged as auto-scaled, cloud-native microservices managed through business process automation and driven by a devops model.

Becoming SaaS inside and out

Companies should consider making their internal systems into services, even if the services are not customer-facing. This refactoring allows the company to sell its internal services externally or potentially replace an internal service with one delivered by a third party. To fully capitalize on this idea, the company has to move to business process automation instead of traditional process management. In principle, this means that, based on certain sets of circumstances in the state of the system, people take action in a consistent, repeatable, documented fashion.

The difference between traditional process management and business process automation is like the difference between a taxi company and Uber. In a taxi company, a dispatcher tells the drivers who to pick up, where, and when. With Uber, you order a ride, and the app tells a driver where you are. The dispatcher is software.

A true SaaS business should not just be a technological marvel but a marvel of automation. Ideally, no human dispatcher or manager is involved in everyday operations, just algorithmic business processes and people taking action. This automation doesn’t mean the elimination of humans from the process.

It means understanding your policies and practices and converting them into business processes with a closed-loop management system, one backed by data-driven human decision support and with a situational awareness system embedded in it.

Companies that make this transition are inherently more valuable. A company’s value is, in part, its theoretical purchase price in an acquisition or stock merger. However, acquisitions are a risky business. According to Harvard Business Review, 70% to 90% of mergers and acquisitions fail to deliver on their promise. A key factor in the successful valuation of an acquisition is the transparency of the acquired company’s systems and management and a clear path for integration. Companies that are combinations of loosely coupled services and business process algorithms should be inherently easier to merge.

SaaSified companies should also be easier to adapt to market conditions. Suppose an internal service is not performing as well as expected or as well as a competitor. In that case, there is an option to optimize or eliminate that service or find a better one that is provided by a third party. If an internal service, say logistics, is outperforming expectations, it could potentially be offered to third parties, perhaps via a mere API call.

What SaaSification means for IT

SaaSification presents new challenges to IT organizations. Running a service requires a different form of thinking than traditional IT stewardship and gatekeeping. A service faces variable demand and should be constantly reliable even in the face of change.

To make this transition, services have to be identified and decoupled. Each service has to run according to a defined quality of service in terms of throughput and reliability. Each service should be scalable as needs and demand will inevitably change. Finally, this likely involves not only the cloud but new technology in everything from authentication services to databases.

Consider the standard internal IT department with an Active Directory (AD) server and a slew of Oracle, MySQL, MariaDB, and SQL Server instances that provide data for a series of stovepipe applications. Each of these applications, or future loosely coupled services, relies on underlying client-server software, which scales only to a limited level and provides limited redundancy. Depending on which SQL database you’re running, you might obviously move to a compatible distributed SQL database, and Microsoft would recommend moving to Azure AD, but not everything is as easy to migrate.

This migration is usually an opportunity to deduplicate and combine services. Rather than having multiple AD instances for different parts of the company or a series of stovepipe databases, it often makes sense to coalesce related data and systems. For instance, inventory might be on an Oracle database, and the pricing or catalog service might be on MariaDB. There might be an AD instance for the west and one for the east. Maintaining this division when moving to services may not make sense, especially in the cloud. It is easier to administer, maintain, and secure fewer systems and data.

When load testing, a service that meets the current needs and projected future needs is no longer sufficient. Services must now meet a pattern of scale. They should look as linear as possible and scale down when demand diminishes. Scaling down should include both capacity and cost. This capability ensures that services and the business can evolve together and allows for more flexibility when providing new offerings to customers and the business.

Finally, services must now be both globally locatable and relocatable. This requirement means that the service and its data must be able to span regions. Spanning regions can be done with just cross-region replication. However, for companies with a global reach, the ability to span regions requires cloud independence. No single cloud service provider is optimal in every region of the world.

We have the technology

The good news is that the technology already exists. Nearly all of this is possible with containers, Kubernetes, cloud computing, and distributed databases. However, it will require a different mindset and a change in culture. Cloud-based service architecture must be a given for everything IT develops or manages. These services must meet the standards necessary for SaaSification including scale-up, scale-down, and global capability. In many cases, core services (like security and databases) must be combined and coalesced to make them more maintainable.

More importantly, businesses must think in terms of services and processes rather than hierarchies. A service is not just “an IT thing” but how a business organizes itself. IT and business professionals must modularize everything as cloud-native SaaS, including industry-specific services, horizontal systems of engagement, systems of record, databases, and security. Yes, it is time to adopt the technology innovations of the last few years, but adopting this change in mindset is even more critical.

Copyright © 2023 IDG Communications, Inc.

How to choose a low-code development platform