I've recently done a survey of job listings, titles, and the skills and experience levels associated with the term “architect” for the North America corporate IT marketplace. I drew the general definition of an IT architect’s roles and responsibilities partly from major Enterprise Architecture frameworks (e.g., TOGAF, FEAF, and DODAF) and partly from the survey of architect job postings on popular employment websites (e.g., Monster, Dice).
This material is “enterprise”-y and may not describe some of the more advanced IT businesses out there, like Google or Facebook. But before I did the research and write-up, I was quite ignorant about some of the wider uses of the term, and I did not have much clarity on what separated an architect from (say) a project manager or product representative.
Seeing hundreds of job descriptions and trying to map out what companies and recruiters were looking for was quite eye-opening. These descriptions may contribute some useful knowledge or terminology to others in their career planning or job hunting. I would like to think they represent current IT best practices, organized, simplified, and given consistent terminology and definitions. But the title “architect” in IT is not yet usefully standardized, and there’s lots of room for alternative viewpoints.
IT architect roles, skills, and experience
The title of “architect” identifies someone with extensive experience in one or more IT knowledge and practice domains (as I define them below). The most junior architect role builds on at least ten years of progressive, non-management design and delivery experience in a basic IT domain. A more senior architect shows similar progressive experience but more of it, and in more than one IT domain.
Note: Title inflation may be weakening the concepts of seniority and specialization we used to associate with the IT architect role. Just as a startup with a few dozen employees may end up with numerous staff titled “Vice President”, some smaller IT environments give the title “architect” to several of the IT team without necessarily requiring lengthy experience or depth of knowledge. For example, in many job listings the title “Solution Architect” describes a (junior, three-year) technical sales-support role, not a senior IT architect role as it might be generally understood.
The IT domains
For our purposes, there are five core domains of enterprise IT practice and knowledge. Each domain has an equivalent architect role:
1. Business. A business can be described as processes and groups of processes. Business architects analyze and document these processes and relationships to help optimize them for flexibility, efficiency, and performance.
2. Data. The data architect deals with the stable, long-term structure of data of interest to the enterprise, and with the technologies that deliver value in data storage and retrieval.
3. Technology. Applications and data reside on a complex and evolving technical infrastructure, which the technology architects design and implement.
4. Application. Application architects are the senior representatives of the programming trade, experienced enough to support successful application design, development, integration, and delivery.
5. Security. A newer entry to enterprise architecture, the security architect designs and oversees the implementation of corporate information security.
Apprenticeship roles
Every domain has one or more apprenticeship roles for individuals likely to become architects. For example:
1. Business: business analyst --> business architect
2. Data: database administrator --> data analyst --> data architect
3. Technology: system admin --> infrastructure analyst --> technology architect
4. Application: software developer --> developer-analyst --> application architect
5. Security: network security analyst --> security architect
There are many more paths than these, and some of these may become uncommon or obsolete as the roles continue to evolve. Future architects often follow paths in two or more domains, for example, both the data and the application domains for n-tier client-server developers, or application and technology domains for web developers.
Senior architect roles
The most senior architects are not tied to specific IT domains. For their work to be valuable, they must have a strong knowledge of all IT domains, and extensive, progressive working experience in two or more domains. The most common titles for these roles are:
A. Solution Architect: expert in two or more domains, and senior to single-domain architects
B. Enterprise Architect: senior to all other IT architects in the enterprise
Note that the terminology for architects at this level of seniority is not very consistent at present in the industry. In particular, “solution architect” is a synonym for “application architect” in some markets. As well, the term “enterprise architect” is sometimes applied to any IT designer above a certain level of seniority, even if their experience has been in a single domain and they have no claim to senior-level knowledge or skills across the full collection of enterprise IT domains.
Nature of IT architecture practice
We don’t use “architecture” in the world of information technology as we do in the design and construction of buildings or other structures, where the term originated. In building physical structures, architecture is the initial step that elicits user (owner) requirements and attempts to meet them with one or more initial designs. A design will contain enough information to support project risk analysis, costing, and local zoning or equivalent review. When the design has been accepted, the architect is generally finished and other professions or trades come to the forefront of project decision-making.
IT systems and technology architecture works with extremely malleable but less predictable materials, processes, and staff roles. As a result, IT architects have far more freedom in design, but less certainty in the costs and risks of the resulting product.
As a result, the IT architect tends to be involved in a greater number of decisions for an IT project, may have made important decisions even before the project started (e.g., regarding corporate IT standards, development methodology, infrastructure technologies, etc.), and may influence IT development or delivery processes as well as detailed product and service design. The IT architect’s role is broader in scope and longer in duration than common for the architect role in construction.
In general, IT architects work with corporate business requirements and major project requirements as input, producing general enterprise IT standards and custom IT designs as output. Good architects are familiar with multiple means of achieving IT goals, including multiple basic computing platforms, multiple development methodologies, multiple product delivery architectures, IT design patterns, design and delivery tools, academic resources, and other contributors to flexible, intelligent decision-making and design.
Rather than producing architectural models and sketches to be implemented and then walking away to leave development and project handover to a subsequent team of engineers, IT architects define the overall IT delivery environment, do initial designs, select or define technical standards, and may even take lead engineer roles in one or phases of a delivery project. In short, the IT architect role overlaps with detailed systems engineering. This attention to both concept and detail helps overcome the problems of working with an insubstantial construction material like software, keeping the experienced designers in touch with a project and its technologies until all significant technical risks have been recognized and overcome.
Differences from other IT roles
The IT architect roles do not imply supervision or management responsibilities. Like the corporate lawyers or financial investment team, the architects are valued for their knowledge and resulting contributions to corporate goals. They typically do not take supervisory or management roles, as these do not require the specialized technical knowledge and skills for which the architects are retained.
Within IT departments, therefore, there exists a line of seniority for management that is separate from the line containing architects. Staff development for IT management generally follows a path from team lead on technical projects, to project management, to portfolio management (overseeing multiple projects, each with its own project manager) for a business unit or other organizational group.
IT managers generally keep up with the broad march of progress in the technology domains for which they are responsible, but do not remain active practitioners once they reach middle or senior management. IT architects, by contrast, remain active practitioners to develop and maintain the deep knowledge and skills associated with the title of “architect”.
I hope I haven't muddied the water too much with these thoughts. I don't claim any special insight here, and I think there is space (which is actively under exploration and colonization) for much deeper thought and more rigorous conclusions about the IT architect role, title, and qualifications. I'd be particularly interested to hear the current state of the art in Europe and Asia, if anyone has knowledge from these areas.