Why every Computer Engineer is an Architect in the making

Technological architecture suffers from a peculiar paradox- despite being the subject of many discussions, its true scope remains a source of much confusion. Perhaps it is a sign of the times, wherein the current stage of technical development demands architectural capabilities from almost everyone, thus resulting in a plethora of architectural charts and an equal amount of criticism about weak design and convoluted structures.

CaoYaojun, senior engineer of Alibaba’s International Technology Division, sheds light on what it means to be an architect at Alibaba, and the values that accompany such a position.

The Two Types of Architects

Anyone who has worked in the tech industry for more than five years would be familiar with undertaking unspecific architectural responsibilities within small R&D teams or projects. Such situations require key design and implementation of projects, maintenance of product infrastructures, and introduction of viable new ideas and frameworks. Successfully executing these duties earns employees a good reputation among team members, and sets them apart in the eyes of upper management.

This is what one could refer to as a “part-time architect”, a responsibility that most developers or project managers assume for fractions of time within their own roles, implementing self-created architecture when overseeing small units.

 A “full-time architect”, on the other hand, can be expected to contend with challenges bigger in scale and impact, spanning all business systems. This type of architect is rarely directly responsible for specific projects. Instead, they work with larger teams and wider domains, gaining an in-depth understanding of all projects.

 Though there is hardly any consensus on the validity of tech architects or architect teams within companies, Alibaba continues to follow a middle-of-the-road approach based on the requirements of different team and the specifications of each project.

The Responsibilities of a Full-time Architect

In any attempt to investigate the nature of such a role, we must first limit and define the responsibilities. A good example of this is Microsoft’s multiple classifications - enterprise architects (EA), infrastructure architects (IA), technology-specific architects (TSA), and solution architects (SA) - based on various disciplines and departments within the company.

 With the exception of EAs, Alibaba has used all types of architects across different periods of operation. Most part-time architects, usually concentrating on product system architectures, fall within the category of SAs, while IAs and TSAs account for more full-time architects, envisioning problem domains and their corresponding system architectures.

 Given the nature of the role, full-time architects are saddled with a commensurate set of responsibilities: 

 Responsibility 1. Global Technical Planning

An architect's first and foremost responsibility is demonstrating proficiency in technical planning. The most important output here is the architecture itself, in other words, the blueprint, or what is called a ‘chart’ at Alibaba. The main test here for the architect lies in determining not only the elements that make it onto the chart and explaining the reasons why, but also the ones that aren’t included. For a chart to guide the entire team’s efforts uniformly, it must cut through the chaff, remaining as clear and specific as possible.

 Another aspect of this is the incorporation of a holistic perspective that is both inclusive and considerate. Inclusive technical planning enables the chart to serve as a combination of different sub-charts and offer clear guidance in all areas; a considerate chart focuses on short-term and long-term interests of not only the team but the company as well, ensuring sustainable growth and harmonious development of the unit within the larger organization.

 A discerning eye aside, the architect must also possess the communication skills to convey, in-depth, the rationale for adopting pattern-selection methodologies to various stakeholders, including those who may not be experts in the relevant technical field. 

Responsibility 2. Uniformity in Methodologies, Norms and Mechanisms

A blueprint, regardless of quality, still requires the architect to supplement it with methodologies, norms, and mechanisms for its successful implementation. Though fairly tedious and complicated, providing support in form of such materials ensures that the entire team acts on the blueprint efficiently and effectively. Norms guide orderly progression, for which a chart must be dismantled into vertical and horizontal dimensions, and be functionally cohesive enough to correlate powers and responsibilities.

 Responsibility 3 : Soundness of Infrastructure

The blueprint defines the team actions, the norms guide processes, and the infrastructure serves as the arsenal. The soundness of infrastructure determines whether the team is equipped with rifles, or with tanks. Since this is often a responsibility decided on a case-to-base basis, especially in instances where physical architecture teams are present, the core architect should ideally assume a portion of this responsibility for the overall success of the blueprint.

Responsibility 4: Implementation

Ultimately, any plan that cannot be implemented is the equivalent of empty talk. Since a vast majority of architectural responsibilities channel hard power, the requirement of wielding soft power makes implementation a challenge for most full-time architects. Responding to external factors and various parties within the organizational structure is a crucial component of implementation, and full-time architects that detach from the process at this stage run the risk of having their plans branded impractical, or worse, impracticable.

The Rights of Full-time Architects

Though their role within companies and company processes may be unconventional, architects aren’t expected to operate in a framework devoid of rights, especially when dealing with influence. Some may feel that only organizational leaders, armed with the power to mobilize and coordinate, fit such a profile. Others believe that since architects exist on the periphery of organizations, they can rarely be held responsible for technical teams and their output.

Most leaders today perform duties similar to those of EAs- especially in mapping various business systems and components, and planning their evolution. However, due to scarcity of time and energy, such duties focus on long-term organizational policy rather than niche projects, demonstrating the stark difference in influence levels between corporate leaders and EAs.

Assessment of Full-time Architects

Companies may struggle to evaluate the performance of architects in the context of complex roles and responsibilities, and architects may find themselves rudderless when it comes to ascertaining personal goals.

Teams, professional rights, and external environments are highly variable and therefore unreliable as indicators of success. A truly results-oriented appraisal may incorporate these factors in a subjective capacity, but would place the greatest emphasis on implementation and the architect’s involvement in fulfilling the chart.

Some Ideas on Implementation

Given the current scenario, establishing an “architecture language” should be the foremost priority for consistent communication and collaborations. The basis of the language does not lie in new syntax, but clearly defining business architecture for production teams, and application and deployment architecture for OPS teams.

This should pave the way for the creation of an “identity body”, gradually formed by building technical capabilities, ease of knowledge transfer, and specialized staff systems.

Architects may also find that embracing a client-facing attitude when dealing with team members enables better participation in the implementation process. After all, an architect facilitates the provision of platforms, services and opportunities with the purpose of empowering each R&D member in achieving their targets.

Architecture creates something from nothing, abstraction inverts the exterior to the interior, and design transforms that which is coarse into the polished product.

.     .     .