As you may (or may not) have read, I am involved in the local (Seattle) chapter of Iasa first ever IT architecture competition. We are at the point where the rubber meets the road. Team Skyscraper needs to submit their first set of deliverables this weekend on the 22nd. The deliverables are a business requirements document and initial draft of an architectural design document with conceptual and information architecture complete.
We met last Friday and the team was struggling a bit with completing the template for the requirement document. They had never seen a completed requirements document and had little idea of what should be placed in the document. I was able to bring another architect (Matt Tavis) in to talk to my team and asked him to talk about how he goes from business objectives to an implementable architecture. Matt was gracious enough to describe his approach and answer many questions the team had. Hearing two different people describe the same thing helped the team absorb what we were trying to say.
The business requirements template they were given is one that has been in use for quite a while and captures most of the required information. However, the ones I have seen in use lately are quite a bit different and more adapted to storyboards and agile development environments. Two big learnings I gained this week are that the practice of architecture is not evolving at the pace of technology or development practices and that asking someone to complete a task without providing a walkthrough of the process and example of deliverables is not optimal and can even be a disservice to the person being coached or mentored.
For Team Skyscraper, I discussed a current program I am involved in and told them the business challenge, what the business outcomes are that we are looking for, and how the outcomes will be measured. I them gave the team a high-level overview of the personas involved in the solution along with a story for each of the major functional areas of the solution. I then showed them how I manifested that information into a business requirements document (BRD) and what order I typically completed the BRD in. The team was also trying to fill the template out sequentially and for me and templates, I have never found that to be a good approach. Typically, templates start with the executive summary, business objectives, costs and value, major requirements and constraints. Most of the time, I find focusing on the details first will help a team get going and will also help to tease out some of the information needed as front matter. The analogy I used to describe the order I fill something out is was one for climbing a mountain. I look at the summit, create a high-level (or best guess) roadmap to get there and then focus on the first leg. I suggested that focusing on the first step would make the daunting task less daunting, and having that focus would help me catch detail I may miss otherwise.
For Team Skyscraper, they should be able to complete the BRD now and should be able to (based on other conversations we have had) complete the conceptual architecture and information architecture. Matt showed them how he captures information flow (informally) and they have an example of a formalized diagram of information flow. I’ve shown them conceptual architecture and information architecture. We meet again tomorrow and if the team needs it, I have an example initiative with the artifacts so I can walk them through my approach to completing both.
So what did this interaction do to/for me? It helped me realize that we have a problem with the practice of IT architecture and if I am not helping to solve it, I am contributing to it. That said, time for me to get loud!