Tools & Consulting for the webMethods® platform

Tools & Consulting for the webMethods® platform

Business and software architecture

One of the most fundamental things to understand in commercial software development is how the business requirements influence technical choices. Here are some random thoughts on this topic.

Over the last couple of years I have spent some time thinking about how to approach software architecture. The context was development of custom programs for large commercial customers. More specifically we talk about (application) integration scenarios. And while I have seen statements that integration is mostly about mappings between data formats, this is only part of the game.

So here a few thoughts how to look at this. They obviously only scratch the surface, but will hopefully help to start some thinking. The intended main takeaway is that at the end of the day technology needs to meet the business demand. Being able to think in both worlds and switch between them will be more important than technical knowledge alone.

Differences and similarities

For complex enough software there is never a “one size fits all” approach. Every non–trivial software that is developed and not bought off-the-shelf is a completely individual thing. Because equally individual is the problem that it is supposed to solve. Certain characteristics of said problem will often be foud elsewhere, like the requirement to support a specific number of concurrent users. But the combination of all relevant requirements will always be unique. Perhaps not on a higher level, where competing organizations might indeed share most, if not all, characteristics. But if you dig deep enough, more and more differences will come up. Sometimes these are of a legal nature, because the competitors are based in different countries. Or their organizational structure, for whatever reason, is different and by that has an effect on how approvals and delegations shall be handled. There are many other and less trivial reasons, but these examples should be sufficient to understand that despite the superficial similarities, the sum of all requirements will always be different.

Leveraging past experience

If we accept this premise, the consequence must be that blindly following the latest fashion, or what has worked elsewhere, is not very clever. The opposite, i.e. re–inventing the wheel, is of course not what shall be endorsed here either. Instead, it makes a lot of sense to look at past solutions. Unfortunately, too many people do this in a rather superficial way. They look at the heading of a paragraph that describes a requirement, and if there is a match with their current project the assumption is that re–use is fine. While this may be the case, that would of course be purely coincidental. What should happen instead, is that folks look at the reasoning why a certain approach was chosen in a seemingly comparable situation. Since that documentation also includes (hopefully) what other options have been dismissed and why, there will also be good information about alternatives

Architecture Paradigms

Every time has its fashion for architectural approaches. In the 1990s it was the Client–Server that was supposed to completely replace mainframes. The 2000s saw Service–Oriented Architectur (SOA). And in the late 2010s Microservices became the “secret sauce” for everyting. All these hypes, when looked upon with a ceratin distance, have brought solutions for cer- tain facets of the overall problem. With Client–Server it was the ability to separate functional areas (usually presentation logic and core buiness functionality). SOA took another aim (after Object–orientedProgrammingandmanyothers)at re–use. And Microservices solve problems around scalability, high–availability, and various others.

It is important to understand two things here, in addition to being aware of whether is currently a hype or not. Firstly, these things are paradigms. A paradigm is by defition an idealized view and mental model how to approach a given situation. This means that pardigms ex- clude certain (or many) aspects that accompany a certain problem in real life. The value of a paradigm is that it takes a look from an idealized perspective. Which means that it is easier to understand the core part, because details that would make this understand more difficult, are intentionally excluded to not “muddy the waters”. That is a valid approach to learn something. But it becomes dangereous, when people are not aware that what they just learned is not the reality but stronlgy simplified version of it.

The second thing to be aware of is complexity. A given problem must be solved by means of individual software development. And the complexity of that (business) problem does not change the tiniest bit, when switching from the Client–Server model to a Service–Oriented Ar- chitecture, or any other style. All that changes is that certain technical aspects become less complicated, when choosing one approach, while at the same time others increase in complex- ity. It is always a trade-off.

In closing

Developing, operating, and maintaining a complex software system is a huge task. The overall goal, from which the concrete areas of work can be derived, could be summarize liked this: Provide required funtionality, so that business value gets created, in the shortest possible time while minimizing the risk of introducting undesired behavior while doing so. Or in other words: Fast development, testing, and deployment without introducing bugs.

From this high-level desire a huge number of more specific goal can be developed. And for each of these various a given approach must be examined, whether or not it fits in the specific case that is being looked at. This is what makes software development so interesting for me.

If you want me to write about other aspects of this topic, please leave a comment or send an email to The same applies if you want to talk how we at JahnTech can help you with your project.



One Response

  1. Thanks Jahn for sharing your thoughts on software architecture, particularly in the context of custom programs for large commercial customers. Your perspective on the uniqueness of each software solution and the importance of understanding the underlying problem resonates strongly. Your emphasis on leveraging past experience, while not just superficially, is a valuable reminder for all of us. It’s clear that you recognize the complexity of software development and how different architectural paradigms offer solutions to specific facets of the overall problem. Your focus on balancing complexity and technical aspects is spot-on. I look forward to reading more on this topic in the future and exploring how it can be applied in real-world scenarios. If you have any further insights or specific case studies, I’d be eager to learn more.

Leave a Reply

Your email address will not be published. Required fields are marked *

On Key

Related Posts

Microservices and code reuse for integration platforms

Today I want to write about a software development approach I was able to put into practice a few years ago. I was myself very much surprised how well things worked out, and especially how fast I was able to see tangible benefits for the business side.

Custom logging with Log4j on Integration Server

Every serious IT system needs proper logging. This article describes how I use Log4j v2 with webMethods Integration Server. There is no need to change anything on the system, just install the package and it works.

External Java libraries in webMethods Integration Server

To get most out of your Integration Server you will sooner or later need to leverage the functionality of existing Java libraries. Common examples are Log4j or Apache POI (for working with Excel or Word files). Here is a short guide for this.

Running webMethods Integration Server in containers

Organizations are moving from traditional deployments to containers and Kubernetes to increase business agility. This article discusses a lot of topics that are relevant to actually reach the goal of faster delivery of value to the business through software. Because if you do it wrong, you just end up with yet another technology stack. And, as always, technology is not your biggest challenge.