Starting with some basics
While we’d like to discuss Enterprise Application Integration it is important to start with the most basic approach to data exchange and why is it crucial to understand it fully before jumping into more complex architectural styles that support ecosystem interoperability. Point-to-point as an architectural approach is exactly that. This is the most commonly known approach used by all developers and architects. So let’s take the time to explore the benefits and pitfalls of this architectural style.
What is Point-to-point (P2P)?
To put this simply, Point-to-point should be understood as a system or an application directly calling a different systems or applications API understood broadly. It can be a JDBC procedure call, an invocation of a REST or SOAP API, etc.. Commonly found in every kind of environment, it is impossible to avoid, as it serves as a basis for all communication. The lack of a mediator forces all of the aspects of communication upon the business systems. Those become responsible for the technical implementation of the communication, its security, governance over data and data models, etc..
Implicit architecture
Since Point-to-point, as a dominant form of interoperability in an ecosystem interoperability focus is mostly common within young, small or not tech driven organizations (one could say those with low IT maturity), it is often created as a side effect of lack of architectural governance. In essence, it happens by accident, a sheer need to integrate applications that were introduced into the ecosystem without interoperability in mind, for example: “Ok, so we have this custom application which we built that helps us manage assigning staff to specific client projects, but it would be so much easier if we would not have to input employee details by hand but get them from our Workday instance!”. That way a P2P connection is created with every similar need and the interoperability is not governed but driven by at-the-time business needs.
The road to chaos
Point-to-point, among other things, has a big pitfall that often, when unmanaged, as described above, leads to severe complexity that can even cripple business. This is often referred to as Spaghetti Architecture, because of the large quantity of tangled up interactions that, when charted out, often look more like a dish of spaghetti, rather than a diagram showing actual communication. We take this specific “architecture” as a reference point of what we do not want in our ecosystem and to be able to explain how this complexity can be resolved by various approaches, architectural styles and patterns.
Qualitative analysis
Before Point-to-point leads us to complexity that could kill the business, it is worthwhile to explore what may be its cause and what other pitfalls may be awaiting us when implementing this architectural style. We can avoid some of the pitfalls by understanding what are the key architectural characteristics and how they are relevant in this setting. For that we will be using a comparison table that was produced through a qualitative analysis of architectural styles taking several architectural characteristics into account. If you would like to learn more about this analysis or read how we define those characteristics, you can do so by reading this article, where we explain how this comparison was created.
Cost analysis
Let’s start with the costs of Point-to-point architectural style. There is no middleware used in this architectural style and it relies on direct communication between two applications, which means that development cost as well as operational cost are pushed onto the specific systems that wish to exchange data. What that means is that in this scenario we do not have any additional licensing costs, no specialized development or support team responsible for application integration. This lands P2P with a score of a single in the development and operational costs.
Architectural change cost is the cost that will vary the most depending on the size of the ecosystem and the number of interactions within it. The higher the number of systems and applications and the dynamic dependencies between them, the higher the architectural change cost will be. But if we assume a positive scenario that there actually is some governance (e.g. use of standardized, industry-specific protocols) over the ecosystem and its interoperability, that will limit the number of interactions between systems and as needed switch to a different architectural style, then it will not be allowed to grow to become a Spaghetti Architecture. In that case it will be feasible to introduce architectural changes with ease. This in turn gives P2P a single score in this category.
Architectural and design time analysis
The first group of architectural characteristics that we can take a look at when analyzing architectural styles describes the qualities of the blueprint of the architecture. If we’d take a closer look at what makes Point-to-point really good, we’d find that it is first of all its simplicity (5) . This means that when implementing this architectural style, it will be quite simple to understand and test, as there is no added complexity of a mediator between the business systems. This comes with a specific corollary that this architectural style becomes more complex the bigger it grows, which means that if left ungoverned it will become the Spaghetti Architecture.
The architectural downsides of this architectural style come from the same source as the benefits. Having systems or applications interacting directly with each other means that we face tight coupling between them. The level of coupling that we’d usually like is “data coupling”, where at this point we’re facing not only “stamp coupling”, as in being bound by a specific data model, but also “external coupling” that forces the calling application into using a specific communication protocol. This in turn means that architectural characteristics such as abstraction () and contract resilience () will suffer greatly. This in turn impacts extensibility (), because it is very hard to add new features, functionality and systems, when each time an integration is needed, the system engineers need to learn a substantial piece of a different system and the way it’s implemented. Lastly, due to all of the previous downsides, composability () as an architectural characteristic also suffers, because as far as it is doable to reuse an API exposed by a specific business application, composing new functionality from existing components is pushed into the responsibility of the calling systems, which means that all those ned functionalities are encapsulated within those systems and not reusable by other applications.
Operational analysis
The second group of architectural characteristics we can take a look at focuses around operational aspects of the ecosystem. The first and biggest benefit of a Point-to-point architectural style is its testability (5). Due to the high simplicity of the ecosystem and the fact that the responsibility of testing lies solely with the business applications, testing the communication, analyzing the results and being able to report outcomes is fairly quick. Unfortunately this ties in again to the aforementioned corollary, where with the growth of this architectural style, the complexity heavily impacts testability, which again is reflected over the Spaghetti Architecture qualitative analysis.
The second operational aspect of this style that works well is performance (4). This again relates to the lack of mediators, so as the communication is simpler, the latencies for communication are dependent only on the response time of the called systems. This can be managed and optimized, so the performance of the ecosystem is overall high. The reason that this is not the highest score is that this style usually does not enable efficient asynchronous communication..
The operational architectural characteristics that fall behind in the trade-off in this architectural style are observability (2) and auditability (2). These heavily rely on how the business systems are implemented and what metadata they allow to be extracted out of them. In essence if we’re dealing with legacy custom systems, they might be very hard to refactor to provide sufficient amounts of metadata (logs, correlation ids, etc.). A similar situation might happen with Software as a Service (SaaS) solutions, where customizing those to provide the needed information might be a costly endeavor, severely impacting those characteristics.
Furthermore scalability (2) as an architectural characteristic is also low, because communication done over a synchronous protocol, that is the cornerstone of Point-to-point, does not support horizontal scalability sufficiently, especially due to the fact that it requires additional tools to be introduced to support features such as load-balancing. That hinders the capability of the ecosystem to have automated scaling, which is also done differently with each business system.
Lastly, security (3) in this architectural style is scored as average due to the fact that usually there is little to no overarching governance. This means that implementing least privileged access or following Zero Trust guidelines might be hard to achieve if not impossible.
Conclusions
Point-to-point is and will remain a valid architectural style for the ecosystem level. When implementing this, one should remember that it is not an architecture defined for extensive growth. It is valid for start-ups, small projects or data processing pipelines, where 2 or more systems can be treated as one from the perspective of the "rest of the world" in context of a given process. Without proper governance it might quickly turn into a Spaghetti architecture, leading to unwanted complexity and negative impact on business processes and their execution.