Are software architects necessary?

Just eight months ago, I wrote at length about how Ray Ozzie, Bill Gates’ handpicked successor as Microsoft’s chief software architect, was transforming the way the company delivers software and services for the 21st century. Earlier this week came the news that Ozzie is stepping down from his position at Microsoft and that CEO Steve Ballmer will not seek a replacement. Should I be shocked?

The official word is that Ozzie is leaving the chief software architect post because he has accomplished everything he set out to achieve. In his five years at Microsoft, Ballmer says, Ozzie worked tirelessly to bring Microsoft into the modern Internet era, spearheading such projects as the Live Mesh cloud storage service and the Windows Azure cloud computing platform.

[ Keep up on key application development insights with the Fatal Exception blog and Developer World newsletter. | Follow the latest in Microsoft technology with our Technology: Microsoft newsletter. ]

But not everyone sees Ozzie’s tenure at Microsoft as a case study in success. According to the Wall Street Journal, some Microsoft insiders found his leadership lacking. Ozzie’s well-known aversion to public speaking meant he seldom led meetings or spoke at company events. He also clashed with other execs, the Journal reports — particularly Steven Sinofsky, who heads Microsoft’s Windows division. Reading these accounts, the picture that emerges is that of a visionary software developer, one with grand ambitions and meticulously detailed plans, but who lacks the charisma and management skills necessary to inspire the rest of the company to fall in line.

In other words, I can hear some developers saying, he sounds exactly like a software architect. Which leads to the inevitable question: Was the chief software architect position ever really necessary at Microsoft? Are software architects relevant at all?

Blueprints for software success

The concept of the software architect is one that has developed over the past decade or so. As multitier architectures have increasingly become the norm for software projects, development houses have seen a need for a “master planner” to own the overall structure of the system, in much the same way that a traditional architect creates and maintains blueprints for a building.

Ideally, software architects should be generalists who have some knowledge of the design and implementation of every subsystem in their projects. That means they should be programmers, but they probably aren’t involved in much day-to-day coding. Instead, they use tools such as Uniform Modeling Language (UML) to integrate the various subsystems in ways that are consistent and efficient, with uniform APIs and minimal duplication of effort.

For a company as big as Microsoft, the chief architect can also have a hand in integrating software development efforts across departments and product areas, to ensure that the company’s entire software portfolio forms a cohesive whole.

Microsoft’s software portfolio is so large and diverse, however, that it’s hard to imagine anyone who would be up to the task of architecting such a complex ecosystem. Certainly Ray Ozzie was as good a choice as any. The mastermind behind Lotus Notes, Ozzie has been a driving force in software since the early days of the PC. He was born the same year as Bill Gates and cut his teeth on computing at about the same time.

The worst habits of software architects

But Ozzie is no Gates. A Microsoft outsider, Ozzie lacks Gates’ intimate understanding of the company’s product line, its processes, and its organizational structure. He also lacks Gates’ aggressive personality and hands-on management style, which arguably played an essential role in growing Microsoft into the empire it is today.

When Gates stepped down as CEO of Microsoft, it was easy to see the chief software architect title as a way for him to keep a hand on the company’s reins while leaving the drudgery of dealing with Wall Street to Ballmer. With Ozzie in the role, however, it was a whole different kettle of fish. Lacking Gates’ long history at the company and his dominating presence, it was easy for Ozzie to fall into the typical bad habits of software architects.

At their worst, architects are seen as the ivory-tower academics of software development. They create plans that they expect others to follow, but they don’t actually lead — which inevitably causes friction with business line managers. What’s more, ambitious plans are often seen as unrealistic by hands-on coders, who resent the architect’s lack of experience with the realities of the development process. And when project goals aren’t met, the blame goes to the teams whose job it was to implement the plans, not the architect who dreamed them up to begin with.

As the disconnect between architecture and actual development widens, the overall impression of the software architect within the organization becomes that of someone who gets to act like a superstar developer but who doesn’t have to confront any of the responsibilities, risks, challenges, and compromises that “real” developers face. Little wonder that recent reorganizations at Microsoft have seen Ozzie’s pet projects, including Azure and Live Mesh, farmed off to veteran managers at other groups within the company.

Make room for architecture

But if Ozzie’s role at Microsoft didn’t sit well with other execs and managers, he doesn’t deserve all of the blame. In a sense, he was never given a proper chance to begin with. Microsoft is an aggressive, competitive business culture, one that wasn’t necessarily a good fit for Ozzie’s temperament, according to insiders. What’s more, by granting Ozzie the lofty chief software architect title before he had proven himself at the company, Gates all but ensured Ozzie would remain a perpetual outsider.

Maybe that’s the real lesson to be learned here: Architecture can be an important part of effective software development, but only if it is seen as part of a collaborative process. If your business culture values competition over collaboration, placing a software architect in an artificial position at the top of the pyramid will only engender resistance and resentment among senior managers. That’s a recipe for failure — but blaming the software architect when it happens is letting the tail wag the dog.

This article, “Are software architects necessary?,” originally appeared at InfoWorld.com. Read more of Neil McAllister’s Fatal Exception blog and follow the latest news in programming at InfoWorld.com.