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 aspiring architects within L&T Infotech into full-fl edged architects. As a result, I have extensively researched the role of an architect and talked to many architects across different industries to understand their role and the competencies that make them successful. This article is an attempt to crystallize the wisdom I've gathered from this work.

Being an architect is tough! What architects do is a mystery to much of the world; this is hardly surprising, because an architect's work is intangible—"thought-ware," if you will—and it happens in the background. That makes many wonder about the architect's role in an organization. Architects interact with many stakeholders—CIOs, project managers, business users, and developers—and each expects them to work differently. While the CIO expects an architect to derive a solution road map for implementing the company's IT vision, the developer expects the architect to provide direction on the technical problem. The architect needs to have a bird's-eye view in one scenario, while in some other scenarios, the architect needs to dive deep into the problem area. The architect is expected to be both a generalist and a specialist.

Many companies try to reduce the ambiguity by introducing different flavors of the role, such as enterprise architect or solution architect. Ironically, differentiation within the role can add to the confusion since there is no standardization of the designations across companies. Let's find 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 the CIO's vision and strategy for IT. It includes defining strategic programs (usually multiyear, multimillion dollars for large organizations), selecting the appropriate technology platforms, and providing guidance for implementations. The enterprise architect aids the CIO in making sure that the IT investments are aligned to the business strategy, and provide competitive edge for the organization. The person is also responsible for defining the standards and guidelines, and putting up a governance mechanism to align implementation 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 a strategic IT program. This includes defining the architectural solution for the program (usually spanning multiple technologies), selecting technology platforms in adherence to corporate strategy, handling intergroup communication, and making decisions on technical issues in implementation. The solution architect usually needs to mediate between business and technology teams and various other groups. The solution architect is the "go-to" person for 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 specialist in a particular technology. This person has expert knowledge of the underlying technology function, its integral components, and understands the strengths and limitations of the technology. This person is responsible for determining the applicability of the technology, for defining the best possible architecture using that particular technology, and also for guiding the team in implementing the solution. Generally, the technology architect is expected to know the various 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—infrastructure architect, integration architect, BPM architect, .NET architect, J2EE architect, and so forth.

The Architect's Competencies

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

Leadership

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

Strategic Mindset

This is an ability to look at things from 50,000 feet, at a strategic level, abstracting the operational complexities. It involves taking a larger 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 to achieve it. Architects are often asked to choose a solution that provides the best return on investment to the organization and to create business cases to get 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 as external stakeholders such as vendors and partners. Often, they need to get work out of people who do not report directly to them. They need to be connected to the organization's grapevine to understand the political implications. They should be approachable, to encourage developers to break bad news as soon as possible. Hence, relationship management at several levels is a necessary competency for the architects.

Figure 2. Architect competencies

Communication and Listening Skills

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

The architects need to adapt their communication style when interfacing with different stakeholders. For example, when they deal with the senior management, brevity is important, whereas when they deal with the developers, clarity is more important. The different stakeholders have different expectations—the executives require a business view of the solution explaining the investments, returns, and benefits, whereas the developers are interested in nitty-gritty of the technology implementation. The architect must understand the needs of these different stakeholders and change the articulation style and content of each interface accordingly.

Business-Domain Knowledge

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

Technical Acumen

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

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

Program/Project Management Skills

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

Architects also need to guide their teams in following a process and maintaining discipline. An architect must be conversant in development methodologies (such as RUP, CMMI, and Agile) and architectural frameworks/methodologies (such as Zachman and TOGAF).

Variety of Experience

It is not just the gray hairs. Architects need exposure to projects of varying scope and scale on a range of technology platforms. The size of the project does matter in enhancing your architectural skills. For example, the architectural considerations for a small, local application for a limited number of users will be totally different than those for a large application being accessed by a large user base across the globe. I believe aspiring architects should deliberately try to get into the assignments that offer a range of experiences rather than sticking to the assignments of similar nature.

Does It Matter Where You Work?

The nature of your organization and its services surely influence your overall development as an architect. Generically speaking, if you are working for an IT services company serving multiple customers, you are likely to gain wider exposure to technologies and projects. If you work for a product or platform organization, you will get the opportunity to specialize in a particular business domain and technology suite. If you work for an end-user organization, you can get involved in strategic decisions and see the long term to know the effects of your decisions. On the whole, large companies provide more mentorship opportunities, whereas smaller companies provide more ownership. Of course, each organization is unique and generalizations are by their nature broad-brush. Aspiring architects should carefully evaluate the career opportunities available in their organizations and chart their own path for 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 the curriculum for educating architects. For example, the International Association of 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 Engineering Institute (SEI) has defined a curriculum and training program (http://www.sei.cmu.edu/architecture/arch_curriculum.html).

Many vendor companies provide educational resources for architects. 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 these certifications 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 evaluated on seven competencies, the technology knowledge being just one competency. Although provided by Microsoft, the MCA is actually a technology-independent certification. The Open Group has a similar certification program (http://www.opengroup.org/itac/).

There are other certification programs that are technology-knowledge-based programs, which do not involve any interview process. Often, these are technology-specific programs. For example, Sun Microsystems 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 for architects to pick the brains of fellow architects and network within the architectural 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 of the architect role. You also need technical acumen, good communication skills, and domain and program management skills. Many educational resources and certifications are available. Experienced mentors are another important resource, because training alone is inadequate for developing many necessary skills. Aspiring architects should consider many factors when making career choices, from types of projects to access to mentors. Architecture is a demanding but rewarding profession; it takes determination and good planning to develop your skills fully and mature into the role.

About the author

Amit Unde is a lead architect at L&T Infotech. He is a Microsoft Certified Solutions Architect (MCA) and also a PMA-certified Qualified Project Management Professional. He has over 10 years of experience in Enterprise Architecting, Integration, and Application Development using .NET and J2EE Technology. Amit has worked with many large insurance and manufacturing organizations in the U.S., Europe, and Asia, implementing strategic programs such as IT Strategy Road-Map definition, IT Rationalization, Application Reengineering, and SOA Implementation. He works with L&T Infotech's Insurance Solution Office as a thought leader in conceptualizing innovative solutions for various contemporary business issues in the Insurance domain.

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.