Tracking change and innovation in the enterprise software development community
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
Create REST
-enabled Web Apps
with Project Zero
from IBM.
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
Posted by Abel Avram on May 05, 2008 03:12 AM
Markus Voelter was interviewed by InfoQ during OOPSLA 2007, and was asked to share his opinion on today's practices about writing software architecture documentation. Markus certainly supports the importance of writing such documents, but he has a different take on that compared to the general trend. Many people think of UML as the main tool used to write software architecture documents, but Markus says UML is not the right tool. While he agrees that UML has its benefits, he continues pointing out that we should be using tools which allow us to create a formal model which can be automatically processed and its integrity can be verified. Then we should be able to generate the code from it, including the infrastructure dependency code.
Markus Voelter is also a great fan of patterns when it comes to documenting the architecture. He says that we should be using patters whenever possible because the reader will be able to understand the documents faster and clearer when we use commonly shared concepts.
The entire interview can be accessed here.
The Agile Business Analyst: Skills and Techniques needed for Agile
Hibernate without Database Bottlenecks
RESTful todo list sample tutorial with Groovy & Project Zero
Introducing Project Zero: Building RESTful services for your Web application
The voice of Markus sounded pretty familiar to me, so I would assume that he is the interviewer of SE-Radio because he mentioned it during the interview :) About this topic, I totally agree with you Markus you say a lot of things that I have mind and generates a lot of discussions in my course when I teach about Software Architecture Documentation (slides in Spanish here). Nowadays we have a lot of ways/tools of communicating the architecture, blogs, wikis, webcast, podcats... and the best way depends on the context of the project, the target audience and the part of the architecture that you want to communicate. The only things that you don't mentioned and I consider extremely useful regarding communication architectures is keeping in mind that the architecture can be communicated in terms of perspectives (or view points) and each of them has to be targeted to an specific audience, so with that you can define in a high level the language (or meta-model/diagram/text) that they understand. I really enjoyed this interview, thank you very much!
Very good interview. Many practical and down to earth suggestions.
Can anybody let me know what exactly the title of "Gregory's book" is? Thanks.
Such a great interview packed with useful answers. I really appreciated hearing how pattern reviews were done and the strategies to communicate and document architectures. Thank you!
Well, I'm not sure, but he might mean Gregor Hohpe's Enterprise Integration Patterns.
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
5 comments
Reply