Career Profiles in Architecture

Jack Greenfield is a well-known speaker and writer. He is a coauthor of the bestselling and award-winning book Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools, with Keith Short, Steve Cook, and Stuart Kent. Jack has also contributed to UML, J2EE, and related OMG and JSP specifications. He holds a B.S. in Physics from George Mason University.

This interview with Jack Greenfield is part of an article he authored for Issue 9 of The Architecture Journal which was published in October 2006. You can read the entire article and view Jack's resume at The Architecture Journal.

Who are you, and where do you work?

I am Jack Greenfield. I work as an architect in the Enterprise Frameworks and Tools (EFT) group in the Visual Studio Team System organization, which is part of the server and tools business at Microsoft.

Can you tell us a little about your career at Microsoft?

When I joined EFT, the group was already building the set of tools that we now call the Distributed System Designers in Visual Studio 2005 under the leadership of Anthony Bloesch and Kate Hughes. Keith Short saw the tools as a "down payment" on a vision of model-driven development (MDD), where organizations would use models as source artifacts for automating application development, not just as documentation.

EFT was a natural fit for the vision of MDD presented in my book, which was partially completed when I joined Microsoft. My vision was similar to Keith's, in seeking to leverage MDD, but it brought a new twist into the picture by placing MDD in the context of software product line engineering, which emphasizes the development of reusable assets supporting a custom process for building a specific type of deliverable. Keith and I worked together to create a unified vision and to describe it in the book. The result was the methodology we now call software factories.

While we were writing the book we saw an opportunity to use the modeling framework used by the Distributed System Designers as a basis for domain-specific languages (DSLs), which constitute an important component of the methodology. We put together a business case for productizing the framework and for building tools to support it as the first step toward implementing software factories.

We took the proposal to Eric Rudder, supported by a demo, and asked for resources to build a team. We were able to show that we had a good foundation to build on. Eric agreed and provided the funding. We were fortunate to be able to hire an all-star team led by Steve Cook and Stuart Kent to do the work. The result is what we now call the DSL Tools, which were just released in the Visual Studio SDK. Steve and Stuart also joined us in writing the book, contributing chapters on language design and implementation.

During that time, I also led an effort to apply DSL technology to the tools being developed for the Microsoft Business Framework, working with a team led by Steve Anonsen, Lars Hammer, and Christian Heide-Damm. We used some of the ideas from the book about model references and model management on that project. I also did a lot of speaking, writing, and customer interviews to evangelize software factories. Several people helped us promote, refine, and implement the methodology. Michael Lehman, Mauro Regio, and Erik Gunvaldson, in particular, were instrumental. Mauro and I are writing a new book called Software Factories Applied that shows how to build factories using the prototypes he developed for HL7 and UMM as examples.

We are now building additional products to support the software factories vision. One of the most important steps enabling our current work was Mike Kropp becoming the product unit manager for EFT and integrating it with the patterns & practices group, another all-star cast led by Wojtek Kozaczynski and Tom Hollander. The merger of the two groups has put the wood behind the arrow to build the vision.

What kind of advice would you give to someone who wants to become an architect?

Good question. In general, you do not apply for a job as an architect; it just kind of happens to you, and I think it happens because of the way you think, the way you talk, and the kind of work you do. For me, an architect is someone who goes beyond the fine details of programming and thinks about the big picture.

I like a description that was offered by someone I met recently from the Netherlands: an architect mediates communication among people who think about end-user concerns, people who think about technology, and people who think about the business case. They see how the thing can come together in much the same way that an architect in the construction trade sees how a building comes together to serve the needs of its users in an aesthetically pleasing way within the owner's budget and schedule using available building technologies.

At some point someone will say about you, "he or she is our architect," and that is how you will know you are functioning in that role. Over the last few years a lot of good material has been written about architecture and the role of the architect, and an industry consensus regarding best practices is emerging. In addition to development and organizational skills, an architect needs to know how to find and apply relevant research in product designs.

How do you keep up to date?

First, I spend a lot of time with folks inside Microsoft. I have a lot of interactions with other teams that help me see the bigger picture and where my work fits within it. I think being familiar with your company's products is one of the most important obligations of an architect. Of course, Microsoft is huge, and it is hard to get your head around even a small chunk of it, but the more you can learn the better.

From there, I tend to follow movements in industry and academia, such as the design patterns and agile development movements. I read a lot of books and articles by other folks who push the envelope, such as Martin Fowler and Rohan McAdam. On the academic side, I follow the Software Engineering Institute (SEI), especially the work being done by Linda Northrup, Len Bass, Paul Clements, and others on the practice of architecture, which contributed to the design of software factories. I also stay in touch with colleagues like Krzysztof Czarnecki at Waterloo and Don Batory at Austin. I also serve on conference program committees and peer review boards for journals, which give me opportunities to see a lot of good papers. I also do my share of speaking and writing to stay engaged in the community.

Name the most important person you have ever met and why?

Apart from sitting on Lyndon Johnson's knee as a five year old, the most important person I have ever met has to be Bill Gates. I have presented to Bill on a couple of occasions, sitting right across the table from him. On every occasion he has played the same kind of role, which was to ask a lot of questions and then to point us at related work taking place in other parts of Microsoft. I think this really demonstrates the point about knowing your company. Bill is always concerned about leveraging as much as possible of what we are doing around the company.

Another person I would put on my list is Steve Jobs. He is a charismatic and visionary leader. He creates a tremendous amount of excitement in people. It gave me the feeling of doing something world changing.

What is the one thing that you regret most in your career?

I have done more than my share of things that I would do differently in hindsight, but the one thing I regret most is not a single thing, but rather a trend or pattern that if I could I would correct from the start. In the past, I have often thought, "I can do it!" and have just plowed ahead. Instead, I should have stepped back and spent more time working with others as part of a team.

It is hard to overemphasize the value of being part of a team. No one has all the cards as an individual. There have been many times in my career when I have held nine of the ten cards I needed to win, but could not get the tenth card without a team. Unless you work in a way that brings out and synthesizes the contributions of other people, you will not have all the cards when you need them. Thinking you can do it alone is an affliction that plagues many technically gifted people. Look around some time and notice how many B students who work well with teams end up being more successful than A students who know most of the answers. It should be clear from the number of people I have named in this interview that the success of my work depends on the work of many other people and vice versa, and there are many people who have made key contributions to the software factories vision. Some of them are named in the acknowledgements in the first book, and a whole new set will be named in the second book.

What does Jack Greenfield's future look like?

I want to see software factories change the industry. This goal relates to the comment I just made about teams. To have industry-wide impact, software factories will have to be owned and developed by many people. Object orientation emerged in the late 70s and early 80s, but in the course of being scaled out to the masses in the 90s a lot was lost along the way. A lot of what we call object-oriented code today is not object oriented; it just happens to be written in an object-oriented language. I think the same thing is happening with service orientation.

The key to fixing these kinds of problems is changing software development from a craft to an engineering discipline. A lot of people have said it cannot be done, and for some time our industry has been in a phase of focusing on craftsmanship at the expense of developing and applying better engineering practices. Unfortunately, craftsmanship does not scale, and there is a tidal wave coming, driven by changes in the global economy, which will require approaches that do scale.

I think the key to scaling up and scaling out is to leverage experience, which is the goal of software factories. In the simplest terms a factory is experience codified and packaged in such a way that others can apply it. As much as I appreciate "following design smells," if you are still smelling your way through the fifth or sixth Web application, something is wrong. You may smell your way through a part of it, through some new requirement or some new algorithm, but by and large most of the work we do is similar to work that has already been done, and we need to get much better at leveraging that experience. We are getting there slowly but surely. If I can help bring about transition, I will have achieved my professional goals.

Top of page