The Boxology paper seems to represent an wonderfully complete reference sheet in case an architect needs to make their design decisions based on the expected flow of data and control. The tables presented in the latter portions of the paper are precisely the sort of resource I would expect to see printed out and tacked up on a cubicle wall to act as a simple reminder for what needs to be done, or perhaps published in a "pocket guide to Architecture". The problem is that the author has done a wonderful job of laying out way to differentiate theoretical systems based on key groupings, but it seems to exist in a sort of bubble that ignores the fact that a reader may be looking for ways to directly apply this to a project. I found myself looking this document over for the architectural equivalent of a code snippet just to see if I was following him correctly. As there doesn't seem to be that, just those charts and a guiding checklist at the end, I feel the author has left the task incomplete. He has provided us a wonderful rubric but no real instruction on how to go and apply it in our real world.
The second biggest complaint I have is that, like many theoretical papers, they seem to assume that all systems are designed both correctly and coherently, with one major way to handle flow of information or control. While I would love if that were the case my time in the professional world has taught me that due to various business concerns: release dates, promotions, loss, various other HR shuffles, and the sheer power of business cases and market segments means that in all likelihood the system we would use these tables to classify may only fall "mostly", or even only "somewhat" into one of these categories.
Monday, August 31, 2009
A Tale of Two Systems
From the discussions about the two systems there seem to be two major differences that filtered down to create the rest of the issues with the messy project and the successes of the more elegant one. The first and foremost in the author's mind seems to be that the first project failed because it lacked any sort of uniform design philosophy or goal, which he takes great pains to point out the second project had again and again.
I find two things odd about his presentation in this matter, however. Not once does he talk about the business pressures that were put on the second development story, just that "enough time" was given to the team to get the project done. Which strikes me as odd considering how often he seems to attack the first project for the constant efforts involved in meeting its unrealistic business deadlines. The other thing that tickles my mind about this is how much his experiences might have changed had he been with the messy product from the beginning. As he notes he came it later in its life cycle, and had to deal with all the issues listed, when he talks then about the wonderful experiences of the other project. If he'd been in those first initial meetings when the first project wasn't designed I think his attitude would change significantly.
The other main difference he highlights is the difference between standardization of the two projects, with the first project not experiencing any conformity, not even to the language and environments being used, to the supposedly total harmony he helped design in the wonderful project. Standardization of tools, naming conventions, and the rest is an extremely important step, not to mention standardization around a goal, and the first project definitely suffered for it heavily.
In the end though, his point that the first project was constructed for various business reasons on the shakiest of all foundations should not be lost. The issues of coupling, data storage, control, maintenance and everything else could have been much alleviated had the company not simply had the team stitch their various prototypes together.
I find two things odd about his presentation in this matter, however. Not once does he talk about the business pressures that were put on the second development story, just that "enough time" was given to the team to get the project done. Which strikes me as odd considering how often he seems to attack the first project for the constant efforts involved in meeting its unrealistic business deadlines. The other thing that tickles my mind about this is how much his experiences might have changed had he been with the messy product from the beginning. As he notes he came it later in its life cycle, and had to deal with all the issues listed, when he talks then about the wonderful experiences of the other project. If he'd been in those first initial meetings when the first project wasn't designed I think his attitude would change significantly.
The other main difference he highlights is the difference between standardization of the two projects, with the first project not experiencing any conformity, not even to the language and environments being used, to the supposedly total harmony he helped design in the wonderful project. Standardization of tools, naming conventions, and the rest is an extremely important step, not to mention standardization around a goal, and the first project definitely suffered for it heavily.
In the end though, his point that the first project was constructed for various business reasons on the shakiest of all foundations should not be lost. The issues of coupling, data storage, control, maintenance and everything else could have been much alleviated had the company not simply had the team stitch their various prototypes together.
Wednesday, August 26, 2009
What is Architecture?
The main point of this chapter seems to simply drive home the point that when you’re designing a system it’s not all about what technology stack you’ll be using, or how you’re going to split up responsibilities into modules on the client side, but also to make absolutely sure you and your team have a firm grasp on why you’re building something the way you are. Without this information it’s too easy for the architect or the engineers to build something that violates the intended design and solution, and to make checking for this sort of thing simpler, documentation should be made available and be kept up to date.
@Randy: I can’t think of a single concrete example, but I took that section more to mean that the Architect should have a good understanding of which components can be decoupled the easiest. I mean, in a magical world of infinite budgets and staffing you would be able to assign a single person to each of these modules. Or maybe they’re just using a different staffing model where what could (and, you’re right, probably should) be two different jobs are unified under the heading of “Architect”.
@Randy: I can’t think of a single concrete example, but I took that section more to mean that the Architect should have a good understanding of which components can be decoupled the easiest. I mean, in a magical world of infinite budgets and staffing you would be able to assign a single person to each of these modules. Or maybe they’re just using a different staffing model where what could (and, you’re right, probably should) be two different jobs are unified under the heading of “Architect”.
Software Architecture in Practice Chapter 4
The three most important qualities are, without a doubt, Availability Modifiability, and Reliability. While all the qualities discussed are very important these three represent a solid foundation from which more expansive software can be grown. If a user installs a new piece of software they expect it to work they launch the program and quickly become irritated if that basic operation doesn’t succeed. If the program is plagued by constant errors, crashes, and other interruptions of service the complaints will begin to pour in, just as would be expected. Lastly modifiability is extremely important as this can be a way to measure the lifespan for a piece of software. Businesses or other software creating entities that do not make modifiability a concern early on will have more trouble as time goes on and new technologies or practices are introduced. By nailing these three qualities we ensure that the user’s expectations of a functioning program are met, and that as time goes on the software will change to keep pace with new technologies or simply with the necessary repairs to ensure solid use.
However, the quality I have found to be the most difficult in practice is Usability. Each quality listed in the chapter carries its own unique challenges, but many of them are relatively easy to overcome, in that hard documentation exists or many opportunities in school and in the workplace exist to practice overcoming these challenges. With Usability, however, so many small adjustments can have such a wide ranging effect on the user’s flow that capturing even a few major helpful practices is difficult. I know that in my own experience some of the longest discussions I have concerning features I am working on have to do with how things will be presented to the user and how that impact's their workflow. Another big issue that separates Usability from the others is that a single program may have to be used by people with a wide range of abilities, and making the program complex gives the power users the control they desire but may render the system unusable for those without the skills. I once heard about a system that used an auto-hiding taskbar to hide the menu options from the user. An elderly operator was so unfamiliar with this convention that in order to close the program he would actually hold down the computer’s power button and force a restart! And this doesn’t even begin to cover other usability concerns such as simple icon placement, color choices, and a host of other things that have added many minutes to many meetings.
Tuesday, August 25, 2009
Subscribe to:
Posts (Atom)