Java & Spring: More Than 15 Years of Experience as the Foundation for Software Architecture

I have been developing in Java for more than 15 years, and I’ve used the Spring Framework for almost as long. This experience isn’t just a line on my CV. It is the foundation for the architecture decisions I make today.

Java as the Constant Across Changing Roles

My career has taken me through very different environments: comSysto, kernpunkt and codecentric on the IT consultancy side, and Audi and MAN on the large-enterprise side. Each role came with its own requirements, teams and constraints. At IT consultancies, clients and business domains change often. In large corporations, the focus is on system landscapes that have grown over time, long lifecycles and many stakeholders.

Java was the constant throughout. Because the language and its ecosystem are widely used in all of these settings, I could carry experience from one project to the next. A pattern that worked well in one environment could be tested again and adapted in another. Over the years, this builds up experience that depends less on individual projects than on recurring questions: How do you split a system sensibly? Where does each responsibility belong? What keeps code understandable years later? Learn more on the Software Architecture page.

How Spring Has Changed Over the Years

After using Spring for this long, I have seen the framework itself evolve. In the early years, a Spring application was configured mainly through large XML files, which explicitly declared beans, their dependencies and how they worked together. Over time, annotations and Java-based configuration became the norm, moving configuration closer to the code. Spring Boot then took this approach further with sensible defaults, auto-configuration and standalone applications that are much faster to set up.

Having seen this evolution firsthand is more than a historical footnote. If you know what Spring used to require explicitly, you have a better grasp of what Spring Boot now does automatically behind the scenes. That helps when an auto-configuration doesn’t do what you expect. It also makes it easier to judge which conventions to adopt and where to deliberately deviate from them.

2011: Certified Spring Professional – Understanding the Framework Systematically

In 2011, I earned the SpringSource Certified Spring Professional certification, which was based on Spring 3.0 at the time. The real value came less from the certificate itself than from preparing for it. In day-to-day project work, you usually learn only the parts of a framework that the current project needs. Preparing for the exam made me work through Spring systematically and in full, including areas that had played no role in my own projects up to that point.

This systematic understanding pays off over time. There is a difference between simply using a framework and understanding its concepts and design decisions. That understanding is what lets you use Spring confidently in new and unfamiliar situations.

What 15 Years of Java and Spring Mean for Architecture Decisions

The experience I have built with Java and Spring over more than 15 years is still the basis for my architecture decisions today. Three themes run through it:

Structure: A system needs a clear organization so that new team members can find their way around and changes land in the right place. Clear responsibilities: Every component should have a clear purpose. Spring has always encouraged this through dependency injection and by thinking in well-defined building blocks. Maintainability: Software usually lives much longer than the project that creates it. How easily a system can still be changed a few years later is therefore a question to address from day one.

This experience holds up because it combines many years of hands-on work in changing environments with a systematic understanding of the framework. It doesn’t rest on a single project. It rests on patterns that have proven themselves over many years and across different organizations. Today, these applications often run in containers in production. See the Cloud & Infrastructure page.