This workshop is completly different from what you are used to where you are sent by your company to be trained. You don’t arrive, sit down, listen and leave the room being an architect. Instead you only go through 50 slides in two days, and spend your time working in small groups and interacting with the others. At the end you leave the workshop with your head full of ideas.
Then comes the definition of an architect and its role. Again we worked in groups and everybody came our with their own definition. The result is that there is no right answer. Depending on the team, its size, individual skills, the architect could lead the team, develop, mentor, check the quality of code… and any combination of other skills that you might think of.
Then we looked at where the architecture is involved in the software development lifecycle. Again, depending if you are using waterfall, RUP or agile methodology, the archiecture could be defined at the very begining before development starts or at each iteration. In an agile development the architect is the one who has the technical vision and makes sure the team leads to this vision throughout the interations. And because Simon is an hands-on architect, he stressed out that the architect should be involved in all phases of the project not just analysis and design (which means in the phases of prototyping, coding, testing…).
We looked at what drives the architecture. As I said, the architect must keep the functional and non-functional requirements in head. But he has to take into account a set of constraints : costs, skills in the team, time, technical strategy of the company, existing systems, company politics, past failures, legal topics (licensing for open source software for example).
Then Simon gave us functional and non-functional requirements for a case study. We had half a day to work on it in small groups and each one had to come out with an architecture and present it to the others. That was really interesting. Because this workshop is technology agnostic, people came up with different solutions. An intersting aspect was the notation that people used. It was a bit of everything, from boxes and arrows, to more structured UML diagrams or text. It goes to show that everybody knows how to model classes, interaction between classes of even state, but modeling an architecture is not as simple and straight forward.
And of course, it’s always a pleasure to go back to London, my second home, meet my friends, have some beers in British pubs, and enjoy Indian curries.
