For this issue, as part of the Architecture Journal Profile series, we had the chance to catch up with Don Ferguson, a Technical Fellow at Microsoft. We asked Don some questions about his career, and we asked what advice he had for people who wanted to become architects or who are interested in architecture today.

AJ: Who are you, and where are you from?

DF: I'm Don Ferguson. Before I joined Microsoft earlier this year, I was an IBM Fellow. There are about 200,000 engineers at IBM and about 50 Fellows, so it was quite an honor to be one of them. When I first joined IBM Research, I never thought that someday I would be a Fellow. Maybe one day, I would become a project leader; that would be quite an accomplishment. There are a lot of smart, talented people, and I just hoped that I could be one of them.

AJ: How did it feel to become an IBM Fellow?

DF: The day I became a Fellow was one of the best days of my life. In truth, I did feel a little bit awkward about the award, however. I felt that there were some people who deserved it more than I did. So, shortly after the announcement, I became an advocate for these people, and over the next few years was able to help get three or four of them to Fellow. In some ways, I was happier on their award days than on mine. When it happens to you, it's a blur; but when it happens to others, you have a lot of satisfaction.

AJ: What did a typical day look like?

DF: I was the Chief Architect in the Software Group in IBM. There were hundreds of products and projects. Being the Chief Architect means that you can't design every component. There are just too many projects and products for this to be a realistic goal. A large portion of my day would be spent doing a lot of review work. I would review several projects' or products' designs, focusing on some top-level things. I placed special emphasis on new products. Typically, I would focus on cross-product integration, common themes, and so on. For example, does the portal product have the right interface to connect to this security product? Is the product supporting the right standards? I used to jokingly refer to this as "herding the cats." On the title slide of presentations that I gave, I often used the title of "Chief Cat Herder."

In the early days, this work was very unsatisfying—too abstract, too shallow, too broad. But then I had an epiphany: Working on pulling the different parts together a little bit more had a significant effect, especially across products. A little bit of improvement in a lot of places makes a difference. An example is also true of the work that I was able to do on the Web services standards. I think I helped make them a little more coherent, composable, easier to understand, and so on.

AJ: With such responsibilities, how do you stay technically savvy?

DF: Good question! The first thing I do is work really hard. When I'm not with the kids, it's often eat, sleep, work, karate; and sometimes sleep is optional. I definitely put in a lot of hours. Secondly, I do a lot of work on airplanes, where there are no conference calls or disruptions. Whenever possible, I consciously stay away from e-mail. I also try not to learn new technical information by reading a paper or presentation. The best way is to download, install, use, and code.

Over the years, one of the things I've learned to do well is to synthesize how things should work with only a little bit of information. By and large, people are smart. With a little bit of information, I can often figure out what smart people must have done. How would smart people have designed this? With this process, although I may not know the topic in-depth, I can often work out how things must work and contribute to the discussion.

In IBM, I tended to have around 10 to 12 initiatives that I was working on at any time. I would spend a few months on each project, multiplexing between the initiatives. Eventually, each initiative would either take on a life of its own or not pan out. You'll see a lot of this in the standards work I participated in. I was listed as contributor for many of the early papers, but over time I disappeared. A lot of good people started driving and doing deep technical work, and I moved on to something else.

AJ: What advice would you give someone who wants to become an architect today?

DF: I think there are four pieces to this answer:

Firstly, at IBM we had an architect board in the Software Group, which helped me form a network. It took me a while to understand the importance of a network. Being a New Englander, I tend to be a little taciturn and by myself. You should never underestimate the importance of a social network. You don't know what you don't know. You don't know what someone may say to you that can push the reset button in your brain and make you think differently.

Secondly, as a software architect, never stop coding. I write code. It's not good or particularly deep code, but I do code. A lot of it is educational and related to my spare-time activities. For example, recently, I've been working on a portal that connects my family using TikiWiki and PHP. I installed the products, but they didn't work for me right out of the box. So, I had to go in and hack them. It was cool. Another example is the nursery school that my daughter attends. They asked me to set up a Web site using [Microsoft] FrontPage, which was another learning experience.

Thirdly, communication skills matter. They really do. It's really important to understand how to write well and how to present well.

Finally, the most important thing is to connect with customers. Spend as much time as possible with them. Learn what they are trying to do, and look at what works and what doesn't. Help them use your products. There's no substitute for spending time with customers and helping them solve problems. Doing this, we often learned that customers used things in ways that we never dreamed they would. We also came up with amazing new ideas.

AJ: Who is the most important person you've ever met, and what made that person so significant?

DF: When I started out in academia and the Research Division, my thesis adviser (Yechiam Yemini) was really important. He taught me two things:

People who are driven tend to underestimate the quality of what we do. We are too hard on ourselves. We think our papers aren't very good or our research isn't novel. My adviser helped with perspective.

Secondly, he taught me that this stuff can be fun. Just have a good time, and enjoy what you are doing. He had a very contagious, childlike enthusiasm.

In addition to my adviser, there are many more people at IBM who became great friends and role models. Tony Storey was the most important one. I would look at the ones that I respected, and often try to "reverse-engineer" how they do their job. I would consciously try to be like them.

AJ: What is the one thing in your career that you regret? What did you learn from it?

DF: Wow! I don't even know where to begin! I'll give you two: My old group gave me a "Darth Vader" helmet, because of the way I was operating in the early days. "Do it my way or I will blow your planet up." The "Darth Vader" approach doesn't work. You can't make smart people do things that they don't want to do. People do well what they want to do. For me, that was an epiphany. Why was I so curt and domineering? I was busy, and all I could think about was, "I have these 20 things to do. Why won't this person just do what I want?" I came to realize that this approach never works, no matter how hard you try. People deserved my time, and I owed them the time.

Secondly, many people who work in technology suffer from the "endgame fallacy." We are all pretty bright. We see a lot of customers. We see what they are doing and then plot a trajectory for where they will be in a few years. Once you do this, however, it's too tempting to build what they will need in five years, and not what they need next or are ready for. Sometimes, I say there is no point in building the Emerald City without building the Yellow Brick Road; and you have to build the road first. Often, I would make things too complicated, anticipating their future needs. One of the senior executives used to say that "vision without execution is hallucination," and it's true.

AJ: What does Don's future look like?

DF: To answer this, I have another piece of advice. When I ask myself that question, I always put personal fulfillment first and then job fulfillment second. If you are not fulfilled personally, you will never be fulfilled in your job. I have a black belt in karate (Kenpo) and want to get better at that. I want to take another discipline: Jiu-Jitsu. I would like to teach Kenpo. Personal fulfillment has to come first.

For job fulfillment and what excites me, I imagine a point in the future where everyone can program. This isn't so much about using Fortran and C#, but instead another definition of "program." It sounds strange, but let me explain:

Everyone who graduates from high school has done some programming—even if it's something simple like a PHP Web site. These are basic skills now—just like I learned how to do long division by hand (although I would argue that students of today can't do long division anymore). These casual programmers will enter the workforce.

Maybe we need to broaden our definition of "program." What's the number one "programming tool" for business professionals? [Microsoft Office] PowerPoint. If business professionals can use [Office] PowerPoint, I wonder whether we can nudge them into another tool to do business modeling. They already do business modeling, but they do it by using documents that get handed to programmers. Programmers guess what the documents mean, and bad things happen when programmers guess. I wonder whether we can do something cleverer. In business schools, they teach a discipline called structured English and various diagramming techniques. Maybe these could form the basis for programming business services.

Job fulfillment for me would be thinking about how we change the fundamental nature of the Web. Web 2.0, mash-ups, and feeds are interesting, but they are step one of a two-step process. The Web today is a push model.

People write content that is pushed out to people who read it. Programmers write Web applications that end users "use." People write mash-ups or scripts to access the "pushed" content. These applications run on the PC today, but I believe that they could migrate into the Internet "cloud." The Internet now becomes the programmable Internet and can run my applications for me. The tag line is, "The Internet is the computer." We see this in nascent places already—with Google, Amazon.com, MSN, and so on all now having callable services. Together with a broad range of programming skills for everyone, I see a blurring between the personal and business environment. That's what I really care about.

 

More on Donald Ferguson's Career

Dr. Donald Ferguson is a Microsoft Technical Fellow in Platforms and Strategy in the Office of the CTO. Don focuses on both the evolutionary and revolutionary roles of information technology in business. Microsoft expects that he will be involved in a variety of forward-looking projects. Prior to Joining Microsoft, Don was an IBM Fellow and Chief Architect for IBM's Software Group (SWG). Don provided overall technical leadership for WebSphere, Tivoli, DB2, Rational, and Lotus products. He also chaired the SWG Architecture Board (SWG AB). The SWG AB focused on product integration, cross-product initiatives, and emerging technology. Some of the public focus areas were Web services, patterns, Web 2.0, and business-driven development. Don guided IBM's strategy and architecture for SOA and Web services, and coauthored many of the initial Web service specifications.

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.