Sergey Nivens - Fotolia
How to evolve architecture with a reactive programming model
Looking to modernize your enterprise architecture? Learn why reactive programming and event-driven process management will be the foundation of this change.
Most enterprise architecture today evolved before many of the modern technical tools or application principles evolved. Rather than retrofit new ideas to an old model, would it be better to start from scratch? Many architects think so.
It's hard to talk about modernizing something without a clear view of the future. Cloud computing, virtualization, componentization and microservices have combined with mobility to empower workers in a new way. In this new model, entire businesses are event-driven, meaning that processes run as needed rather than on a schedule. The software architecture term that envelopes these concepts is the reactive programming model, and it's the notion of the event-driven business and reactive applications that define the future of IT.
Understanding reactive
In a reactive program, a business responds to external events, such as purchases and sales. Each of these events changes the state of some business resource, such as inventory. When a state change occurs, that generates other events that roll the changes through related processes. This lets workers take care of conditions as they occur. It also ensures that everything needed to complete a transaction has been done before the next step is triggered. It's a complete departure from monolithic applications and the sequential notion of business processes -- the vision that guided most legacy enterprise architecture (EA) models.
Reactive programming focuses on business operations as a set of asynchronous business processes that support workers, customers and partners in a variety of ways. Each of these asynchronous processes are composable into role-based frameworks that look like current applications or workflows. The key is to be responsive to specific business needs and to adapt to changes in the ways those needs develop. The IT portion of a reactive model adds the requirements of resiliency, elasticity and message-driven processes, which assure alignment with evolving technologies, like mobility, internet of things and the cloud.
Steps vs. flows
At the top level, the reactive model demands that enterprise architects think in terms of steps rather than flows. Each step is a task that is performed by a worker, an application component or a pairing of the two. Steps are invoked by a message and generate one or more responses. For example, a customer number has to be validated, meaning it's associated with an active account. This step might be a part of a customer order, an inquiry, a shipment or a payment.
Historically, enterprise architects might consider this sequence to be a part of each of the application flows cited above. In the reactive programming model, it's essential to break out and identify the steps. Only after that should architects compose them into higher-level processes. It's difficult to work with line organizations to define steps because they tend to think more in terms of workers and roles, which dictated the flow models of the past. If you're dealing with strict, top-down EA, you'd derive steps by looking at the functional components of the traditional tasks, such as answering customer inquiries. You would then break these tasks out into steps and look for common steps that can be shared across workers and roles.
You can start this process of atomization with legacy EA models, but be sure to involve the line organizations whose workers support the business processes you're reviewing. Do this one line department at a time. Take each process, and review it with the responsible line managers to validate its accuracy, as work practices tend to diverge from EA models. While you're doing this, get specific input on how critical each process is; you'll need that information down the line.
Identifying business activities
After you've broken down processes, you can start to collect information on the processes that are associated with your business activities. This may involve creating a rough list that compares basic descriptions of what workers or outside partners are doing and then reviewing ones that look similar with the organizations involved. Through this, you can determine what processes are common across multiple business activities and also build a description of a functional model for these common elements that will satisfy all the business users.
This will reveal the requirements for the reactive programming model, but not the other three. It is not necessary, and may even be undesirable, for architects to try to incorporate resiliency, elasticity and message-driven properties into low-level EA models. But it is necessary to identify functions that require resiliency and scalability.
Adding resiliency and scalability
This atomization will reveal the business requirements that underlie the resiliency, elasticity and message-driven requirements of reactive programming. During that step, the architect should have identified the specific processes that are critical to operations. Architects should then inform development teams about these processes so they can build in the required resiliency.
Collecting data that identifies the processes that support multiple line departments, roles and workers is critical in framing the scalability dimension of the reactive programming model. Variable workloads generated by a single department are easily spotted, but it's easy to overlook the variable load requirements placed on application components by concurrent use in different parts of the business. If you identify common business processes as reactive steps, you'll identify the pieces that are critical or are at risk to overload.
The defining element in future business operations is the event-driven enterprise, and the reactive programming model helps architects visualize the worker-to-IT relationships of the future. It will also help model business processes into steps that map easily to future IT.
