Monday, December 01, 2008

[Arch] Archi-Zack!-ture

A few months ago I read a very good article series by Pavlo Baron about Software Architecture in the Java Magazin. Software architecture is an important component in software projects and you will find a lot of resources (books, web sites, blogs) which focus on this topic. He titled the series with Archi-Zack!-ture.

What does a Software Architect do? The role of a software architect in a software product becomes more important the more complex the system is. Software architecture is still a rather young discipline and the value of a software architect in software development is often underrated. As Pavlo describes in the first part, it's hard to seperate the role of a software architect with the role of a software developer. The architect enables developers to develop the software system by providing the necessary environment. The developer on the other side focuses on the fulfillment of the requirements. The motives are the same, but the emphasis differs.

The major part of the series are (Anti-) patterns about the software architecture. I picked up the most important one from my point of view. First I will enumerate the patterns which should be followed:
  • Architect also implements
    Each architect should also implement. This is very important, because as a architect you make decisions about performance, scalability and similar stuff. Without any technical backround these issues are very hard to design/answer.
  • Senior Developer = Software Architect
    It is important the a software architect has experience in software development.
  • Manages makes the final decision
    One man of the management must make the final decision. The software architect prepares the material which are used for the decision
Now some antipatterns
  • Ivory-Twoer Architect:
    The purchase to the reality lost
  • One Man Show:
    The software architect makes everything alone
  • Single point of decision:
    The software architect must decide everything, e.g. implementation details.
  • Design by Committee:
    On the other side, it makes no sense to make all decisions in the team which ends in a never ending discussion. A good mixture is the answer.
  • Architecture by implication:
    Architecture is not documented.
  • Architecture without review:
  • Meta architecture:
    Software architect remains too abstract
  • Customers are idiots:
    The Software architect is not a God!!
  • No Refactoring:
    The management does not give time for refactoring
Some people believe that software architects are the "kings", and without them software projects don't work. The above mentioned anti patterns are found rather often in projects and architects should keep that in mind. It is not important which title is written on your business card, the content, the attitude to the project and how the project team works toghether, are the keys to the success of the project.

No comments: