Becoming an Architect in a System Integrator

by Amit Unde

Summary I am currently involved in a program for grooming aspiring architects within L&T Infotech into fulledged 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 Ive gathered from this work.

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 dening 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 conicts, implementation issues, or decisions. In some organizations, this role is dened 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 dening 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.

Being an architect is tough! What architects do is a mystery to much of the worldthis is hardly surprising since an architects work is intangiblethought-ware, if you willand it happens in the background. That makes many wonder about the architects role in an organization. Architects interact with many stakeholdersCIOs, project managers, business users, and developersand each expects them to work differently. While the CIO expects an architect to derive a solution roadmap for implementing the companys IT vision, the developer expects the architect to provide direction on the technical problem. The architect needs to have a birds 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 avors 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. Lets nd the commonalities and dene these different avors of the role.

Figure 1: Architect Roles

High Enterprise Architects
Strategy Focus

The Architect Role

Typically, there are three different variations of the roles (Figure 1): Enterprise Architect/Chief Architect The enterprise architect is responsible for implementing the CIOs vision and strategy for IT. It includes dening 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 dening the standards and guidelines, and putting up a governance mechanism to align implementation to the dened standards and guidelines. In some organizations, this role is merged with that of the CIO
Journal 15 www.architecturejournal.net

Solution Architects

Organization Scope Project Scope Technical Architects

Low

Technology Breadth

Technology Depth

Technology Focus

High
7

Becoming an Architect in a System Integrator

There could be more avors of this roleinfrastructure architect, integration architect, BPM architect, .NET architect, J2EE architect, and so forth.

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 dened 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 expectationsthe executives require a business view of the solution explaining the investments, returns, and benets, 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 dening 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 dening 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 condence with them, the architect must speak in their business vocabulary and draw examples from their domain. Technical Acumen This is a key competency since 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 handson experience in coding. Since I was a developer, I may be biased, but I think its helpful to have a coding background to understand the possible issues and also to identify solutions to the problems. Nonprogramming architects often nd themselves detached from the development teams and may be unable to help them with technology problems. This could seriously affect the teams 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 nd themselves estimating, choosing development methodology, and
www.architecturejournal.net Journal 15

The Architects Competencies

Now that we have dened roles and responsibilities, lets look at which competencies are required to perform these roles (Figure 2). Leadership Architect is a leadership designation. An architect is supposed to bring clarity to the requirements, dene the foundation, and lay out the roadmap 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 nd 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 condent enough to stand up to negative criticism, work their way through roadblocks, and shield the development team from political pressures. Hence, the most signicant 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 leaders 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 organizations 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: Architectural Competency Pyramid

Strategy

Mindset

Communication Technical Acumen Domain Knowledge Leadership Project Mgmt Experience Foundation Skills

Relationship Mgmt

Becoming an Architect in a System Integrator

planning with the project managers. It is therefore benecial 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.

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 certication. The Open Group has a similar certication program (http:// www.opengroup.org/itac/). There are other certication programs that are technologyknowledge-based programs, which do not involve any interview process. Often, these are technology-specic programs. For example, Sun Microsystems has a program for certifying on J2EE technology (http:// www.sun.com/training/certication/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.

Does It Matter Where You Work?

The nature of your organization and its services surely inuence 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.

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 certications are available. Experienced mentors are another important resource since 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 fully develop your skills and mature into the role.

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 dened a skill library for architects (http://www.iasahome.org/web/home/skillset) and a standard curriculum and certications. Similarly, the Software Engineering Institute (SEI) has dened a curriculum and training program (http://www.sei.cmu.edu/architecture/arch_curriculum.html). Many vendor companies provide educational resources for architects. Microsofts 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/). Certications There are many certication programs. The value of these certications is directly linked to the difculty level in attaining those. For example, Microsoft Certied Architect programs (http://www.microsoft.com/
Journal 15 www.architecturejournal.net

About the Author Amit Unde is a lead architect at L&T Infotech. He is a Microsoft Certied Solutions Architect (MCA) and also a PMA-certied Qualied 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 like IT Strategy Roadmap denition, IT Rationalization, Application Reengineering and SOA Implementation. He works with L&T Infotechs Insurance Solution Ofce as a thought leader in conceptualizing innovative solutions for various contemporary business issues in Insurance domain.
9