The Software Architecture Essentials Seminar
Today I attended a half-day Software Architecture Essentials Seminar at the local Microsoft offices. This event followed closely on the heals of the Developers Academy event which Microsoft organized yesterday. While the organization of the events, in particular the Developers Academy, was somewhat lacking, Microsoft deserves a lot of credit for organizing these free events.
The Software Architecture Essentials Seminar was presented by Ron Jacobs of ARCast fame. Ron is a very good speaker and the seminar was both interesting and entertaining. Software architecture is a subject that is close to my heart, which is why I’m lecturing about SBC solutions architecture at the upcoming Briforum conference. If you get a chance I highly recommend attending Ron’s presentations (and mine),
(He is also a gutsy guy, installing a Vista patch on his laptop in the middle of his presentation. Well he learned his lesson: he had to go without slides for 10 minutes.),
There were two aspects of Ron’s presentation that were slightly off in my mind. First Ron’s definition of the scope of the architect’s role encompassed activities that I usually attribute to system/business analyst (analyzing organizational processes), and to product managers (gathering and maintaining requirements and functional specifications),. While I agree that it’s always a good thing to see the bigger picture, the architect’s role is complicated enough without assuming the responsibilities of other roles as well. When I asked Ron about this he explained that the definition he used was more applicable to enterprise customers and system integrators than software companies, including Microsoft itself.
Second, Ron ignored an important aspect of change. Not change in specifications during the project, which he did address, but the aspect of the need to change the product after it has been released. For example, Ron used the standard building architect metaphor, yet few buildings need to undergo radical changes every two or three years after they are completed! Architecting for this type of change is an important and unique aspect of software architecture.