After 5 days of architecture workshop I can say for sure that this was the best way, that I participate in, to achieve several goals for all parties that took part in that workshop. First few words about the workshop scope, content and context.
- First and foremost rule is that the workshop should be base on real project that need to be develop. Not those customer –suppliers samples, real project with real difficulties and unexpected problem (yes, people need to learn how to deal with those situation as well).
- The workshop should help system developer’s team to start up their project by laying down the right architecture for their project and validate chosen architecture. Validation process should be done by writing code that implement architecture and check if that code meets the system specifications.
- don’t try to deal with problems that you don’t think you will solve in a week time frame. If the project is too complicated or too large, find the right fragments from the project that represent project problems and can be done in week time frame.
- spend time with project leader to set workshop scope and flows. Don’t start to solve those problems while meeting with the project manager, solving problems is part of the workshop process. Architects need to see who programmers handle problems and programmers need to learn how to deal with architecture problems as well.
- If you want to integrate frameworks into the workshop, don’t build them as part of the workshop. Integrated working infrastructures or don’t deal with them at all. The workshop target is to help kick up a project, not to develop new infrastructures.
- While developing code in the workshop stick to enterprises selected development process and rules that your enterprise uses. (Case tools, daily builds, unit testing, etc’).
We start the workshop with effort to find system requirements and problems and write them down. As input we use the system design. Then we start to select the right architecture for the given specification by moving through possible architectures for problems and explaining why we think that given architecture is the best solution for a given problem. To make long story short this process should teach participates what are architectural possibilities that they have and how to choose the right one. From architect point of view it’s a great way to see how programmers react to architectures patterns. Architects, Listen very carefully to what programmers have to say …. They are the one that eventually translate your ideas into code and you should know if your set of rules and ideas are easy to implement.
After the whiteboard was full with rectangles, lines and all of those three letter words we move to the next step and simply create static class diagram and sequence diagram that resemble the code implementation of the chosen architecture. If that process raise flows in architecture … GREAT! Explain way and how to solve them. Before the architects try to solve the problem let programmers to deal with the issue. As an architect watch how programmers react to that problems see what solutions they choose and what motivate them to choose that solution. Remember those considerations, you might use them in your work while you create new architecture for new system.
Last task is coding. Use this step to ensure that programmers are following enterprise development rules. This part is mainly to create base project code so the team will go back to work with base code containing samples for code implementation for architecture solutions. Another target is to let participants check out architecture while running code.
That’s what I can say from my own point of view. I learned a lot from that workshop and hope that those guys that participate learn as well. I think that such a workshop is win-win situation to developing group and enterprise architecture group. I strongly recommend programmers and architects to promote such workshop in their organizations.