by Amit Unde

Contents

Introduction
The Architect Role
The Architect's Competencies
Does It Matter Where You Work?
Getting There
Conclusion

Introduction

I am currently involved in a program for grooming aspiringarchitects within L&T Infotech into full-fledged architects. As a result, I have extensively researched the role of anarchitect and talked to many architects across different industries tounderstand their role and the competencies that make them successful. Thisarticle is an attempt to crystallize the wisdom I've gathered from this work.

Being an architect is tough! What architects do is a mysteryto much of the world; this is hardly surprising, because an architect's work isintangible—"thought-ware," if you will—and it happens in the background. Thatmakes many wonder about the architect's role in an organization. Architectsinteract with many stakeholders—CIOs, projectmanagers, business users, and developers—and each expectsthem to work differently. While the CIO expects an architect to derive asolution road map for implementing the company's IT vision, the developerexpects the architect to provide direction on the technical problem. Thearchitect needs to have a bird's-eye view in one scenario, while in some other scenarios, the architect needs to dive deep into the problemarea. The architect is expected to be both a generalist and a specialist.

Many companies try to reduce the ambiguity by introducingdifferent flavors of the role, such as enterprise architect or solutionarchitect. Ironically, differentiation within the role can add to the confusionsince there is no standardization of the designations across companies. Let'sfind the commonalities and define these different flavors of the role.

The Architect Role

Typically, there are three different variations of the roles(see Figure 1):

Figure 1. Architect roles

Enterprise Architect/Chief Architect

The enterprise architect is responsible for implementing theCIO's vision and strategy for IT. It includes defining strategic programs(usually multiyear, multimillion dollars for large organizations), selectingthe appropriate technology platforms, and providing guidance forimplementations. The enterprise architect aids the CIO in making sure that theIT investments are aligned to the business strategy, and provide competitiveedge for the organization. The person is also responsible for defining thestandards and guidelines, and putting up a governance mechanism to alignimplementation to the defined standards and guidelines. In some organizations,this role is merged with that of the CIO and has the title "Chief Architect."This is especially true for many product and platform companies.

Solution Architect

The solution architect is responsible for implementing astrategic IT program. This includes defining the architectural solution for theprogram (usually spanning multiple technologies), selecting technologyplatforms in adherence to corporate strategy, handling intergroupcommunication, and making decisions on technical issues in implementation. Thesolution architect usually needs to mediate between business and technologyteams and various other groups. The solution architect is the "go-to" personfor any technology conflicts, implementation issues, or decisions.

In some organizations, this role is defined just as"Architect." The senior position has the title "Lead Architect."

Technical Architect

The technical architect is usually a technology specialistin a particular technology. This person has expert knowledge of the underlyingtechnology function, its integral components, and understands the strengths andlimitations of the technology. This person is responsible for determining theapplicability of the technology, for defining the best possible architectureusing that particular technology, and also for guiding the team in implementingthe solution. Generally, the technology architect is expected to know thevarious vendor tools in the technology area, the latest trends in the market,and various architectural alternatives for implementing the solution.

There could be more flavors of this role—infrastructurearchitect, integration architect, BPM architect, .NET architect, J2EEarchitect, and so forth.

The Architect's Competencies

Now that we have defined roles and responsibilities, let'slook at which competencies are required to perform these roles (see Figure 2).

Leadership

Architect is a leadership designation. An architect issupposed to bring clarity to the requirements, define the foundation, and layout the road map for execution. At each step, the architect has to makedecisions and take ownership. Many times, the right decision will not be simpleor clear-cut. The architect needs to find a solution that will work. It may notalways be the best solution on technical merits, but it must be what will work bestin the particular organization. To reach these decisions, the architect needsto have a very good understanding of the political environment, and should havethe ability to generate "buy-in" from all the stakeholders to move the projectforward. Architects must be confident enough to stand up to negative criticism,work their way through roadblocks, and shield the development team frompolitical pressures. Hence, the most significant competency an architect musthave is leadership.

Strategic Mindset

This is an ability to look at things from 50,000 feet, at astrategic level, abstracting the operational complexities. It involves taking alarger vision such as "taking an organization into leader's quadrant by 2010"and dividing it into smaller, tangible steps to make it simpler for others toachieve it. Architects are often asked to choose a solution that provides thebest return on investment to the organization and to create business cases toget the budgets. They often need to deal with top-level executives (CIO, CEO)where it is necessary to present a view at strategic level.

Human Relationship Management

Architects deal with many internal stakeholders as well asexternal stakeholders such as vendors and partners. Often, they need to getwork out of people who do not report directly to them. They need to beconnected to the organization's grapevine to understand the politicalimplications. They should be approachable, to encourage developers to break badnews as soon as possible. Hence, relationship management at several levels is anecessary competency for the architects.

Figure 2. Architect competencies

Communication and Listening Skills

Listening skills are often considered part of communicationskills, but I mention them explicitly to emphasize their importance. It isessential that the architects listen to the business users to understand theirbusiness problem, to the senior management to understand the most workablesolution, and to the developers to understand the possible problems in theimplementation. At the same time, it is important for the architects toeffectively articulate the solution to the business users to generate buy-in,to the senior manager for funding and support, and to the developers so thatthey understand how to implement the defined architecture.

The architects need to adapt their communication style wheninterfacing with different stakeholders. For example, when they deal with thesenior management, brevity is important, whereas when they deal with thedevelopers, clarity is more important. The different stakeholders havedifferent expectations—the executives require a business view of the solutionexplaining the investments, returns, and benefits, whereas the developers areinterested in nitty-gritty of the technology implementation. The architect mustunderstand the needs of these different stakeholders and change thearticulation style and content of each interface accordingly.

Business-Domain Knowledge

It is very important to understand the problem statementbefore defining a solution for it. It is also important to be aware ofnon-stated requirements, such as regulatory and legal requirements, competitivesolutions, and so forth. The sound business knowledge not only helps indefining the appropriate solution, it is also necessary for understanding the requirementsand articulating the solution. To have meaningful dialogue with the businessusers and to establish confidence with them, the architect must speak in theirbusiness vocabulary and draw examples from their domain.

Technical Acumen

This is a key competency, because the architects are hired fortheir technical acumen. It is essential to have exposure to the breadth oftechnologies and vendor platforms to understand their relative strength andweaknesses, and make a best choice to suit the requirements. Even for a"specialist" role such as technical architect, it is desirable to have exposureto multiple tools and vendor platforms, and to be aware of technology trendswithin the industry.

A topic of debate is whether the architect needs to havehands-on experience in coding. Since I was a developer, I may be biased, but Ithink it's helpful to have a coding background to understand the possibleissues and also to identify solutions to the problems. Nonprogrammingarchitects often find themselves detached from the development teams and may beunable to help them with technology problems. This could seriously affect theteam's productivity. (It is, of course, nevertheless possible for a team todeliver a good solution with the help of senior developers.)

Program/Project Management Skills

Why should an architect be required to have projectmanagement skills? If you take a close look at what architects are doing, youmight see they are doing nothing but managing a project or a program, albeitlargely from the technology standpoint. They often find themselves estimating,choosing development methodology, and planning with the project managers. It istherefore beneficial to have project management experience or training.

Architects also need to guide their teams in following aprocess and maintaining discipline. An architect must be conversant indevelopment methodologies (such as RUP, CMMI, and Agile) and architecturalframeworks/methodologies (such as Zachman and TOGAF).

Variety of Experience

It is not just the gray hairs. Architects need exposure toprojects of varying scope and scale on a range of technology platforms. Thesize of the project does matter in enhancing your architectural skills. Forexample, the architectural considerations for a small, local application for alimited number of users will be totally different than those for a largeapplication being accessed by a large user base across the globe. I believeaspiring architects should deliberately try to get into the assignments thatoffer a range of experiences rather than sticking to the assignments of similarnature.

Does It Matter Where You Work?

The nature of your organization and its services surelyinfluence your overall development as an architect. Generically speaking, ifyou are working for an IT services company serving multiple customers, you arelikely to gain wider exposure to technologies and projects. If you work for aproduct or platform organization, you will get the opportunity to specialize ina particular business domain and technology suite. If you work for an end-userorganization, you can get involved in strategic decisions and see the long termto know the effects of your decisions. On the whole, large companies providemore mentorship opportunities, whereas smaller companies provide moreownership. Of course, each organization is unique and generalizations are bytheir nature broad-brush. Aspiring architects should carefully evaluate thecareer opportunities available in their organizations and chart their own pathfor development.

Getting There

As the architect role has gained visibility in recent years,resources for aspiring architects have grown.

Education

Initiatives have been set forth to standardize thecurriculum for educating architects. For example, the International Associationof Software Architects (IASA) has defined a skill library for architects (http://www.iasahome.org/web/home/skillset)and a standard curriculum and certifications. Similarly, the Software EngineeringInstitute (SEI) has defined a curriculum and training program (http://www.sei.cmu.edu/architecture/arch_curriculum.html).

Many vendor companies provide educational resources forarchitects. Microsoft's MSDN Architecture Center is a one (http://msdn2.microsoft.com/en-us/architecture/default.aspx).IBM DeveloperWorks also provides a resource site (http://www-128.ibm.com/developerworks/architecture/).

Certifications

There are many certification programs. The value of thesecertifications is directly linked to the difficulty level in attaining those.For example, Microsoft Certified Architect programs (http://www.microsoft.com/learning/mcp/architect/default.mspx)are based on an expert panel interview during which the architect is evaluatedon seven competencies, the technology knowledge being just one competency.Although provided by Microsoft, the MCA is actually a technology-independentcertification. The Open Group has a similar certification program (http://www.opengroup.org/itac/).

There are other certification programs that aretechnology-knowledge-based programs, which do not involve any interviewprocess. Often, these are technology-specific programs. For example, SunMicrosystems has a program for certifying on J2EE technology (http://www.sun.com/training/certification/java/scea.xml).

Groups and Forums

There are many blogs, groups, and forums available forarchitects to pick the brains of fellow architects and network within thearchitectural community. Here are some of the most notable ones:

• International Association of Software Architect (IASA): http://www.iasahome.org
• Worldwide Institute of Software Architects (WWISA): http://www.wwisa.org
• MSDN Forum on Architecture: http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=58&SiteID=1
• Open Group Architecture Forum: http://www.opengroup.org/architecture/
• Grady Booch Blog: http://www.booch.com/architecture/blog.jsp
• Blogs by Microsoft Architects: http://msdn2.microsoft.com/en-us/architecture/aa699386.aspx

Conclusion

Experience and leadership qualities form the foundation ofthe architect role. You also need technical acumen, good communication skills,and domain and program management skills. Many educational resources andcertifications are available. Experienced mentors are another importantresource, because training alone is inadequate for developing many necessaryskills. Aspiring architects should consider many factors when making careerchoices, from types of projects to access to mentors. Architecture is ademanding but rewarding profession; it takes determination and good planning to develop your skillsfully and mature into the role.

About the author

Amit Undeis a lead architect at L&T Infotech. He is aMicrosoft Certified Solutions Architect (MCA) and also a PMA-certified QualifiedProject Management Professional. He has over 10 years of experience inEnterprise Architecting, Integration, and Application Development using .NETand J2EE Technology. Amit has worked with many largeinsurance and manufacturing organizations in the U.S., Europe, and Asia,implementing strategic programs such as IT Strategy Road-Map definition, ITRationalization, Application Reengineering, and SOA Implementation. He workswith L&T Infotech's Insurance Solution Office asa thought leader in conceptualizing innovative solutions for variouscontemporary business issues in the Insurance domain.

This articlewas published in the Architecture Journal, a print and online publicationproduced by Microsoft. For more articles from this publication, please visitthe Architecture Journal Web site.