Since architecture is a relative new field, much debate goes on about the methods and techniques to be used within the field. Since one of the key competencies of an architects is to be able think conceptually, it is only natural for architects to engage in lengthy discussions about their tools, techniques, approaches and methods. A recent example of such a discussion can be found on the Via Nova Architectura website, where a rather opinionative posting on TOGAF 9 resulted in an involved discussion with 38 elaborate responses.

In principle, there is nothing wrong with a critical attitude towards methods. Especially in developing disciplines, one needs to be critical about the efficiency and effectiveness of the methods we apply. Regretfully, however, current discussions on architecture methods tend to be based on opinions, views and impressions rather than facts derived from thorough evaluations in practice. In the earlier mentioned discussion on TOGAF 9, several participants referred to their own (undocumented and unvalidated) private experiences. These experiences might be true and hard earned. Regretfully, however, they do not constitute a solid base for further (mature) development of the field. I would therefore like to make the case for a more scientific approach to evaluating and refining our architecture methods. This is not an easy thing to do. But is the road to maturity ever an easy road to travel?

In my opinion, we should stop discussions about architecture methods until we have conducted rigourous evaluations of these methods in practice, or at least discuss any claimed shortcomings in terms of well documented case studies observed in real life applications. For example, TOGAF, as a "purposely designed object", has an intended set of situations in which its creators will claim it to be efficient and effective in achieving certain goals. The questions to be evaluated then are: Is the method efficient and effective in achieving these goals? Are the goals relevant? Can the method be improved any further?

So rather than debating on the quality of TOGAF 9, say, I think we should focus on using our architecture methods in practice, and debate about rigourous methods to evaluate their efficiency and effectiveness in achieving results. To some architects, this may come as an unwanted call for more rigour in our field, as it may result in less heroism and folklore. An earlier call made on architects by Ron Tolido and myself to stop discussing architecture methods, but rather to get on in applying them, resulted in an even more heated debate.

Mind you. I am arguing the case for the evaluation of methods based on experiences in practice, and not the a desk-research based comparison of methods based on features that can be found in their descriptions. In the past, ample desk research has been conducted using elaborate classification frameworks in terms of their scope, viewpoints, intent, description, etc. Rather than doing more classification work, I propose we should focus on an evaluation of their practical usage. Our focus should really be on applying methods in real life situations, and evaluating these engagements in order to further improve our methods. Practical application and rigourous evaluation is key here.

Methods typically contain a description of how to "do the work". A method "to achieve X" usually contains a description of the activities and ordering on how to indeed achieve X. This set of activities, and its ordering, is quite often referred to as the method's way of working. This, nevertheless, does not necessarily mean that the way of working should be a fully elaborated recipe that will apply to all situations. A method is likely to starts its life as a method aimed at achieving goals in specific contexts. A method as a "purposely designed object", however, typically aims to be applicable in a wider range of situations. This requires the way of working as suggested by the method, to evolve into a kind of a body of actionable knowledge. In other words, a "theory for getting things done to achieve X" rather than a recipe applicable to one situation only. Quite often, the notion of method is equated to a "recipe based" way of working only. I refer to this as a "method in the narrow sense", where a method taking a wider perspective involving a "theory on getting things done" would be a "method in the broader sense". The latter requires a stronger focus on core operating principles as well as heuristics on how to make things work in specific situations. Methods can quite well start their life as a method in the narrow sense, while evolving to become a method in the broader sense. This, obviously, requires several re-design and re-factoring steps, combined with application in practice and rigourous evaluation.

Comments (5)

Only registered users can write comments.
Please login or register.