Hate him or love him, but Marc Andreessen, the founder of Netscape Communications, was named the blogger of year by the Inc. magazine. The Inc. magazine is geared towards both current and future entrepreneurs, so if you have a trace of an entrepreneurship in your blood, you will most likely find the information published by Marc very insightful, analytical, and to the point. Having spent some time reading Marc's musings, I was initially puzzled by his assertion that it's always important to be a small fish in a big pond. He urges everyone to "optimize at all times for being in the most dynamic and exciting pond you can find." After mulling this over for a short while, I finally shouted "Eureka," kicked the bathtub and signed up for the Jax Architects meeting. I was bound to be the small fish there, just sucking up all the knowledge coming my way. Big Kudos to Jeff Barnes of Microsoft for yesterday's very informative architects session; it gave me plenty of new directions to pursue to be better at architecting and managing the software systems. Major props to all attendees as well, the discussions are always interesting and offer fresh perspectives on the old issues. The arm wrestling match was an extra bonus (Ok, just kidding about that).
While I have designed, built, tested, held hand, kissed butt and generally gave my unconditional love to many software solutions throughout the years, every new application brings with it an opportunity to apply freshly gained knowledge. The most recent piece of research that I am looking forward to applying comes from IEEE 1471-2000, and it has to do with documenting software architectures. In the past, the documentation of my architectures consisted of multiple UML diagrams, user interface prototypes, Word documents and Excel spreadsheets documenting my schedule estimation efforts. I say "efforts," since software estimation is still an art that remains to be mastered by yours truly. Incidentally, I have yet to personally observe a detailed and accurate software estimating effort that does not involve reaching somewhere unknown (or unspeakable) and pulling out a random number of developer hours.
IEEE 1471 is the recommendation (not a mandate) on documenting software architectures. After the first glance at its recommendations, two thoughts crossed my mind:
1. I am already doing this today.
2. Why does it have to be so confusing--what the heck is the difference between a "view" and a "viewpoint?"
While I was already doing many things outlined in IEEE 1471, what I was lacking in my efforts was the completeness of architectural representation of the system. How did my Word documents relate to each other? What were the most important concerns of the system--security, reliability, accuracy, etc.--and how would anybody know that these concerns were the most important? At what point can you be certain that all of the concerns of the system and all of the potential stakeholders of the system are satisfied? The IEEE recommendation put those things in perspective for me.
Here are the main tenants of IEEE 1471 recommendations:
--The architecture of the system addresses all concerns of system's stakeholders. Concerns include security, accessbility, performance, functionality, etc. of the system.
--A concern or a set of concerns can be addressed by one or more views of the system. A view is the representation of the whole system in the context of one or more concerns.
--A viewpoint is the template from which we can develop individual views. Each viewpoint should have a name, describe what concerns it addresses and the stakeholders it is aimed at. Each viewpoint should also specify the modeling techniques, analytical tools, or language that will be used to construct the view.
The IEEE recommendation is clearly an evolutionary development of the Zachman framework that was developed in the 1980s. The Zachman framework, a de facto framework for documenting enterprise architectures according to Wikipedia, defines 6 perspectives (viewpoints) from which an enterprise can be viewed and offers 6 focus areas for each perspective. By filling in the resultant 6x6 matrix, an architect takes an additional step towards ensuring the completeness of the system's architectural description. Yesterday, Jeff Barnes briefly talked about Zachman framework at the Jax Architects meeting. In contrast to Zachman framework, IEEE 1471 does not dictate any preset viewpoints of the system; it simply recommends documenting the architecture in the form of viewpoints and views.
So, for my next project, the very first thing I will do is fire up a word processor, write down a comprehensive set of concerns of all stakeholders of the system. I will then create empty viewpoint templates addressing those concerns. From these viewpoints, I will develop the views. After that, I will systematically drilldown to the lowest level of detail in each view, eventually even getting to you, the stick-man with the giant bubble.
Here's to all the big fishes already following the IEEE 1471 guidelines--Cheers and have a great weekend! Hoping to see many of you at our next "geek outing" in December--we will meet somewhere informally (probably Dave and Buster's so I can kick Bayer's butt in basketball) to drink beer and (possibly) talk about software architectures. Bayer White will post the information on JaxDug's website regarding the location and time of this meeting.