Ray Ozzie is Microsoft’s chief softwarearchitect, assuming the role from Bill Gates in June 2006. To coincide with thetheme for this issue of the Architecture Journal, we caught up with Ray to askhim about his vision for Software + Services and some of his thoughts aboutbecoming a software architect.
Microsoft Chief Software Architect Ray Ozzieoutlines Microsoft’s transformation to a world of live services at thecompany’s annual gathering of financial analysts. Microsoft Chief SoftwareArchitect Ray Ozzie outlines Microsoft’s transformation to a world of liveservices at the company’s annual gathering of financial analysts.
AJ: Many readers may have heard yourkeynote at MIX this year about Software + Services. Could you elaborate alittle on the vision?
RO: There are fundamental changes thatcontinuously occur within our industry related to the price of different typesof 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 basedon changes that are occurring. Today, the confluence of cheap computing, cheapstorage, and cheap communications is again causing us to re-evaluate where weput computing in order to deliver solutions and solve problems.
The Web initially was built for a low bandwidthworld, utilizing a thin client or smart terminal, and assumed fairly lowbandwidth 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 enterprisethat balanced processing on the client and the server. Given the changes incomputing, 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 thebest way to balance what’s on the client, what’s on the enterprise server, andwhat’s on the service in order to accomplish different scenarios.
We are undergoing a fairly dramatic shift indelivering solutions. I believe fundamentally the answer is never one extremeor 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 justgo to a browser; you’ll complete your transaction, get your information, and dowhatever you need to do. There are other situations where you’re highly mobileand 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 aroundas much data on your vast hard disk as possible, and have ready access to it.
For example, in the early days, the PC wasmostly about documents. Now, of course, it’s about media. People are takingdigital photos, putting vast libraries of them on their hard disks, cachingtheir music, etc. We also are seeing many camcorders going digital. Does thismean that you will have all your home movies on your PCs? Or replicated amongyour PCs? I believe there’s a huge opportunity for our industry, in terms oflooking, solution by solution, and asking what’s the best way of balancing theuse of client code and service.
AJ: It sounds like many of these solutionscould fit within a spectrum of browser-based clients and rich interaction.Within that spectrum do you see different types of architectural patternsemerging?
RO: There are different patterns emerging,although we don’t know exactly what they’ll all be yet. The patterns forhorizontal scale are the ones that I’m thinking are most challenging and mostinteresting at this point in time. What’s very clear is that for any high-scaleservice you must have an image in your mind of a virtual machine that you scaleaccordingly to meet your needs. Refactoring your application so that it scalesout as opposed to up, and also making it elastic in terms of very broad or verynarrow scope is probably the most interesting right now.
There are certain design patterns like MapReducethat are clearly horizontally scalable design patterns, but these solve a relativelysmall set of problems compared to the large number of business applicationsthat we have today. Over time, we’ll ultimately find a middle ground and willend up with frameworks that think of your application in tiers. These tiers, aslong as they fit within this pattern, should be horizontally scalable.
AJ: To the degree that these patternsemerge, or frameworks are provided, how do you think the Software + Servicesvision differs from consumers to enterprises?
RO: That’s a really good question. I’m not sosure that the patterns are all that radically different, aside from the onething in the enterprise that doesn’t exist in the consumer space -- theenterprise server. If you’re in the enterprise and you’re building systems foryour customers, it’s going to be the same as if you were building systems forconsumers. If you’re building for employees there are more systems integrationissues. You’re probably going to want to build solutions that have some kind ofaffinity to another local server in the geography, and locating those based ondata access patterns might be fairly significant. But over time, I do seeenterprises embracing services more and more; initially for infrastructureservices such as e-mail, communication, and other commodity-level services,before moving on to enterprise applications.
“REFACTORING YOUR APPLICATION SO THAT ITSCALES OUT AS OPPOSED TO UP, AND ALSO MAKING IT ELASTIC IN TERMS OF VERY BROADOR VERY NARROW SCOPE IS PROBABLY THE MOST INTERESTING RIGHT NOW”
AJ: As readers think more about embracinga Software + Services model, where should they start today? And how do theyknow when they are successful?
RO: I’ll start with the last one. If they areachieving business goals and objectives, then they are successful. As for wherethey should start, from my vantage point, I would recommend becoming extremelyfluent in the technologies, both from a developer and a designer perspective.For the Microsoft platform, this means understanding Expression Studio andVisual Studio. Then continue, explore, and prototype things in WPF (WindowsPresentation Foundation) on Vista; it’s an amazingly powerful tool. As youknow, I started programming back in the ’60s – and in the early days there wasa model of a program that you had in your mind. It began with main and youstarted writing. At a certain point, it transformed to WinMain and became moreof an event-based model. The new model of programming is where you’re thinkingin a declarative model, starting with XAML and a canvas, and building yourapplication from there.
This new model is different — until you startprototyping with it, you don’t understand the power that you get, and howproductive you can be once you’ve transitioned to this new mindset. Prototypingbrings you to a point where you start thinking, “Oh wow! Now I understand how Icould build something in Silverlight and deploy it out there very quickly toanybody via a browser.” Following this approach is going to be much easier thanfiguring out how to write JavaScript for different types of browsers.
AJ: You mentioned a relationship betweendesigners and developers. Historically, I would argue that these people havenot communicated as well as they should. Do you see that changing with this newwave of technology?
RO: In any effective solution that has a designelement to it, both had to find a way to get along. There’s nothing Microsoftcan do to change the DNA—meaning the type of person who is a designer or thetype of a person who is a developer.
What we’ve observed is developers and designersstretching themselves in different ways. Some designers can go further inunderstanding the challenges developers face. And some developers can relatemore effectively to the challenges designers face. Having tools where there’san overlap, where there isn’t an absolute boundary between a design tool and adeveloper tool, is extremely important and helpful. The core of MicrosoftExpression is really oriented toward a designer. The work that they dotranslates into XAML, which can be imported and used in Visual Studio by adeveloper. I’m excited and optimistic about how tools like this will bringdevelopers and designers closer together, for the ultimate benefit of the user.
AJ: We have a number of Architecture Journalreaders in developer roles today who aspire to be software architects. Givenyour responsibilities, what does a day in the life of Microsoft’s chiefsoftware architect look like?
RO: From my vantage point, being an architect isreally about pattern matching. It’s about being exposed to enough tools andtechniques of the trade that over time you start to develop a toolkit ofdifferent patterns that work in different situations. This is true of softwarearchitecture and probably other types of architecture as well. Whether youbuild bridges or design buildings, you’re trying to apply design patterns to agiven situation.
My role within Microsoft is an interesting onebecause there are very strong architects within the different product groups,within the different divisions of the company, and they’re doing a terrific jobon their products. My role is essentially a cross-cutting one. By that I meanunderstanding how customers are using multiple products together, and thenasking myself what patterns I see. What’s the smallest possible thing I couldsuggest to a product team that they could do to re-architect their product inorder to minimize seams with other products? Or from a business perspective,what’s the smallest possible thing I could overlay on these products to addvalue for our customers, and advantage our solutions in the market. At the veryhighest 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 patternsthat are out there, and recognize the attributes of well-architected systems,in order to raise yourself to the next level of abstraction in the solutionsyou’re building.
AJ: It sounds like the ability to dopattern matching really comes down to experience?
RO: Absolutely. It especially pertains to thethings 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 certainlevel of complexity, but if used in a more dynamic environment it could be toofragile. You only learn that through experience.
“AT THE HIGHEST LEVEL, MY ADVICE TO ANASPIRING ARCHITECT IS TO FIND THE RIGHT BALANCE OF FOCUS ON INTERNAL ANDEXTERNAL TRENDS THAT WILL GIVE YOU THE PERSPECTIVE YOU NEED.”
AJ: You’ve been in the software industryfor over 25 years, and clearly feel very passionate about technology andsoftware. What keeps the motivation going? What gets you up in the morning?
RO: I like to solve problems. I enjoycomplexity. I enjoy technology. I’ve been fortunate because very early in mycareer I had the opportunity to work on systems that were deployed at largescale. So I’m somewhat addicted to the notion of having a large impact in thethings that you do. Each individual wakes in the morning with differentmotivations. For me, it’s about being a builder. I like to solve problems thatcan positively impact people’s lives.
AJ: I imagine that to do that you must havea wide array of knowledge across multiple technologies. Given that, and theproduct teams you interact with each day, how do you keep up to date?
RO: It’s really an interesting combination. Theeasiest and most natural thing is to just talk to people in your sphere ofinfluence, 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 thetrends and what’s going on externally, especially staying in touch with whatcustomers 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 toour 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 influencerscongregate. These allow me to track major competitive issues, or at least theoutward presentation of what competitors might be saying and doing. But I alsoenjoy the tail conferences, where you can get a closer-to-the groundperspective on what’s really happening. I like to meet people who are just outof school, who have startups and understand the kinds of technology choicesthey’re making and why. At the highest level, my advice to an aspiringarchitect is find the right balance of focus on internal and external trendsthat will give you the perspective you need.
AJ: That’s definitely great advice.Related to this, what would you say are defining characteristics of aneffective software architect?
RO: The most effective architects I’ve dealtwith are the ones who’ve paid their dues. These are the architects who’ve spenttime in the trenches building and debugging fairly complex systems. You canlearn a lot about how things work by fixing other people’s bugs. When somethingfails and the person has left the company, you can learn a lot by eitherreverse engineering or looking at the documentation. The more systems that youcan learn from the inside out, the more you can develop an understanding forbad practice and good practice design patterns. As I mentioned earlier, it’sthis library of patterns in your mind that will define you as an architect.
This article was published in the Architecture Journal, a printand online publication produced by Microsoft. For more articles from thispublication, please visit the Architecture Journal Web site.