Architecture Journal Profile: Pat Helland

Recently, the Architecture Journal stopped by the office of Microsoft Architect Pat Helland to catch up with him and ask him about his thoughts on architecture, and how to become an architect.

AJ: Who are you, and where do you work?

PH: My name is Pat Helland and I work in the Visual Studio team in the Developer Division. I came to Microsoft in 1994 and helped found the team that built Microsoft Transaction Server and the Distributed Transaction Coordinator. By about 1998, I started to understand that N-tier computing was not addressing all the issues our customers were having and I became involved in what today is called service-oriented architecture, which back in the day I was calling "autonomous computing." This led to working on connecting the services with reliable messaging, and I helped start a project that shipped in SQL Server 2005 called SQL Service Broker. Starting in 2003, I spent some time working in DPE doing evangelism to our enterprise customers. [See About the author for more on Pat's long career and varied projects.]

AJ: As an architect for many years, what kind of advice would you give to someone who wants to become an architect?

PH: Architecture is a very interesting area. I liken it to building architecture. If you stand back and think about what a building architect has to do, they first of all have to think about a business need and understand how to create a building that fulfills that business need.

Even more, the building needs have a feel to it. When someone walks up and looks at the building, some emotion is conveyed.

At the same time, we have to deal with a myriad of pragmatics. How is the air going to flow through the building? How will the people move through the elevators? How do you make it comfortable and meet all other environmental considerations? You have the functioning of the building—the utilitarian object—combined with the fulfillment of the business needs, combined with the effect that particular structure will have on human beings.

Looking at that from the standpoint of software, you see exact parallels. The primary goal of a software architect is to understand and work out how to fulfill the business need. At the same time, you want the software to relate to people and their feelings about using it. While you are doing that, you have to deal with all of the transcendent aspects of the darn thing functioning correctly and pragmatically.

A building architect dealing with a large building may not be an absolute expert on elevators or airflow. But he has to know enough about those areas to interact with the experts and bring it together into a cohesive whole. Similarly, a software architect needs to know enough about the different aspects of the larger system that they are putting together to interact with the respective specialists.

AJ: A lot of this may sound familiar to people who have heard about Metropolis, correct? [See Resources.]

PH: Yes, and I'm still very keen on the Metropolis theme. Take a look at the history of urban development and how cities changed when the railroads arrived in the middle of the nineteenth century. The rapid movement of goods and people allowed—and caused— the same changes to occur in cities that we are now seeing in IT shops as different computers and facilities are being interconnected to the Internet.

The ability to communicate and to carry data or carry requests for business functionality remotely is causing pressure for standardization. It's causing the work to be broken into pieces and then connected with standards. Those standards are not just about how to squirt the data back and forth, but also to answer questions: What is a service? How do I think about the operation that I want to provide?

Again, this is very much what we saw in cities when the manufacturer was separated from the retailer who was delivering the goods. You can't do that unless you standardize on SKUs [Stock Keeping Units]. When you talk about breaking manufacturing down, and having manufacturers building parts for larger things, you are talking about standardization. You see a lot of commonality when you look at cities and when you look at the development of widely distributed IT shops.

AJ: I totally agree. Working in the developer division, I'm sure you need to stay up-to-date with the latest technologies. How do you do that?

PH: For me, I'm a relatively social person and I find time to talk both to people who are experts in the area—ask them their perspective—and compare their views to other experts that I talk to. In the end you just have to read. You have to think. It's actually a huge challenge trying to balance the time when you are talking and interacting with people where you are gaining and helping in so many different ways, and the time to go away to contemplate. Again to read, to absorb, to let things cook in the background and try to figure out what kind of big, sweeping changes you can make. And then you have to go and try to popularize those. It's astonishing how much of the job of an architect is to evangelize, to socialize—to get people to buy into a dream. Sometimes people ask what my job is, and I tell them, "To make stuff up and sucker people into building it." That's the job of an architect!

AJ: I like the definition. You mention socializing and keeping up-to-date with people. Who is the most important person you have ever met, and why?

PH: Important within the context of the computer field? I would say my dear friend Jim Gray whom I've known since 1982 and has recently gone missing, which is quite a hardship on many people. The reason I love him and hold him up as a mentor is that he cares compassionately about individuals. He doesn't care if the individual was some important muckety-muck or an aspiring college kid; he just cares about them as individuals. Related to that, Jim has an extraordinary ability to look at someone, listen to them for a minute and rapidly gravitate to what level they can understand the discussion. He neither talks down to them, nor overwhelms them with technology and concepts that are out of their grasp. And I've watched him do it repeatedly. I've watched him do it for 25 years, and I've always been just very, very respectful of that.

AJ: Yes that is an amazing thing, a very great man.

PH: This has allowed him to build an enormous network. I've watched Jim see someone in need of something, and then do a little bit of matchmaking with someone else. The combination that is then created can be very powerful and results in wonderful technology and wonderful growth in the technology community. Jim is constantly working to help uplift other people, each time concurrently looking at how he can uplift the technology and the business. It's that combination of growing individuals while accomplishing the business goals of creating great software that is such a joy and that has earned Jim so much respect in the industry.

AJ: Looking back at your career, what do you most regret?

PH: Not following Jim's advice and writing more. I am not always as disciplined as I wish I were in terms of forcing myself to write down all the things that are on my mind. Taking the ideas that are rattling around in the cavernous emptiness above my shoulders and getting them written down is something that I'm again anxious to push forward. Jim has always told me: You need to write more; you need to communicate more.

I don't know what it's like for everyone else, but I know it's hard for me to take the time and create a cohesive, communicative document unless I create a deadline and unless I get myself under the pressure. Then, I have to go away for a few days isolate myself with "Oh, my gosh! I'm going to get this done or bad stuff is going to happen!" I have to force myself to finish it, tie a ribbon around it, and push it out even though the perfectionist in me wants to rewrite it. That is something I wish I could've done better and I continue to try to make happen more.

AJ: The forcing function, I think a lot of people struggle with that.

PH: Yes. Architects are human. You just have to figure out how to make it happen.

AJ: So, what do the next few years look like? What do you hope to accomplish as part of your job?

PH: My goals are to figure out how to pick up a certain area of product features and drive them to a new level. Now, exactly what it's going to be, I've only been back, like, five weeks, and so I haven't completely put shape and form to that, but I want to push some new cool stuff into our product sets.

At the same time, I would like to gradually increase my time out presenting, my blogging, writing the artifacts that help people understand the various things I've been thinking about.

Also, just working with people inside and outside of Microsoft to help them solve their problems is what I find joyous— to really make a difference. I feel Microsoft is special in that you can have a broad influence.

Now mind you, it's an interesting place with a lot of stuff going on and lots of chaos here and there. Sometimes the things you are working on don't make it and not everyone realizes the incredible emotions that are tied up in engineering. People invest themselves in stuff that may or may not stick. I'm interested in how to facilitate avoiding the pain in that and how to bring out the joy. I'm also interested in helping people out into the public with their ideas. This is what I strive for.

Resources

Metropolis

About the author

Pat Helland has almost 30 years' experience in scalable transaction and database systems.

In 1978, Pat worked at BTI Computer Systems where he built an implementation language, parser generator, Btree subsystem, transaction recovery, and ISAM (Indexed Sequential Access Method).

Starting in 1982, Pat was chief architect and senior implementor for TMF (Transaction Monitoring Facility), which implemented the database logging/recovery and distributed transactions for Tandem's NonStop Guardian system. This provided scalable and highly-available access to data with a fault-tolerant message based system including distributed transactions and replication for datacenter failures.

In 1991, Pat moved to HaL Computer Systems, where he discovered he could work on hardware architecture. He drove the design and implementation of a 64-MMU (Memory Management Unit) and a CC-NUMA (Cache Coherent Non-Uniform Memory Architecture) multiprocessor.

By 1994, Microsoft called and asked Pat to work on building middleware for the enterprise. He came and drove the architecture for MS-DTC (Distributed Transaction Coordinator) and MTS (Microsoft Transaction Server). Later, Pat became interested in what today is called SOA (Service-Oriented Architecture) and started a project to provide high-performance exactly-once-in-order messaging deeply integrated with the SQL database. This shipped in SQL Server 2005 as SQL Service Broker. Later, Pat worked on WinFS, and did a stint in DPE evangelizing to our largest enterprise customers.

For the past two years, Pat had been working at Amazon on the catalog, buyability, search, and browse areas. He also started and ran a weekly internal seminar series. He is excited to return home to Microsoft and to work in the Visual Studio team!

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.