Ray Ozzie is Microsoft’s chief software architect, assuming the role from Bill Gates in June 2006. To coincide with the theme for this issue of the Architecture Journal, we caught up with Ray to ask him about his vision for Software + Services and some of his thoughts about becoming a software architect.

Microsoft Chief Software Architect Ray Ozzie outlines Microsoft’s transformation to a world of live services at the company’s annual gathering of financial analysts. Microsoft Chief Software Architect Ray Ozzie outlines Microsoft’s transformation to a world of live services at the company’s annual gathering of financial analysts.

AJ: Many readers may have heard your keynote at MIX this year about Software + Services. Could you elaborate a little on the vision?

RO: There are fundamental changes that continuously occur within our industry related to the price of different types of components and the cost of communication. About every five years or so, we’ve found the need to re-evaluate the right architectures for systems based on changes that are occurring. Today, the confluence of cheap computing, cheap storage, and cheap communications is again causing us to re-evaluate where we put computing in order to deliver solutions and solve problems.

The Web initially was built for a low bandwidth world, utilizing a thin client or smart terminal, and assumed fairly low bandwidth with most of the computing power being applied at the service level. In the client-server era, we had a high bandwidth network within the enterprise that balanced processing on the client and the server. Given the changes in computing, storage, and communications, we as an industry, and we as a company, are reflecting upon the value we deliver to our customers and looking at the best way to balance what’s on the client, what’s on the enterprise server, and what’s on the service in order to accomplish different scenarios.

We are undergoing a fairly dramatic shift in delivering solutions. I believe fundamentally the answer is never one extreme or the other unless you’ve got a really intense constraint like a thin pipe. There are some solutions that will be delivered as pure services. You’ll just go to a browser; you’ll complete your transaction, get your information, and do whatever you need to do. There are other situations where you’re highly mobile and the connectivity to the Internet is less reliable from one spot to another. In these environments, the opposite extreme is true; you want to carry around as much data on your vast hard disk as possible, and have ready access to it.

For example, in the early days, the PC was mostly about documents. Now, of course, it’s about media. People are taking digital photos, putting vast libraries of them on their hard disks, caching their music, etc. We also are seeing many camcorders going digital. Does this mean that you will have all your home movies on your PCs? Or replicated among your PCs? I believe there’s a huge opportunity for our industry, in terms of looking, solution by solution, and asking what’s the best way of balancing the use of client code and service.

AJ: It sounds like many of these solutions could fit within a spectrum of browser-based clients and rich interaction. Within that spectrum do you see different types of architectural patterns emerging?

RO: There are different patterns emerging, although we don’t know exactly what they’ll all be yet. The patterns for horizontal scale are the ones that I’m thinking are most challenging and most interesting at this point in time. What’s very clear is that for any high-scale service you must have an image in your mind of a virtual machine that you scale accordingly to meet your needs. Refactoring your application so that it scales out as opposed to up, and also making it elastic in terms of very broad or very narrow scope is probably the most interesting right now.

There are certain design patterns like MapReduce that are clearly horizontally scalable design patterns, but these solve a relatively small set of problems compared to the large number of business applications that we have today. Over time, we’ll ultimately find a middle ground and will end up with frameworks that think of your application in tiers. These tiers, as long as they fit within this pattern, should be horizontally scalable.

AJ: To the degree that these patterns emerge, or frameworks are provided, how do you think the Software + Services vision differs from consumers to enterprises?

RO: That’s a really good question. I’m not so sure that the patterns are all that radically different, aside from the one thing in the enterprise that doesn’t exist in the consumer space -- the enterprise server. If you’re in the enterprise and you’re building systems for your customers, it’s going to be the same as if you were building systems for consumers. If you’re building for employees there are more systems integration issues. You’re probably going to want to build solutions that have some kind of affinity to another local server in the geography, and locating those based on data access patterns might be fairly significant. But over time, I do see enterprises embracing services more and more; initially for infrastructure services such as e-mail, communication, and other commodity-level services, before moving on to enterprise applications.

“REFACTORING YOUR APPLICATION SO THAT IT SCALES OUT AS OPPOSED TO UP, AND ALSO MAKING IT ELASTIC IN TERMS OF VERY BROAD OR VERY NARROW SCOPE IS PROBABLY THE MOST INTERESTING RIGHT NOW”

AJ: As readers think more about embracing a Software + Services model, where should they start today? And how do they know when they are successful?

RO: I’ll start with the last one. If they are achieving business goals and objectives, then they are successful. As for where they should start, from my vantage point, I would recommend becoming extremely fluent in the technologies, both from a developer and a designer perspective. For the Microsoft platform, this means understanding Expression Studio and Visual Studio. Then continue, explore, and prototype things in WPF (Windows Presentation Foundation) on Vista; it’s an amazingly powerful tool. As you know, I started programming back in the ’60s – and in the early days there was a model of a program that you had in your mind. It began with main and you started writing. At a certain point, it transformed to WinMain and became more of an event-based model. The new model of programming is where you’re thinking in a declarative model, starting with XAML and a canvas, and building your application from there.

This new model is different — until you start prototyping with it, you don’t understand the power that you get, and how productive you can be once you’ve transitioned to this new mindset. Prototyping brings you to a point where you start thinking, “Oh wow! Now I understand how I could build something in Silverlight and deploy it out there very quickly to anybody via a browser.” Following this approach is going to be much easier than figuring out how to write JavaScript for different types of browsers.

AJ: You mentioned a relationship between designers and developers. Historically, I would argue that these people have not communicated as well as they should. Do you see that changing with this new wave of technology?

RO: In any effective solution that has a design element to it, both had to find a way to get along. There’s nothing Microsoft can do to change the DNA—meaning the type of person who is a designer or the type of a person who is a developer.

What we’ve observed is developers and designers stretching themselves in different ways. Some designers can go further in understanding the challenges developers face. And some developers can relate more effectively to the challenges designers face. Having tools where there’s an overlap, where there isn’t an absolute boundary between a design tool and a developer tool, is extremely important and helpful. The core of Microsoft Expression is really oriented toward a designer. The work that they do translates into XAML, which can be imported and used in Visual Studio by a developer. I’m excited and optimistic about how tools like this will bring developers and designers closer together, for the ultimate benefit of the user.

AJ: We have a number of Architecture Journal readers in developer roles today who aspire to be software architects. Given your responsibilities, what does a day in the life of Microsoft’s chief software architect look like?

RO: From my vantage point, being an architect is really about pattern matching. It’s about being exposed to enough tools and techniques of the trade that over time you start to develop a toolkit of different patterns that work in different situations. This is true of software architecture and probably other types of architecture as well. Whether you build bridges or design buildings, you’re trying to apply design patterns to a given situation.

My role within Microsoft is an interesting one because there are very strong architects within the different product groups, within the different divisions of the company, and they’re doing a terrific job on their products. My role is essentially a cross-cutting one. By that I mean understanding how customers are using multiple products together, and then asking myself what patterns I see. What’s the smallest possible thing I could suggest to a product team that they could do to re-architect their product in order to minimize seams with other products? Or from a business perspective, what’s the smallest possible thing I could overlay on these products to add value for our customers, and advantage our solutions in the market. At the very highest level, my advice to aspiring architects is, don’t jump in too quickly. You need to do your time as a programmer to understand the different patterns that are out there, and recognize the attributes of well-architected systems, in order to raise yourself to the next level of abstraction in the solutions you’re building.

AJ: It sounds like the ability to do pattern matching really comes down to experience?

RO: Absolutely. It especially pertains to the things that nobody at the architecture level likes to think about. For example, performance characteristics, IO characteristics, reliability characteristics… You might have had experience with a system that works well given a certain level of complexity, but if used in a more dynamic environment it could be too fragile. You only learn that through experience.

“AT THE HIGHEST LEVEL, MY ADVICE TO AN ASPIRING ARCHITECT IS TO FIND THE RIGHT BALANCE OF FOCUS ON INTERNAL AND EXTERNAL TRENDS THAT WILL GIVE YOU THE PERSPECTIVE YOU NEED.”

AJ: You’ve been in the software industry for over 25 years, and clearly feel very passionate about technology and software. What keeps the motivation going? What gets you up in the morning?

RO: I like to solve problems. I enjoy complexity. I enjoy technology. I’ve been fortunate because very early in my career I had the opportunity to work on systems that were deployed at large scale. So I’m somewhat addicted to the notion of having a large impact in the things that you do. Each individual wakes in the morning with different motivations. For me, it’s about being a builder. I like to solve problems that can positively impact people’s lives.

AJ: I imagine that to do that you must have a wide array of knowledge across multiple technologies. Given that, and the product teams you interact with each day, how do you keep up to date?

RO: It’s really an interesting combination. The easiest and most natural thing is to just talk to people in your sphere of influence, and gain exposure to different technologies as a part of your job. But in order to be successful long term, you need to stay in touch with the trends and what’s going on externally, especially staying in touch with what customers or individual users are saying and doing.

I spend a fair amount of time reading blogs, tracking specific influencers that have very interesting voices both related to our products and completely unrelated to our products.

I go to a combination what I call ‘head’ and ‘tail’ conferences. I’ll attend a few where the known industry influencers congregate. These allow me to track major competitive issues, or at least the outward presentation of what competitors might be saying and doing. But I also enjoy the tail conferences, where you can get a closer-to-the ­ground perspective on what’s really happening. I like to meet people who are just out of school, who have startups and understand the kinds of technology choices they’re making and why. At the highest level, my advice to an aspiring architect is find the right balance of focus on internal and external trends that will give you the perspective you need.

AJ: That’s definitely great advice. Related to this, what would you say are defining characteristics of an effective software architect?

RO: The most effective architects I’ve dealt with are the ones who’ve paid their dues. These are the architects who’ve spent time in the trenches building and debugging fairly complex systems. You can learn a lot about how things work by fixing other people’s bugs. When something fails and the person has left the company, you can learn a lot by either reverse engineering or looking at the documentation. The more systems that you can learn from the inside out, the more you can develop an understanding for bad practice and good practice design patterns. As I mentioned earlier, it’s this library of patterns in your mind that will define you as an architect.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal Web site.