Included in the 2024 Gartner Hype Cycle for AI, but still early in the curve as an innovation trigger, we find autonomic systems. Gartner analysts describe this innovation trigger as “…self-managing physical or software systems performing domain-bounded tasks that exhibit three fundamental characteristics: autonomy, learning, and agency.”

This essay proposes a structure for autonomic systems that specifically addresses software. We will refer to it as autonomic software architecture (ASA). ASA facilitates the identification of and binding to software-related domains and provides a construct for the detection of and governed adaptation for threats and usage patterns. With this structure, ASA affords software a degree of self-regulation for stability, self-protection in mitigating events, and self-adaptation for accommodating client usage preferences.

The ASA pattern is inspired by the utility of the autonomic nervous system (ANS) studied in the science of physiology. ANS regulates internal physical functions (breathing, heart rate, and blood pressure) and automatically manages adjustments needed in response to external demands and stressors. ANS affords allostasis, an agile physiological adaptation in response to stimuli, and then the return to baseline settings and function for stabilization.

In the same way that our physiological systems adapt and self-regulate to navigate the world around us, ASA allows software to adapt safely to events and usage trends to better align with its environment. ASA also helps to determine whether adaptations should be made permanent or if a return to the previous state is best for system stabilization.

ASA is a natural objective for software systems. If the “intelligence” referred to in AI reflects human intelligence, then it follows that technologies incorporating AI would also endeavor to model other human systems, like ANS, in the pursuit of replicating human capabilities.

The Enablers of Autonomic Systems

Several modern software development trends could enable ASA. The first driver is the practice of “everything as code.” This means that in addition to the application software itself, all things related to the build and operation of software are also code-driven. This includes infrastructure, delivery pipelines, security solutions, and so forth.

The next precept is machine learning (ML). Observability tools and ML capabilities such as pattern recognition and anomaly detection enable evaluating how clients use software, assessing the software’s performance, and detecting malicious behavior.

Automation is also an important element for ASA. Workflow automation tools for testing and deployment are mature, pervasive, and code-driven, allowing code to be automatically deployed when it passes testing.

The final and most recent enabler for ASA is generative AI (gen AI). Gen AI is quickly advancing to the stage where, when served precise and unambiguous prompts, it can produce reliable code.

Recommendations For Developing ASA

Separate Architectural Dimensions

The ASA framework can be established by organizing the solution into separate architectural dimensions. Much like how the model-view-controller (MVC) framework organizes a web application’s primary components, ASA is an architecture model for the entire software solution that depends on a clear “separation of concerns.”

To build autonomic systems, you must delineate dimensions that have unique analysis metrics and that are modified with particular actions. Architectural dimensions for software include user interface, functions and services, protection, infrastructure, logging, and application data.

MAR Modules And Decision Agents

For each architectural dimension, ASA must implement monitoring, adaptation, and reorientation (MAR) modules, with decision agents managing the communication and the flow of adaptation initiatives. Let’s examine the modules that power ASA to see how they work.

Monitoring Module

This module monitors for threats and usage patterns that indicate needed adaptations. The architectural dimension being served by the monitoring module constrains the adaptation triggers to consider, informs the thresholds and margins that generate triggers, and curates the adaptation actions available.

For example, suppose the protection dimension is tasked to monitor for scenarios such as brute force attacks and DoS attempts. It also is focused only on allowed adaptation actions such as adjusting request throttling settings or blocking a requestor’s IP.

To assemble a monitoring module, select monitoring tools with robust configurations for alerts or that support real-time queries of the monitoring output. Create thresholds and margins that, when breached, will send alerts (push) of an adaptation trigger or use intelligent queries (pull) to identify an adaptation trigger. The monitoring module also uses historical analysis, predictive analytics, and enterprise guidelines to set the “baseline adaptation” flag to indicate if an adaptation is permanent or temporary.

The monitoring module will have a cross reference of the relationships between adaptation triggers and adaptation actions. The details of these relationships, the identified trigger, the corresponding allowed action, and the architectural dimension’s domain context all feed into a prompt assist tool to create a prompt asking for the needed adaptation code.

Decision Agents

Decision agents between MAR modules serve as gateways for ensuring that adaptations comply with enterprise governance, among other responsibilities. Decision agents are contextual to their architectural dimension and the MAR modules they serve.

To keep with our example using the protection dimension, the decision agent between monitoring and adaptation may include enterprise governance that dictates minimum and maximum request throttling settings or could refer to a protected list of clients that cannot have their IPs blocklisted.

Adaptation Module

As expected, adaptation modules are highly related to their architectural dimension. They can execute curated adaptation actions and have well-defined flows for those executions. Use the adaptation code provided by the monitoring module and a well-defined process to drive testing and validation. Refer to a predefined, enterprise-compliant versioning and delivery model. Use all this information in a prompt assist tool and create prompts to generate testing scripts and a deployment pipeline.

In keeping with the example related to our protection dimension, if the adaptation action is to block one or more IPs, we already have the adaptation code provided by the monitoring module. In the adaptation module, we use a prompt assist tool to generate a prompt that creates tests to verify the blocklisting works as expected. We also create a prompt to generate code for the delivery pipeline to publish the adaptation code to block the target IP(s).

Reorientation Module

Reorientation after the delivery of the adaptation is where we take appropriate actions for adaptations that are temporary and for adaptations that are permanent changes to the software baseline. Reorientation modules are pre-configured to know, for each adaptation action, the documentation components to be updated and any related changes to monitoring that must be implemented.

The decision agent between the adaptation and reorientation modules also evaluates the success of the adaptation delivery. If post-production metrics are poor, the reorientation module is instructed to initiate a rollback of the adaptation. For example, and in keeping with our scenario in the protection dimension, if the IP blocklisting adaptation is erroneously blocking more than the intended IP(s), the reorientation module will perform a rollback of the adaptation.

Figure 1: A template of the MAR modules and decision agents that serve an architectural dimension.

How ASA Can Serve APIs

A demonstration is often the best way to convey an idea. Let’s use the autonomic software architecture model to enable an API to self-adapt and accommodate a usage-implied need for an additional filter.

In an ASA architecture for APIs, the architectural dimensions could look like the following diagram:

Figure 2: This shows MAR modules and decision agents are instantiated for each architectural dimension.

Example API

Let’s assume the following API exists to get subscriber data:

Resource: 
/subscribers

Data elements: 
{subscriberId, fName, lName, address, city, state, zip, subscribeDate, renewalDate, subscriptionLevel, paymentPlan, hyperLinkTransactionHistory}

Query/Header Filters: 
{subscriberId, state, subscribeDate, renewalDate, subscriptionLevel}

ASA Event Summary: Identifying a Client-Desired API Enhancement and Deploying It

The monitoring module for the contract architectural dimension observes that occasionally, clients pass “zip” as a filter. Because “zip” is not a valid filter in the API contract, it is ignored in the request. The occurrence count for this anomaly crosses a threshold and is identified as a stimulus for an adaptation. A flow is initiated that will enhance the API to process “zip” as a valid filter.

Example Flow:

1. Monitoring Module
   1. The module identifies clients using a non-valid attribute, “zip”, as a filter. The module recognizes that adding a filter is an allowed adaptation.
   2. The module utilizes a prompt generator to create a prompt and uses the prompt to generate code that will accept “zip” as a filter in the API contract parser.
   3. The module determines this to be a “baseline adaptation” that will be permanent.
2. Monitoring-Adaptation Decision Agent
   1. The adaptation code is confirmed to be compliant with enterprise governance and guidelines.
   2. The adaptation code is determined to be non-breaking for clients.
3. Adaptation Module
   1. The module utilizes a prompt generator, considering enterprise guidelines and process definitions, to create tests and a delivery pipeline.
   2. With successful testing completed, the delivery pipeline is executed.
   3. Update API documentation
4. Adaptation-Reorientation Decision Agent
   1. Execute post-production testing to validate the delivery or determine if rollback is needed.
   2. Instruct the reorientation process to rebaseline the API with this adaptation.
5. Reorientation Module
   1. Rebaseline the API
      1. Publish the API documentation that includes the “zip” filter as valid for the API
      2. Communicate the API update to all stakeholders
   2. Determine and initiate any needed code changes to the monitoring module related to the new “zip” filter. For example, new monitoring may be added to track how often “zip” is used as a filter, the performance of the API when “zip” is used as a filter, and error codes received when using “zip” as a filter.

Notes:

• Step 3.2 assumes the technology is in place to auto-generate appropriate testing.
• The monitoring module interrogated the data schema to understand that “zip” could be used as a filter. In the prompt generation task, the request only needed to focus on additional code for the contract parser to manage the “zip” filter when seen in a request. If the application data was not prepared for filtering by “zip”, then the flow stops until intervention is taken.
• Decoupling architecture dimensions allows for a change to the contract service without risk to the API’s protection solution, logging, infrastructure, or application data.
• To minimize risk, there could be approval steps at any point along this flow for manual review.

Summary of Autonomic Software Architecture

ASA is a nascent concept, but it is an achievable goal with the maturation of gen AI. Well-defined guidelines are needed. Anyone who wishes to participate in this project is welcome.

In the future, API management solutions will integrate ASA components into their platforms to expedite autonomic architectures. In that new world, API design becomes even more critical as it must consider the potential direction of an API’s self-evolution. We will have to craft APIs and the related governance used in MAR modules so that our APIs remain aligned with the business strategy during adaptations. Such APIs will serve the consumer and benefit the provider when they adjust as needed to better protect themselves and accommodate usage preferences.

During our journey with software engineering, intuition has driven us down the path of “everything as code”. This sets the stage for gen AI to participate in “code enables everything.” We know the importance of agility in software engineering. Now, we have the tools to build solutions that, to some degree, have the self-adaptation power needed to deliver autonomous agility.