Columns

Software architects: Working on a building

• By Jack Vaughan
• May 1, 2004

Fans of "Seinfeld" may recall that among George Costanza's many pathetic affectations was the occasional ploy that he was an architect. Actual architects, those who design buildings, would laugh at George's claim -- but they may take offense when they learn that, over the last few years, the title "architect" has found firm footing in IT departments.

The title chief software architect has been taken as a cloak to symbolize the authority of no less than Bill Gates, who developed a version of BASIC for the MITS Altair computer in the 1970s, and who can probably still list all the bugs in that system.

The title seems apt to some. The architect is at least one step above the programmer, business analyst and project manager. In Gates' case, the steps on this scale are very big. It is the bugs that are the issue.

It is not unfair to question the notion of a "chief software architect" just as some engineers have questioned the idea of "software engineering" in general. After all, there is no single book that largely summarizes the undeniable tenets of the discipline as there is in civil engineering ["Know your live loads on bridge trusses!"], electrical engineering ["Don't overload digital outputs!"] and the like.

Some people are seeking to formalize the calling of the software architect. Among these is Thomas Mowbray, chief software architect at Keane Corp.'s Federal practice and longtime object expert. Together with Raphael Malveau, he recently released the second edition of Software Architect Bootcamp. The book is a bit of a manifesto that discusses the various elements that go into making a discipline of software architecture. [See Dan Romanchik's review of Software Architect Bootcamp: "Books: Building a better foundation" in the March 2004 issue of ADT.]

In conversation, Mowbray admits that the movement toward "well-built" software is slow, but his seriousness of purpose gives us confidence that there is progress again afoot.

"In the object-oriented software era, RAD [rapid application development] was of most importance for most IT shops. But when you 'do RAD,' you make a lot of decisions as rapidly as possible. You were not encouraged to think of architecture," Mowbray told me.

The proving grounds for would-be architects remain the developer cubes. "A lot of architects come from programming roles," said Mowbray. "The senior programmer often becomes the de facto architect." But as Mowbray and co-author Malveau state in Software Architect Bootcamp, managing complexity -- or, in fact, creating burdensome complexity -- can become endemic if programmers do not apply design principles -- architectural principles, if you will -- to projects.

So, who should you hire and allow to wear the mantle of "software architect"? Responds Mowbray: Software architects should know which are the major decisions in system development and integration, as well as the various approaches to making those decisions. They should be committed to live-time training.

Moreover, they should not get extra credit for being, say, a Java expert, .NET expert or just off one big project success. "Software architects should come to a company with dozens of project experiences using many technologies," said Mowbray. Having actionable plans for systems means doing good estimates, having some flair for analysis and understanding the business domain.

There are enough initiatives underway to hold promise of more formal software architect training and, eventually, certification. The Worldwide Institute of Software Architects (WISA) is addressing these issues.

The independent Federal Enterprise Architect Certification (FEAC) Institute now offers education and training leading to formal certification. The task is vitally important. Failed software systems building at the FBI has been judged to be an impediment to uncovering the activity leading up to the Sept. 11, 2001 terrorist attacks on the U.S.