This is Visual Studio Magazine's big foray into architecture (which I translate freely into "program management.") If you read one thing this year, pick up this issue.

I've developed a running commentary on a couple articles to give you a taste:

“Reining in Job Title Inflation (Editorial)” by Patrick Meader

This editorial delivers the information that HP’s Rich Fricchione is working with Microsoft to adopt HP’s architect certification process over there. This would result in stabilization of title inflation, where as Alan Cooper says, “web designers are called programmers, programmers are called architects, and architects never get called.” Ostensibly, this means that architecture is either not being done, or is done with underqualified folks. (In my opinion, the first is a great loss for productivity, the second is a misdemeanor at best.) Meader is supportive but pessimistic about the effects of Fricchione’s deal, saying it should involve more companies and be broader based. This begs the question, what effect would such standardization have on our industry if it were to occur? We all want to be more experienced and more productive at our work. None of us want to be bored, except maybe with regard to a monotonous paycheck coming in. If anything standardizes us, these dynamics do already and with possibly more impact than a shared program defining us by exams or experience. The impulse of such programs is to band together as developers to solve systemic problems that are practically inevitable in our industry. The effect, hopefully, would not be another way to itemize and divide us.

“Architect Your Enterprise” by Paul D. Sheriff

Term “that’s new to me”: n-tier techniques

Fun Quote: “Beginning any new application without a set of reusable objects in hand leads straight to the ‘File | New Project” syndrome. This is what happens when developers start a new project from scratch and have way too much to develop in too little time.” Let’s be clear that you can use this command lots of times during the course of a real project, and even if you do it doesn’t mean you’re not reusing code. This is a cute thing to say but a confusing image. Game developers specifically have problems with using too much of their previous project, which happens accidentally and out of some level of desperation to get something to work again.

Glorious Section on “Become an Architect” – I retype it here, but I replace the word architect for program manager, and IT for product development. Apologies to Sheriff, and hopes that he would take it as a compliment.

“As a program manager, you tackle many roles within the enterprise. You’re responsible for interfacing with both technical people and business people, so you need to wear many hats and perform different day-to-day operations.

“A successful program manager must be able to strategize with business people on future directions for the company, keep the goals of product development and business in sync, set goals for product development, and create its mission statement. Wearing your technical hat, you create standards and processes that support the architecture, create framework designs, enforce standards and processes, apply success metrics to product development – and communicate the results to management.

“The best program managers share a number of traits. They’re technical people who know how to lead an product development team, and they possess great written and oral communication skills, along with technical and general problem-solving creativity. They have an open mind and also a vision of product development success, they can create and enforce good product development processes. At the same time, they have business acumen; they’re plugged in with the business executives and are able to influence the appropriate people in the organization. And unlike many technical people, they can make effective drawings to communicate ideas.

“If you already possess many of these traits, you can probably acquire the rest. Strive to attain as many of these qualities as possible if you want to become a program manager.”

Now that’s news you can use!

I had a bunch of problems with the sidebar on “Map your road to success”. It seemed to copy the waterfall system so denounced in Murphy’s article this issue. It also raised tons of issues later answered in the article, but not in an integrated way. For example, the executive buyoff was not in this diagram, and even though mentioned in the article later it’s hard to figure out where Sheriff meant it to go.

“If you don’t know which way to go when you leave your driveway, chances are your trip will take a lot longer.” Shipping software is not like finding the nearest post office. It’s about delivering something compelling to the marketplace. Sheriff is right that leaving your driveway is a momentous occasion for the project, but he’s not right about why. It’s not the direction you turn, but what’s in the trunk that counts. Imagine you are driving a taco bus. Sheriff might wonder which way to turn out of his driveway in order to sell more tacos. But he’d be wrong: with the right tacos, any direction will do.

Excellent diagram called “Build Generic Components for All Your Applications” I would love to have a book on this topic.

Excellent comments on how to convince execs to spend more time on architecture, and how to overcome resistance among the ground troops.

comment []4:23:12 PM  trackback []