Architect – what architect?

In many projects and organizations I am constantly meeting software architects. Given the quantity I’d only expect only a fraction of software development projects to encounter any issues in software architecture and design. As we all certainly know, quite the opposite is true.

Ok, nice and true words, but what exactly is the reason for this observation?  

Of course, I absolutely have no clue :-; So let me just make some assumptions.

Could it be that the term “software architect” on a business card is subject to a variety of different interpretations?

In one company, someone may be promoted to software architect, just because she/he is the only one who owns a pattern book. [Beware of humour!]

Consulting companies may entitle some of their engineers as software architects, because they can charge more for architects than for developers.

A handful of companies may offer a challenging education program to become a software architect.

With other words, it is not clearly defined what a software architect is or should be. Nothing prevents you from calling yourself a software architect. You may remember that I am proposing a rather tough profile for software architects. Well, I know too many projects that failed  miserably because of lack of competencies, experience or skills by the responsible software architects.

Note: not only the skills count! As software engineering is heavily related to communication and learning from failure, becoming a software architect requires starting as a developer, taking over more and more responsibilities over the years, before finally turning into a butterfly.

Another issue I often encounter is the missing separation between software and system architects. Today, many system architects are also considered as software architects. This might work very well if the system architect is an experienced software architect. Likewise, the aforementioned setting is adequate for software-intensive developments. But here again, the system architect needs also to be an experienced software architect. If the latter doesn’t hold, the software relevance is obviously underestimated and will inevitably lead to trouble.

Hold on, there is even another possibility. Even if you can justify that you are a software architect now, this doesn’t mean you’ll be a software architect forever. One of the most fundamental challenges is to know the state of the art of relevant software technologies and methods as well as appreciating and practicing coding and testing skills. Guess, you have been appointed as a software architect ten years ago, but in the meantime you were constrained to using UML tools, Powerpoint and other Office applications. With other words: would you trust a surgeon to operate on your heart who lacks ten years of practice?

I bet, you made some similar experiences in your environment. If that is the case, a comment would be highly appreciated. If not, even more! 

Sick Architecture

You may wonder why my publication rate in this blog has decreased dramatically. I am staying at home due to an infection for three weeks now which wasn’t that helpful for my blog.

To keep things running I have decided to create a new posting. Well, the title is intentionally related to my current health situation.

To be honest, I think that software architecture design reveals some interesting commonalities with sickness:

• Both often require intense treatment by experts
• Different experts offer different opinions and treatment plans
• Both are typically open-ended to some extent
• Both are not subject to planning in most situations
• Both mostly feel very miserable
• To reduce the risk of getting infected some kind of prevention strategy is always a good advise
• It is better to cure the cause not the symptoms. Thus, be aware of all interdependencies and follow a holistic approach
• Viruses are a problem in both worlds
• Healthcare never ends – it is important in the whole lifecyle
• Learning from failure is recommended to avoid similar problems in the future
• Prevention is always better  (i.e, cheaper) than healing

Most software architectures I know are not in a good and healthy shape - at least in some intermediate phases. Why? Because they were not devleoped with the aforementioned bullet list in mind.  Thus, health monitoring (i.e, reviews) and treatments (i.e., refactoring) should be an essential tool in the architect’s framework.

Does this sound reasonable?

Data centric Architecture

In most projects there is a big emphasize on functionality. Use case modelling defines responsibilities of the system as well as how it interacts with actors. Logical modelling then maps the use cases to related subsystems/components which, of course, is functionality based. At the end we'll get functional interfaces between subsystems or between components. Do you recognize that methods such as UML mostly focus on methods?



However, in many cases the data exchanged between architectural entities is rather complex. For example, in healthcare scenarios complex structures with patient information or charging information are the rule. Not dealing with data as first class citizens might lead to various issues such as versioning problems, or inadequate partitioning or aggregation of data. Thus, architects should deal with data modelling very soon if they are facing complex structures in their development projects.



Data modelling starts with the domain model. What are the main entities in your problem domain and which kind of data do they need to persist, share, or transfer?

Then in the next "layer" when we are introducing the subsystems we'll have to think about data structures in subsystems and data structures exchanged between subsystems. For example, what exactly are the data structures required in the functional interfaces. Obviously, these data structures can be partially derived from the domain model with further data structures required by infrastructural entities or non-functional qualities.

In the component layer we are starting to deal with finer grained data types.

Last but not least we'll have to define how data is mapped to implementation artifacts.



Thus, we should also follow a top-down approach for data modelling. And likewise we need to consider bottom-up constraints such as special data requirements of infrastructures or platforms. With other words, data modelling must go hand in hand with all the other architectural modelling activities:



Important questions to ask when modelling data:

• Who is the originator of data?


• Who is the consumer of data?


• How does data move from the originator to the consumers?


• Do we need to collect/aggregate data from different sources (transfer objects)?


• What about quality constraints such as performance (e.g., caching data), security (e.g., encrypting data), modifiability (e.g., versioning data), concurrency (e.g., locking data), availability and reliability (e.g., replicating data, data persistence)?


• Where and how is data stored?


• How do different data structures depend/relate?

I think, data modelling is an underestimated and undervalued activity in architecture design. What about your experiences and opinions?

Ineffective Communication

It might not be that obvious why time management is of high importance especially for software architects. But of course, being a software architect in a mission critical project requires your full attention. However, in a couple of projects I met software architects who were simply overwhelmed by communication requests and finally got stuck in a kind of waste time singularity. Ineffective communication can significantly reduce your productivity. 

Unfortunately, there are many opportunities where your focus on the real important things is easily lost.

• My favourite are unnecessary meetings (including telephone conferences).  As software architects are caught in the gravitational center of the project they receive a lot of meeting requests, by managers, developers, other engineers. If you are a very communicative and friendly person – and I bet you are – you might be inclined to say “yes, we can” to all those nice invitations. It is often overseen that meetings also require preprocessing and postprocessing activities. Hence, don’t just count the time you’re spending in the meeting room! Consider carefully what type of meeting you are asked to attend. Is it an essential meeting where your participation is absolutely required (class A meeting)? Or more one of those nice-to-have-meetings? Only accept class A meeting invitations! Even for class A meetings ask yourself whether this meeting has the right setting in terms of people invited, time frame, goals, agenda. With other words: is the benefit you obtain larger than the time spent? Sometimes, a small face-to-face meeting offers more value than a large official meeting. And of course, act thoughtfully if you invite to meetings yourself! As an Outlook junkie do not only enter meetings in your calendar but also time slots for your actual work. Mind the fact that other people tend to fill the gaps in your calendar assuming those gaps are indications of idle time. Personally, I also enter slots for my spare time, just in case. Needless to say that you should also consider travel time in this context. Care about meeting netiquette: there is no place for cell phones or notebooks in a meeting – a few exceptions granted.
• Another critical challenge is e-mail. Communication by e-mail can be very ineffective (but also the most effective means in other situations). Try to reduce corporate spam which consists of all those mails which steal your time for no good reason. Organize your inbox in folders and prioritize mails as soon as it arrives. Process the mail depending on its priority. Read mail only at specific points of time and tell your communication peers about this fact. And do not send unnecessary mail yourself! Before writing an e-mail, always hold on and consider whether you would also have sent an letter containing the same information in the stone age of communication.

At the end, it is the project success that counts. Good results require effective architects with as much productive working time as possible. Productive hours depend on effective communication. It is the quality not the quantity!

Vacation - the end is near

The last weeks I have relaxed a lot: visiting Dresden, running, swimming and biking, as well as practicing with my DSLR. In addition, I read two books on Scala, updated an article on D (the language), installed several apps on my IPhone (yag – yet another gadget),  prepared slides for ADC 2009 and OOP 2010, participated in a new episode for our SoftwareArchitecTOUR podcast, … and spent a little time on further expanding my work on architecture refactoring.

However, I intentionally did not work on software architecture or on this blog. This will change beginning with upcoming monday. Now, that I got some new and fresh ideas, I can continue my journey on software architecture issues.

By the way: I did not mention it so far but maybe you like to follow me on twitter (username: stal_m).

And now for something completely different

This is my first week of a 3 weeks vacation. It is really hot in Munich why I am currently enjoying swimming, biking and visiting beer gardens more than software engineering.

Nonetheless, I am currently educating myself in a new programming language. Scala by Martin Odersky combines a pure object-oriented langauge with functional features. And it runs on the JVM. An earlier version of Scala does also support the .NET CLR.

What I like most is the proper integration of functional features. Closures, for comprehensions, nested functions, pattern matching are notable examples. While Scala is statically typed (it is not a dynamic language), it offers type inference for variables, arguments and results.

In addition, it provides some cool extensions to Java: all types are objects, no static members, support of covariance and contravariance, to name a few.  Traits are available instead of interfaces – they can behave like interfaces but also allow implementations of methods. With traits the problem of multiple inheritance (mind the diamond configuration) can be avoided. This is possible by introducing inheritance linearization and a kind of virtual super.

With all of these features Scala code can be much more compact than Java - and it interoperates well with Java components.

Well, I am really kinda enthusiastic. If you ask me, Scala could be a strong competitor for Java and C#.  But of course, there is not a big company backing Scala such as Sun or Microsoft. Thus, the community will decide.

Loving the JVM but preferring other languages than Java? No more excuses, Dave!

Neverending Story

One of the prominent questions I often hear in software development projects is when to start with architecture design. Sometimes, architects hesitate to start until almost all requirements are available in high quality. This strategy is highly recommendable when you like to postpone architecture design forever. There is not a single project with medium to high complexity I remember where we knew all forces in full depth and breadth at project start.

First of all, it heavily depends on the software development process. In a Waterfall model without iterations you are stuck anyway. Thus, I generally recommend an iterative-incremental approach. In software developments with all their volatility only piecemeal growth can succeed.

It is important to have a sufficient quality and quantity of requirements available, for example, the most important 30%-50% of use cases and non functional qualities with unique priorities. This way, you can come up with a conceptual architecture which you can then use as a base for iterative-incremental refeinement.

After the baseline is available prioritize all user requirements (use cases), map them to end-to-end scenarios and integrate them into the architecture, keeping the non-functional qualities in mind. To deal with non functional qualities let key developers, architects or even teams work on principles and guidelines how to address these qualities. Do this after the baseline architecture design but before starting the end-to-end iterations.

As soon as new requirements appear or have been concretized assign them priorities and put them into the “backlog”.

To introduce a kind of safety net for embracing change, introduce test-driven design methods, flash architecture reviews after each iteration, and (architecture and code) refactoring activities after each flash review.

Keep in mind that sometimes you need courage to decide even when not all details are available.  It is typical for all creative and volative acts that not all details are known in advance, nor the ways how to cope with them.

As a consequence, it is much more productive and effective to follow wrong paths sometimes instead of following no path at all.

To keep it simple: Prefer acting over reacting