Tech Ed - Software Architecture

Today we have enjoyed a whole series of seminars today from Ron Jacobs (Microsoft Architect) and Scott Hanselman (Corrillian Architect). Both are superb speakers and clearly experts in the domain of software architecture.

The key points we took away that a key to an architect are;

Different lenses on documentation. It is vital the correct lens is applied to the current customer. For example the sales director does not care about how much money you have saved on servers or disc space … the sales director lens must be customised with sales information such as – this system will allow a transaction to complete 25% quicker. Whereas the IT director does not really care about the sales information so the IT director lens must be customized with IT information such as we can now decommission two other servers and save you £1500 a year in maintenance.

Executive buy in. It is vital to have "suits" buy in, to have them understand the benefits of how investing in an architecture will bring long term value to the business as a whole and to individual projects. Should management buy in be failing … then maybe a sneaky shadow government could form … a team working in their own time which achieve a final product with now has metrics (see below) to present to the management. Obviously very risky but does show team commitment to a process.

Metrics are vital and play two key roles;
First, working towards executive buy in to be able to show the sales director how sales can go through 20% quicker with this new technology or show the IT director that 30% development time was saved on project X because the architect already has a pattern for this main problem and some of the existing architecture was re used.
Second, and probably more important in order to demonstrate successfully delivering requirements both to the technical team and to the customer.

Testing. Implement automated testing and continuous integration. Therefore each unit of work results with a complete set of test results and on success a complete build. To fully benefit from automated testing it is important to remove as many "word" document requirements as possible and include them within the automated testing tools. For example; the requirement that the home page must load within less than 3 seconds on a 512mg connection - incorporate the load time testing within the automated test tools and then the only dependency on building is to ensure the tests are passed and not someone remembering to have to run further manual tests.

Responsibility. During the Q&A session it was explained that neither Ron nor Scott had any management responsibilities. They have a clear technical responsibility right to the top management but in regards to holidays, career and general HR stuff they are not involved. They noted this is on purpose and significant in that now the architect can focus on the technical goals of the company as a whole and get the positive buy in from the techies without any management politics becoming involved.

Methodologies. Tying in with the automated testing and continuous integration is agile. This is key when the team focus on delivering business benefit in small quick iterations. Worth looking at SCRUM.

On a more general note for very large scale smart client development Ron Jacobs points you to the CommSee case study.