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 info@jahntech.com. The same applies if you want to talk how we at JahnTech can help you with your project.
One Response
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.