Is your software architecture explicit?

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 do not think before you code.

protected String getSystemArg(final String key) {
  return parameters.get(ARG_PREFIX + key);

public Map<String, String> getSystemArgs() {
  final Map<String, String> map = new HashMap<String, String>();
  for (final Map.Entry<String, String> e : getParameterMap().entrySet()) {
    if (e.getKey().startsWith(ARG_PREFIX)) {
      final String newKey = e.getKey().substring(ARG_PREFIX.length());
      map.put(newKey, e.getValue());
  return map;

Both methods in the class handles the same parameter map. The first method returns a “SystemArg” for a specific key from the parameter map. The same parameter map that the second method in some obscure way gives you in total (but with keys without the ARG_PREFIX).
The first method is protected. The second is public. Which one would you have used if you have a key for which you want a “SystemArg”? Which one would you like to use?
This is an example of what you get if you do not think about your design. A public interface of a class that blatantly shows the inner workings, and a protected interface that is what should have been the public one in the first place.

To me, an explicit architecture is visible. All team members knows about it, i.e. it is well communicated. To make such an architecture you need to be aware of the decisions you make and why. This means that the team(s) need to have discussions, perhaps draw some interaction diagrams on a white board, maybe make a domain model and whatnot. Just do something. Anything is better than nothing.

White board area next to Sprint Backlog
White board area next to Sprint Backlog
Example of explicit architecture
Example of explicit architecture.

Agile does not prohibit you from doing design or architecture. It certainly does not prohibit you from using your brain. It only states that you shouldn’t do it all upfront, but rather evolve it over time, just as your requirements evolve. So please, think about your architecture and make it explicit. Because if you get an implicit architecture, you will be knee-deep in technical debt and then you will call me to come and fix it…

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.