You know, every system has a software architecture and a software design. Whether you think about your system’s architecture or not, it will have one. Here is an example of two methods in a class I recently saw. It is not architecture, it is good old OOD, but it exemplifies what can happen if you

Have not all of us been in a spot where we feel an urgent need to fix some quality such as performance or availability, which takes a change in the architecture for effect? And yet we are pushed to work on new features instead?

There is a chasm between the tech side and business side that has to be bridged before a sound dialogue about system architecture can take place.

Continue reading

It has been 10 years since the Agile Manifesto was written and although I have not been following the agile community for that long, I have been a developer in Scrum teams since 2007. In total, I have done system development for 30+ years so I have lived and breathed both waterfall and RUP before trying Scrum.

So what is on an agile developer’s mind these days? Here are my current reflections on three things today, Agile Development, Architecture and Acceptance Testing.

Continue reading

Yesterday I held a presentation on the subject "Agile and Architecture" at EDB. They have an internal competence network which meet

regularly and discuss agile processes and methods.

My point in this presentation was that every system has an architecture that determines the qualities of it. Given a set of functions, different architectures will give these functions different qualities, such as performance and cost of maintenance.

This is still true, no matter if you do waterfall, RUP or Scrum.

Besides understanding the most important structures of a system, it is an architect’s responsibility to understand and influence the design principles.

One common and important set of principles are those of error handling. It is good to have the same principles throughout the system as it produces fewer surprises and mistakes.

In this post, I will discuss some principles that including checked exceptions and Null Object, which you may not fancy. But it is always good to think this subject through, so please come along.

I once worked in a rather large project, about 1000 persons. There are many stories about that project but the one that I’m thinking of now is that we loved to say "stable interface, we must have stable interfaces".

Now, stable means not changing which means nothing gets better. So why would anyone want stable interfaces? And what should we say about the opposite, "unstable"?

Stable interfaces is a cornerstone in tactics for modifiability, so how do stability and modifiability go hand in hand?

Do you see my finger?

I teach a course on System Architecture. It is a three-day course attended by experienced developers who want to go further in some respect.

What strikes me most is that the majority has never read any architecture document. Since writing such documents is one of the main topics of the course, I have a long road for them as they haven’t read any.

So, when you are faced with a system that you are about to change, how do you go about to understand it?

Functional requirements describe how a system delivers value. However, the quality attributes of those functions will make or break it. For example, if your functional requirment is about something that takes you from one city to another, I have a car to sell. Really cheap, for that matter.

Every system has an architecture. It may be elegant or it may be ugly. It may be described or it may be unknown. But it is.

Architecture is what determines the qualities that the system delivers. Is it fast? Is it secure? Can it be extended? Does it scale?

The qualities you strive for should determine the design of the architecture – not the other way around.