Using microservices to solve macro business problems
At this point we all know about microservices. I'm guessing that somewhere in your organization at this very moment, there is a microservices rearchitecture project ongoing, being planned, or being pitched.
The concept of microservices has been around the software development industry for over a decade now and for good reason – the benefits are real. Evolving legacy applications from complex monoliths to independent microservices allows apps to iterate faster, respond quicker, recover gracefully, and scale intelligently.
There's an easy metaphor to be made between legacy applications and established businesses. Like legacy applications, businesses can be extremely complex. Decades of process changes and system evolutions have left teams, processes, and applications intertwined. As a result, businesses can struggle with the same setbacks that legacy applications often do:
- Slow to change
- Many interdependencies
- Difficult to scale
- Stifled innovation
Like microservices applications, we want our businesses to iterate faster, respond quicker, recover gracefully, and scale intelligently. So given their similarities, can we take the same principles that guide microservices software development and successfully apply them to a business architecture?
Key microservices principles for development: Think big, act small
There are two key microservices principles that guide development that you will need to apply to your business architecture in order to capture microservices benefits:
- Components must be targeted, independent, and business capability-centric.
- Interactions between these must be API-led.
Let's dive into these a bit and see how we can act on them in a modern business.
Principle #1: Targeted, independent, and business capability-centric components
The key to the microservices evolution was the realization that we were architecting large, multi-purpose systems all at once. These systems served multiple functions and did multiple, usually unrelated, jobs. And what we learned was that large, complex, multifaceted systems are notoriously difficult to test and deploy – which slows down release cycles and decelerates the release of innovation and the customer feedback loop.
After years of process and organizational evolution, businesses often find themselves in a similar spot: full of bloated business processes and applications with too many competing purposes. We need to decentralize our processes and applications in order to embrace independence so they can change and respond faster.
Identifying and peeling off processes and applications into independent business capabilities is foundational to microservices-level agility.
Gartner suggests kicking off this process by creating a business capability model – a map of all of your business's abilities from customer viewpoint. To a customer, your business is an aggregate of outcomes – something with a start, middle, and end. Opening a new account. Filing a claim. Ordering a new credit card. Each touchpoint with your business will be to create, read, update, or get the results of those outcomes. Your business architecture should reflect that.
In Pega, we call these microjourneys, and they sit at the core of every application, defining the logic, personas, and channels for that outcome.
These customer microjourneys can act as their own, “independent microservice” or be grouped with a set of tightly related microjourneys into a “targeted microservice” (for example, “open account” and “terminate account” may be grouped together).
These microjourneys manage their own business logic, channels, and data, complete with a prioritized backlog of work and an autonomous, empowered team making changes and decisions. As a result, they can change rapidly, responding to the needs of the customer, the business, and the market without waiting for unnecessary dependencies.
For example, let's say a new regulation comes in that requires an additional step to be performed by a new auditor in a document verification process:
- If document verification is modeled as an independent “microservice,” adding a step, new logic, and a new screen is fast and easy.
- If document verification is one part of a large, monolithic system, identifying any dependencies is challenging, and changes need to wait until the monolithic application releases a new version.
This all sounds great, but we know that these microjourneys need to connect to one another to spin off work, update work, and aggregate data. How do we set up our business architecture so we can orchestrate and connect our microjourneys?
Principle #2: Interactions between microservices must be API-led
APIs make data and actions available from across systems while maintaining a contract between parties with well-defined inputs and outputs. This communication protocol acts as an abstraction layer – allowing everything behind its walls to change freely, so long as it adheres to the contract.
In the same way software services need clear APIs and contracts between them, so do customer microjourneys. Because these microjourneys are all part of a larger customer experience, we need the right endpoints to create work, update work, and access data from one microjourney to another.
Once you have your microjourneys defined, begin to identify the contract:
- What data do you need at each step of the journey?
- What actions will be available at each step of the journey?
- What data will be available at each step of the journey?
Clearly communicate the answers to these questions in a standard manner between teams and business units.
For Pega microjourneys, creating the contract for your process and application is done for you automatically, with dynamic, automatically generated APIs that tap into your business logic throughout the microjourney. Pulling in data from other systems or microjourneys is easy too, with flexible, open APIs and RPA to access any system, new or old.
Keep building for change
Adopting these microservices principles in your business architecture will yield tremendous benefits in speed, agility, scalability, and resiliency – but these alone are not a panacea (waited my whole life for an opportunity to use that word!).
As you evolve your business architecture, new needs will emerge:
- Your employees need visibility into all of their work from across these new microjourneys.
- You need dashboards and reports of all of the work being completed for your customers across these business systems.
- You need automated governance to maintain a consistent level of security and quality.
We know that as you evolve your business architecture these needs will arise, so we are setting a foundation for you to move fast while staying connected.
With Pega Process Fabric™, we are introducing a new set of lightweight capabilities for visibility, connectedness, and intelligence across business applications. The best part is that this foundation will work with applications you've already built – be they microservices-based or more monolithic in nature – so you don't have to rearchitect your business all at once.
Learn more:
- Discover how Pega Process Fabric streamlines the customer experience.
- Watch this PegaWorld iNspire 2020 video to see how Pega Process Fabric works.
- Learn how Pega’s technology helps you quickly adapt to new business challenges.