Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Tuesday, January 20, 2009

Views on a Cat

Suppose, you're going to design a new software system for a specific domain. One of the first steps is to introduce a domain object model which comprises the core entities in the domain as well as their relationships. That's easy, you might say. If it is that simple, why do so many  projects fail in establishing the right domain object model? And, of course, this challenge inevitably appears in all kinds of modeling activities.

But now for something completely different - as Monty Python would say. I got two nice cats at home. In order to model a cat, there are different possibilities:

  • (ATOM) We could consider a cat as a mere collection of molecules.
  • (GENE) Obviously, a cat can be uniquely identified using its DNA.
  • (BODY) Another approach is modeling a cat as an aggregation of subsystems such as legs, joints, muscles, intestines.

Does it make sense to apply the first model (ATOM) in order to understand how a cat moves? No, because the detail level is overwhelming.

Is it useful to use the third model for understanding all chemical activities within a cat? Definitely not!

With other words, we can model the same physical concepts in different ways, each of these views strongly depending on the purpose of the model. Don't let yourself be confused. It is not as simple as having only one model for one purpose. For example, to understand the physical appearance of a cat, you could apply model ATOM as well as model BODY.

What are the implications of this observation?

  • First of all, you might require different models (views) in order to define and understand a software system.
  • Secondly, each model should be motivated by a concrete and useful purpose.
  • Thirdly, all participants should agree on syntax and semantics of the model.
  • And last but not least, all models should be documented.

Mind the word "useful" in the second bullet point. As organization drives architecture, the organization often directly maps to entities in the model. If your organization is badly structured, your architecture will reveal the same problem. Think about this in the context of your own organization.

As another consequence I'd like to emphasize that it is not sufficient just inventing a couple of sophisticated models. The set of models should also be simple, complete and consistent. All of the models should complement each other in a meaningful and appropriate way. That's the reason why we got view sets such as the UML 4+1 view.

Unfortunately, I often sit in project meetings where people strongly believe they are all sharing the same view of their domain, while in fact they are not. Endless discussions might be an indicator for this problem. Thus, it is essential to explicitly come up with a common domain model that is agreed among all participants. Basically, the design of such a model should be one of the early steps  in a development project (directly after scoping but before architecture design). Needless to say that software engineers are surrounded by models: they have specific views of the problem domain and the solution domain, use tools such as compilers or database systems that themselves are built on top of models.

If a software developer's life is about models and model transformations (e.g., the mapping from the problem domain to the solution domain) we should consider models as first class citizens and invest sufficient time for choosing the right viewpoints and establishing the right models.

Interestingly, even our view of the physical world such as the way we understand a cat is determined by models. But this is a different story.

Friday, January 09, 2009

Archidictatorship versus Develepocracy

In the software development projects where I am involved as an architect I  can typically observe different types of software architects. Let me illustrate two extremes:

  • Some architects try hard not to decide anything or at least not too early. These architects typically integrate all other project participants in the decision process.  On one hand, this can be a very successful approach. If everyone agrees to important decisions, everyone remains motivated. On the other hand, the same habitude leads to the risk of decisions being postponed endlessly. Eventually, architects constantly drawing new UML diagrams or deep diving into technical details are a problem not a solution.  In most cases, wrong decisions are better than no decisions, because wrong decisions can be detected very early and all problems resolved. Think of refactoring as a tool!
  • Other architects prefer a kind of tyranny. They got a lot of self esteem, believe to know everything, adore the Borgs for their "resistance is futile" strategy. This style of leadership can come very handy in critical situations where project success depends on strong leadership, for example when you require fast decisions. The downside of this dictatorship is that architects behaving this way may not get buy-in from other participants, thus leading to a high level of demotivation. And obviously, too much power in the hands of the wrong persons can lead to projects being doomed to fail miserably. A negative implication might be that those dictators want to get involved in every decision, even in unimportant ones.  As no one is able to understand all details in the case the project is large enough, you'll inevitably will experience lots of wrong decisions.

You will argue that these leadership styles are not specific to software architects, and, of course, you are absolutely right!

What I'd like to emphasize in this posting is the importance of leadership skills for software architects. Of course, there are situations where an architect should be dictator, and other situations where democracy might be the more appropriate choice.

Unfortunately, or should I say fortunately, all of us got different personalities. Your leadership style should fit with your personality, because otherwise everyone will recognize the discrepancy.

I won't cover leadership styles in too much detail because there are persons much more knowledgeable than I in this context. Just read this one or that one. A Web search will even yield more material.

What I consider really helpful is a kind of self analysis. For instance:

  1. Personality: analyze your own personality, try to find your strengths and weaknesses. Ask other people how they assess you as an architect. How do you evaluate yourself acting as an architect? A very helpful tool might be to analyze previous projects: where did you succeed and why and where did you fail.
  2. Leadership Styles: read about all possible leadership styles. Nothing more to add here.
  3. Context: Think in your project context what leadership style should be applied in which situation. Of course, you can't act as a dictator in front of your head of R&D. Likewise, always striving for full agreement by every developer can result in endless recursion.

For a software architect, the time spent for communication might be as large as 50%. Communication means interacting with other people, informing them, guiding and mentoring them, or getting their buy-in. Without the right social skills and leadership style, a software architect is doomed to fail.