成为一个架构师

以下为作者 Amit Unde 写的一篇与架构师相关的文章,文末有些链接已经失效,做了一些更新。

Becoming an Architect in a System Integrator

Summary

I am currently involved in a program for grooming aspiring architects within L&T Infotech into full fledged 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 since 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 roadmap 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 (Figure 1):

Figure 1: Architect Roles

Enterprise Architect/Chief Architect 企业架构师/首席架构师

The enterprise architect is responsible for implementing the CIO’svision 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 ITprogram. 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 whichcompetencies are required to perform these roles (Figure 2).

Figure 2: Architectural Competency Pyramid

Leadership 领导力

Architect is a leadership designation. An architect is supposed to bring clarity to the requirements, define 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 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.

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 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 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, EA Practice

Certifications

There are many certification programs. The value of these certifications is directly linked to the difficulty level in attaining those.

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

• Open Group Architecture Forum: http://www.opengroup.org/

• ITBang Blog: http://ealearning.cn

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 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.

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 like IT Strategy Roadmap 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 Insurance domain.

更多文章

业务架构学习群资料

D5.1 业务架构-将组织转变为敏捷企业

组织很难实现业务战略,特别是当这些战略跨越业务单元、产品和外部业务领域边界时。问题是为什么?研究表明,很多时候,没有实现业务战略并不是因为这些战略考虑不周。相反,这些失败往往是因为这些战略的范围和影响是模糊或未知的。当战略指令的影响超出规划团队的视线范围,需要跨业务协调和协作时,这个问题会被放大。换言之,无法实现业务战略往往是由于在错误的地方做了正确的事情,在正确的地方做了错误的事情,把好的想法变成失败的项目,失去了机会,浪费了投资。

阅读更多»