Cracking the IT Architect Interview

Chapter 1. Architect Roles and Growth Paths

A good architect is one who leads by example, and without a good understanding of the technology stack and business domain, an architect is not equipped to deliver the pre-requisite outcomes for the enterprise. The team members typically have deep-dive expertise in the specific technology areas but will lack confidence in the architect if he is not competent with in the domain or technology.

The architect is the bridge between the technology and the business team, and hence he/she must understand all aspects of the technology stack to be able to liaise with the business team. The architect must be conversant in the business domain in order to drive the team and all the stakeholders toward a common organizational goal. An architect might not be busy all the time, but he/she leverages decades of expertise to solve and monitor the organizational IT landscape, making quick decisions during various stages of the SDLC. The project manager handles the people management aspects, freeing the architect of the hassles of operational tasks.

An excellent architect is pretty much a hands-on person and should be able to mentor members of the design and implementation teams. He/she should be knowledgeable and competent to handle any complex situation.

An architect's success in interviews does not come easily. One has to spend hours prior to each interview, wading through various books and references for preparation. The motivation for this book was to consolidate all this information into a single reference guide that will save time prior to interviews and can be a ready reference for important topics that need to be revised before the interviews.

An architect's critical competencies

Architecture competencies are the ability to effectively carry out the functions and activities necessary to produce architectures that are aligned with organization's business goals. A competent software architect is one who produces high-quality software architectures with acceptable cost. The following paragraphs explain the critical qualities for an software architect:

Figure 1: Architects Compentencies

Leadership: The architect has to make decisions and take ownership, and a lot of times, the right choice is not simple. The architect needs to find a solution that works, and it may not always be the best alternative on technical merits but it should work best in the given situation. To take such decisions, the architect must have an excellent understanding of the cultural and political environments within the organizations and should have the ability to generate buy-in from the key stakeholders.
Strategic Mindset: This is the ability of an architect to look at things from a 10,000-foot elevation, at a strategic level, isolating the operational nuances. This requires creating an organizational vision and then dividing it into achievable objectives to make it simpler for all the stakeholders to achieve these results. For example, making the product a market leader Architects are often tasked with finding an alternative solution that provides the best ROI to the organization and creating a business case for getting sponsorship. Architects often work with top-level executives such as CEO, CTO, and CIO, where it is necessary to create and present strategic architectures and roadmaps for organizations.
Domain Knowledge: It is a critical aspect to understand the problem domain before creating and defining a solution. It is also a mandatory requirement to be knowledgeable about the domain-specific requirements, such as legal and regulatory requirements. A sound domain understanding is not only essential for understanding the requirements and evangelizing the target state but also helps in articulating the right decisions. The architect must be able speak the business vocabulary and draw experiences from the domain to be able to have meaningful discussions with the business stakeholders.
Technical Acumen: This is a key competency as architects are hired for their technical expertise and acumen. The architect should have a breadth of expertise in technologies and platforms to understand their strengths and weaknesses and make the right decisions. Even for technical architect roles, it is mandatory to have skills in multiple technology stacks and frameworks and to be knowledgeable about technology trends.

Architects' growth paths

Software architecture discipline has matured since its inception. This architecture practice is no longer reserved for the veteran practitioners. The core concepts and principles of this discipline can now be acquired in training programs, books and college curriculum. The discipline is turning from an art into a competency accessible through training and experience. A significant number of methodologies, frameworks and processes have been developed to support various perspectives of the architectural practice. A software architect is responsible for creating the most appropriate architecture for the enterprise or system to suit the business goals, fulfill user requirements, and achieve the desired business outcome.

A software architect's career starts with a rigorous education in computer science. An architect is liable for making the hardest decisions on software architecture and design. Hence he/she must have a sound understanding of the concepts, patterns, and principles independent of any programming languages.

There are a number of flavors of architect that exist: enterprise architect, business architect, business strategy architect, solution architect, infrastructure architect, security architect, integration architect, technical architect, systems architect and software designer.

There are other variations as well, but this section describes the previously mentioned flavors in more detail. Finally, for an architect, learning must never stop. Continuous participation in the communities and learning about new technologies, methodologies, and frameworks are mandatory for value creation and to stay ahead of the demand curve.

The following paragraphs describe various roles basis the role definition, artifacts and the competencies:

Figure 2: Architects Competencies

Enterprise architect/chief architect/lead architect

Enterprise architects create the CxO's vision and strategy for organizations. This includes defining strategic roadmaps, selecting appropriate technology stacks and providing guidance to the design and builds teams:

Artifacts: IT strategies, capability maps, city plans, integration strategies, as-is/to-be analysis, architectural principles, gap analysis, life cycle analysis, and application portfolio strategy.

Description: EAs help the chief technology officer/chief information officer/chief executive officer/chief marketing officer to ensure that the IT budgets are aligned with the organization's business strategy and that it will provide a competitive advantage for the enterprise. EAs are also responsible for establishing standards and frameworks and setting up a governance structure to align all the programs with the defined standards and frameworks. In some enterprises, this role may be merged with the CxO and has the title Chief Architect.

Competencies: Deep-dive competencies in IT and business, negotiation and leadership skills, experience in program management, governance, knowledge in enterprise architecture and modeling techniques.

Business architect

Business architects work with the business to thoroughly articulate the businesses operating model. They are competent in business architecture, capability modelling and business processes modeling. They also support solution architects with analysis of existing or new solutions.

Artifacts: Business process maps, use scenarios, information modeling.

Description: They are skilled to know how the IT application support the business needs and recommends capability or process improvements along with enterprise architects. Business architects also support ongoing engagements in the organization using their authority to ensure that projects deliver value to the business. Business architects drive the critical areas related to business process improvements. The business architect is also a critical resource in every organization.

Competencies: Deep knowledge in the business, process modeling, requirement analysis, and workshop leadership skills.

Domain architects

Domain architects focus on a specific domain and have deep expertise in that area.

Artifacts: Domain diagrams, domain maps, interfaces, technical interfaces, integration strategies.

Description: Typically these architects only concentrate on specific areas, for example, security architect, information architect, integration architect, infrastructure architect, data architect, business architect, and so on.

Competencies: Broad technical competencies, deep competencies in infrastructure, data models, service orientation, and a good understanding of enterprise architecture.

Solution architect

A solution architect is responsible for implementing strategic IT architecture.

Artifacts: Application diagrams, system maps, service interfaces, technical interfaces, integration strategies.

Description: Solution architects define the architectural solution, finalize the technology stack in adherence to principles and guidelines, handle stakeholder communications, and make critical decisions specific to technology options. The solution architect mediates between technology and business team members and various other stakeholders. The solution architect is the go to Subject Matter Expert (SME) for any technology decisions, challenges and conflicts.

Competencies: Broad technical knowledge, deep competencies in infrastructure and data models, service orientation, and good understanding of enterprise architecture.

Technical architect/designer

The technical architect is a SME in a specific technology or framework.

Artifacts: Frameworks, class models, patterns, and aspects.

Description: Technical architect have expertise in the underlying platform, its components, and are able to articulate the strengths and weakness of the technology platform. The TA is liable for creating and defining the best architecture leveraging this specific technology platform, and also mentoring the implementation teams. Technology architect are competent in different tools, the latest trends, and different architectural alternatives for implementing the solution.

Competencies: Deep knowledge in programming, frameworks, standards, and technical modeling.

Qualities of an architect

This describes the skills, knowledge, qualification, experience, or capability:

Visual thinking is the ability to communicate with diagrams and illustrations.
The ability to communicate complex ideas to wide audience and well as excellent written communication skills.
A solid foundation of process engineering, lean or six sigma.
A solid expertise in the capability modeling, processes modelling, and application-to-capability mapping and service oriented modelling.
The skill to drive architectural review discussion using the various methods of architectural evaluation.
Expertise in software development methodologies such as waterfall, RUP, agile and spiral.
Expertise in infrastructure domain, including servers, load balancers, storage, networking, firewalls and routing.
Understanding of the security domain including authentication, encryption, authorization, security mechanisms and PKI.
Expertise in the data management, RDBMS, extract-translate-load, business intelligence data management, data integration, data distribution and caching strategies.
The ability to address the system quality attribute that should be paramount to the system, and provide alternatives in the solution.
Architects must be able to inspire and motivate the team members. A large part of the job is to evangelize and influence a set of ideals in the organization.
There will be times when an architect will have to negotiate with the stakeholders to get the final node. Architects are in an individual contributor's role and do not get into people management.
Critical thinking, that is, being able to think swiftly, is often required.
Architects often have to work with a set of complex and unique problems and challenges, and be able to articulate and provide solutions.
Big thinking is the ability to analyze at a problem from 360-degree perspective than a tunnel vision effect.
Business acumen. Understanding the domain in which one works is essential, to help you understand how the technology can affect the business. Being in sync with the business gives architect's much-needed credibility.
Process orientation is the ability of thinking in terms of process which includes process modelling, capability modelling and service modelling.
People skills is the ability to interacting with various stakeholders on an ongoing basis.

An architect's competency framework

The purpose of the architecture competency framework is to help architects understand the competencies for required different architect roles within the industry. To address this challenge, the architecture competency framework provides a standard set of guidelines for the architecting skills and proficiency levels for SMEs to perform the various roles defined within the framework.

The framework defines the following roles for a team undertaking the development of enterprise architecture:

Architecture sponsor
Architecture board members
Chief/lead architects
Enterprise architect, business strategy architect, business architect, data architect, application architect, technology architect, integration and security architect
Program and project managers
Software designer

The framework also includes a number of tables matching roles with skills and proficiency levels within each skill category. A single table shows the definition of enterprise architecture skills by role.

Benefits of competency framework

The advantages of using the architecture skills framework are summarized as follows:

Reduced time, cost, and risk for the overall solution development
Reduced time and cost to set up architecture teams
Reduced time, cost, and risk in training hiring and managing architecture SMEs
Figure 3: Architecture competency framework

Summary

Individual passion is the primary driving factor that determines the growth path of an architect. For instance, a security architect who is passionate about the domain of IT security and must have developed an immensely valuable body of knowledge over time should ideally not be coerced into making a shift to a solution architect and eventually a governance role. There are at least three layers of architects:

Technologist: These roles have broad and narrow competencies in a specific technology or framework and are at the start of the value chain, for example, network architect, security architect, application architect, process architect, web architect, data architect.
T-shape: These roles have broad and deep competencies and are in the middle of the chain, for example, information architect, infrastructure architect, business architect or solution architect.
Governance: These roles on the top of value chain for, for example, lead architect, chief architect, enterprise architect or CTO

This progression is not for everyone, and importantly does not define the success or growth of an architect. This would be optimal for organizations to get creative about fostering career growth paths for each of these role buckets. At the end of the day, SMEs from across these pools need to work together effectively to define solutions. Well rounded individuals from these pools collaborating effectively are the recipe for success in an architecture focused solutions delivery organization. Instating creative and vertical growth paths within each of these pools would stand to benefit both the individuals and the organization.

Architects should be passionate about the work, whether it is being broad and deep in a specific technology area, or developing cross technology/functional breadth. The key is an architect understands the personal tradeoffs of each choice, for instance, a database architect considering a shift to a broader solutions architect role should be aware of the fact that developing a broader knowledge base of technology will become a higher priority to succeed in the role than continuing to go deep into architecting database solutions. The key consideration is to follow ones heart and passion, opportunities to grow and succeed in the domain will materialize over time.