Learn the discipline, pursue the art, and contribute ideas at www.ArchitectureJournal.net Resources you can build on. Journal 15 The Role of an Architect We Don’t Need No Architects! Becoming an Architect in a System Integrator Architecture Journal Profi le: Paul Priess The Open Group’s Architect Certifi cation Programs The Need for an Architectural Body of Knowledge A Study of Architect Roles by IASA Sweden The Softer Side of the Architect An A-Z Guide to Being an Architect ® Contents TM Journal 15 Foreword 1 by Simon Guest We Don’t Need No Architects 2 by Joseph Hofstader What does an architect do? What should an architect do? Join Joseph Hofstader as he examines the role of an architect. Becoming an Architect in a System Integrator 7 by Amit Unde In this article, Amit Unde explores the skills that aspiring architects need in a leading System Integrator. Architecture Journal Profi le: Paul Preiss 10 We chat with Paul Preiss, founder of a nonprofi t group called IASA (International Association of Software Architects). The Open Group’s Architect Certifi cation Programs 13 by Leonard Fehskens Join Leonard Fehskens as he outlines one of the industry’s architect certifi cation programs, Open Group’s ITAC (IT Architect Certifi cation). The Need for an Architectural Body of Knowledge 17 by Miha Kralj Miha Kralj covers an Architectural Body of Knowledge, an effort led by the Microsoft Certifi ed Architect community. A Study of Architect Roles by IASA Sweden 22 by Daniel Akenine Discover a perspective of architect roles through a recent study conducted by the local IASA chapter in Sweden. The Softer Side of the Architect 26 by Joe Shirey Joe Shirey discusses why soft skills are equally important as technical skills for the architect role. An A-Z Guide to Being an Architect 29 by Mark Bloodworth and Marc Holmes Explore a list of everything you need to become an architect using this handy and lighthearted A-Z guide. Resources you can build on. www.architecturejournal.net Founder Arvindra Sehmi Microsoft Corporation Foreword Editor-in-Chief Simon Guest Microsoft Corporation Microsoft Editorial Board Gianpaolo Carraro Dear Architect, Darryl Chantry Diego Dagum John deVadoss Welcome to Issue 15 of The Architecture Journal, where we take a quick John Evdemon breather from technology, turn the spotlight on ourselves and examine the Neil Hutson role of the IT Architect. This has been a fascinating issue to put together, Eugenio Pace partly because of the different perspectives that many people in our Javed Sikander profession bring to the table, but also because of the passion involved in Philip Teale defi ning what is still a very emerging profession. We believe this issue of the journal goes beyond our normal boundaries of Publisher IT architecture and is applicable to anyone who would like to understand why Lisa Slouffman Microsoft Corporation architects exist, what architects do, why organizations need them, and most importantly, what one needs to know to be one. In short, this is an issue for Design, Print, and Distribution both the architect and those aspiring to be architects, and as such, this issue United Business Media LLC – should be shared with your colleagues. Contract Publishing The articles you will fi nd in the following pages will talk about skills, Chris Harding, Managing Director responsibilities, experiences, and many other topics related to being or Angela Duarte, Publication Manager becoming an architect, so it seems appropriate in this introduction to attempt Kellie Ferris, Director of Advertising to answer a question that many aspiring architects have asked — Why do I Bob Steigleider, Production Manager want to be an architect? ® The obvious answer, and one I hear at practically every aspiring architect event I attend, is quite simply — “if architect appears in my job title I will get paid more.” While that is probably true, and in many cases could make the The information contained in The Architecture Journal difference in allowing your family to eat prime rib instead of hamburger, (“Journal”) is for information purposes only. The material in the Journal does not constitute the opinion of Microsoft fulfi lling a monetary requirement does not necessarily address the less Corporation (“Microsoft”) or United Business Media LLC tangible goals we all have for ourselves. (“UBM”) or Microsoft’s or UBM’s advice and you should If most people want more than just to be paid well, why is money the not rely on any material in this Journal without seeking independent advice. Microsoft and UBM do not make any commonly mentioned benefi t to becoming an architect? The answer is that warranty or representation as to the accuracy or fi tness this is probably the only common point. Just as every architect has their own for purpose of any material in this Journal and in no event perspective on good architecture, every architect has their own perspective do Microsoft or UBM accept liability of any description, including liability for negligence (except for personal injury on what makes a good architect and why they want to be one. or death), for any damages or losses (including, without Whether you are an IT Architect by title, or someone that is heading that limitation, loss of business, revenue, profi ts, or consequential way in your career, we hope that you fi nd the articles useful and insightful for loss) whatsoever resulting from use of this Journal. The Journal may contain technical inaccuracies and typographical the work that you do every day. We look forward to hearing your feedback errors. The Journal may be updated from time to time and about this and previous issues at [email protected]. may at times be out of date. Microsoft and UBM accept no responsibility for keeping the information in this Journal up to date or liability for any failure to do so. This Journal contains material submitted and created by third parties. To the maximum extent permitted by applicable law, Microsoft and UBM exclude all liability for any illegality arising from or error, omission or inaccuracy in this Journal and Microsoft and UBM take no responsibility for such third party material. Simon Guest The following trademarks are registered trademarks of Microsoft Corporation: Microsoft, PowerPoint, and Windows. Any other trademarks are the property of their respective owners. All copyright and other intellectual property rights in the material contained in the Journal belong, or are licensed to, Microsoft Corporation. You may not copy, reproduce, transmit, store, adapt or modify the layout or content of this Journal without the prior written consent of Microsoft Corporation and the individual authors. Copyright © 2008 Microsoft Corporation. All rights reserved. • Journal 15 • www.architecturejournal.net 1 We Don’t Need No Architects! by Joseph Hofstader Summary That meeting, and many subsequent conversations with others, led The role of an architect in software development has me to wonder what exactly the role of an architect is on a software come under attack of late. On software projects, the product and what the characteristics of good architects are. The most title Architect is often ambiguously defi ned and the concise defi nition I have come up with is: The role of the IT architect value provided by architects is not easily quantifi able. is to solve a problem by defi ning a system that can be implemented The perception that architects live in an “ivory tower” using technology. Good architects defi ne systems by applying abstract knowledge and proven methods to a set of technologies with the goal of disassociated from the realities of delivering a software creating an extendible and maintainable solution. solution contributes to some of the animosity toward From this concise defi nition, we can extrapolate that good architects those of us with the title. draw upon a foundation of knowledge to be successful in their role. To This article presents a defense of the practice of “solve a problem,” the architect must have a good understanding of the architecture in software development. It defi nes the problem domain. To “defi ne a system using technology,” implies that qualities of an effective architect and describes the the architect has technical acumen. “Abstract knowledge” requires the skills required to succeed in this profession. The article architect to be able to conceptualize the technical solution. “Proven examines widely held perceptions of architects and methods” assumes an understanding of the patterns used to solve some of the mistakes that architects make which similar problems. Figure 1 depicts the key skills of an architect. contribute to negative perceptions. Ultimately, the The key benefi t an architect brings to a project is the ability to apply intent is to show the value good architects bring to a those skills in the defi nition and development of a robust software software development effort. solution. An effective architect is part of the continuum of all phases of a software development project, with skills critical to defi ning the problem space, such as domain knowledge and the ability to conceptualize a software solution, as well as the ability to defi ne the Who Are Those Guys? solution space using appropriate technologies and patterns. The risk In the fi eld of information technology, no title conjures up more raw of not having an architect actively involved in product development emotion than Architect. I have witnessed and been involved in many debates over the defi nition of the term. When I introduce myself at meetings, reactions range from “we’re not worthy” to “we do not Figure 1: The key skills of an architect need an architect”—the former, although friendly, refl ecting the lofty image of architects, and the latter implying that an architect’s knowledge and skills are irrelevant.