Composable Business Architecture: A Roadmap to Business Agility

Supporting constantly changing business requirements in a timely and efficient manner is the key to successful IT. Achieving true business agility is crucial for a company’s continued competitiveness, especially in today’s unpredictable world. This challenge is not new — for many decades, component-based or service-oriented architectures were just two examples for paradigms suggested to decisively advance an organization’s business agility. What makes it even more pressing in today’s uncertain world is the value of business agility in increasing a company’s resilience, that is its capability to withstand and absorb external disruptions.  

One example of this pivot to resilience-focused operations is of supply chains that need to be quickly recombined if some elements become unreliable.  

A major obstacle to achieving business agility is bridging the much-lamented business/IT gap (difficulties and inefficiencies in the interaction between business and IT). This is often due to the inability of both parties to keep their own concerns out of the dialog. For example, DevOps and Cloud are IT concerns that are out of business’ domain. 

How can business and IT jointly establish functional business components that are highly composable, meaning they efficiently support changes in both the business requirements and the underlying implementing functions? This blog post explores the role of proper application architecture, service architecture, and information architecture, and demonstrates how they are key success factors for building a composable business architecture. It also highlights how Software AG’s Super iPaaS provides the functional capabilities to actually implement those architectures effectively.

How lack of application architecture almost destroyed a company

This is the true story of a Software AG prospect, a company that faced a near-destruction scenario due to a lack of proper application architecture. It is a real-world lesson into the consequences of unregulated development practices and the subsequent adoption of API Governance as a solution. 

The company operated a number of self-developed system components, each managed by the development team. However, these developers had overlapping responsibilities for various components. The trouble began when developer Aaron, needing data from component B for component A, improvised an interface without registration, documentation, or monitoring. This informal connection also worked later when developer Conrad needed the same data from component B for component C. Conrad saw Aaron’s interface, used it, and it worked as well for a while. But when Aaron modified his interface in component B later, chaos ensued because that action disrupted component C’s operations. Without proper procedures, and the absence of testing processes, this faulty code was allowed to go live, resulting in production problems, massive cost implications, and damage to the company’s public reputation. Ironically, Brianna, the lead developer of component B, initially faced the most suspicion for the error message as it was her component that appeared to disrupt operations, but the error was not due to a faulty design but rather a result of developer improvisation. This situation highlights the unforeseen consequences of inadequate application architecture and after learning a very expensive lesson, the company employed Software AG to establish API Governance. 

The shortcomings of this company’s development practices are apparent to every experienced developer. While the application is divided into components, these are not properly separated, ideally following the microservices paradigm. The absence of dedicated development teams, documented APIs, traceable invocations, and mandatory QA and testing procedures created a vulnerable system. A solid application architecture, represented as an abstract structure of software components – such as applications, microservices, databases, and more – and how they interact, is crucial for business agility. It enables the adaptation of components, ensuring a faster and less risky process. 

Post this costly lesson, the company sought help from Software AG to establish API Governance. This strategic move aimed to avoid future pitfalls and secure a robust foundation for their application architecture. API Governance ensures proper documentation, registration, and monitoring of interfaces, preventing the kind of chaos the company previously experienced. The tool used, a Super iPaaS, supports the development of such a solid application architecture through central monitoring of decentralized integration execution, fully featured API governance with policy-driven API calls, and support of the DevOps paradigm.

What SOAP and REST can teach about composable business architecture

Even today, developers often engage in discussions about the differences between SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) during their lunch breaks. For business professionals, these acronyms may seem like obscure terms from the realm of technical nerds, unrelated to their daily jobs.  

However, beyond the technical jargon, these paradigms provide valuable insights into the topics of service architecture and information architecture. These insights are not only relevant for technical business considerations but also serve as a foundation for constructing good composable business architectures and, in turn, fostering business agility.

SOAP

SOAP is a protocol. Applications run ‘somewhere’ and use it to interact with each other over the Internet. They make business services available to each other that have a transactional character: a task is executed. The naming conventions for SOAP services illustrate this: They consist of a verb for the action performed, followed by a noun that designates the primary object on which the action is performed. An example of a service promoting an employee is PromoteEmployee.

The service architecture of an organization is the total set of business services (tasks) provided by IT components that support the business processes. (Non-IT services are left out here for simplicity.) It provides a transactional view of the business. Some people prefer the term ‘API landscape’. While not incorrect, it has a slightly more technical character and emphasizes the access interface over the underlying business capability. 

During the heyday of Service-Oriented Architectures (SOA), there was a lot of excitement about proactively creating a service landscape. However, it’s worth noting that many expectations were exaggerated and, consequently, not met. The anticipated backlash went to extremes, declaring SOA as ‘dead.’ Despite this, the fundamental truth persists: maintaining visibility and intelligently evolving the development of a business service landscape is important for achieving agility through a composable business architecture. 

REST

In fundamental contrast to SOAP, REST is not a protocol. This architectural paradigm does not put the task front and center, but the object, analogous to the SOAP ‘noun’. REST defines so-called ‘resources’ that make the object accessible via a URL (e.g., http://www.example.com/hr/employees). When REST is used over HTTP (which is predominant), native Internet capabilities, or so-called HTTP ‘verbs,’ provide create, read, update, and delete operations on the resources.  

To put it simply, SOAP treats the Internet as a mode of transportation, where applications ask each other to perform specific actions. Conversely, REST sees the Internet as an extensive database of distributed objects. The information architecture of an organization encompasses the total set of business objects managed by IT, objects that support business processes and that are frequently accessible through REST resources. 

Using the same example as above, can an employee also be promoted with REST? Yes of course, but it follows a different way of thinking. The employee’s resource with ID emp468 receives a state like {“role”: “senior office manager”, “state”: “pending_approval”}, and a promotion is executed by an actor that performs a state transfer of the resource (‘state transfer’ is even part of the REST acronym!).  

Scientifically speaking, while both REST and SOAP hold equivalent semantic power, their practical differences matter significantly. Service architectures provide a transactional view of the business (possibly implemented with SOAP), and information architectures provide an informational view of the business (possibly implemented with REST).  

This is not just ‘tech talk’; developing these two perspectives is fundamental for the business as well. Effective communication between business and IT hinges on a common understanding of both business services and business information objects. Importantly, this does not mean that the business needs to learn SOAP and REST. Quite the contrary, experienced IT professionals are able to convey these concepts in non-technical terms. The key is grasping the underlying principles and developing service and information architectures, rather than a mandatory implementation of SOAP and/or REST at the company level. 

Achieving business agility with the Super iPaaS

The three cornerstones of a composable business architecture – application, service, and information architecture – are vital for achieving business agility. While architecture frameworks such as TOGAF offer many refinements, the Super iPaaS from Software AG stands out as a crucial tool for implementation and realization.  

However, real-world practice shows that there is a risk of having ‘too much’ architecture — enterprise architects can end up in an ivory tower, creating complexities that neither business nor IT can understand anymore. The right ‘amount’ of architecture depends on factors such as company size, inherent complexity of company processes, and many other considerations. Nevertheless, the three architectures discussed here are always necessary, and often sufficient.  

It’s important to note that no tool can replace sound architectures, not even a Super iPaaS. However, the Super iPaaS is crucial for implementing architecture that will help a business actually realize business agility. Software AG understands the dichotomy between transactional/’application’ integration and data integration, adapting to evolving data landscapes. The Super iPaaS offers robust features for central control and API governance, addressing the challenges associated with evolving IT environments.  

This tool closes the loop between the two types of integration, embraces change by handling ever-changing data landscapes (‘data drift’). Notably, it provides powerful functions for central control and API governance, mitigating the risks associated with aligning IT with the rapid pace of business evolution. Lastly, the Super iPaaS supports the decoupling of application architecture and physical architecture, offering full deployment flexibility in hybrid IT landscapes.

In conclusion, the story of this company serves as a cautionary tale, emphasizing the significance of sound architecture and the role of API Governance in preventing potential disasters. The adoption of the Super iPaaS further solidifies the company’s commitment to achieving business agility in a rapidly evolving technological landscape.