Marc Adler, CTO as a Service
The following observations about the role of Chief Architect come from my four previous positions as Chief Architect. I have been Chief Architect of the Equities Division of Citigroup (350,000 in the company, 30,000 people in Equities), of MetLife (65,000 employees), ADP (65,000 employees), and of a small software vendor named Quantifi (roughly 50 employees). I have a mixture of large company and small company experience that has shaped my perceptions. In addition, I owned my own small software business for roughly ten years, and that experience has also shaped my thinking.
I may be slightly biased in my thinking, but in my opinion, the role of Chief Architect is one of the hardest roles out there, both in terms of defining the role and in terms of what is expected of you. Each company has their own idea of what a Chief Architect’s role is, and some companies don’t even know why they need a Chief Architect.
The role of Chief Architect is an extremely “vertical” one. I always like to say that a Chief Architect has to be able to interact at the CxO level, and be able to talk to the lowest-level coder. The Chief Architect has to be comfortable in executive-level meetings, and must be equally comfortable sitting next to a developer and doing pair-programming or code reviews. Often times, the Chief Architect is called on to explain technology to the CxO-level people. The Chief Architect is often called on to face off with the senior-level technical people at vendors and partners. I have been directly opposite CIOs and CTOs of vendors on many occasions. The Chief Architect should know the business and well as the technology.
In my opinion, there should really be only a single Chief Architect in a division or an enterprise. There should be a single point from where all architectural decisions are made. This jives with the list of responsibilities that a Chief Architect should have (see the list below). If there are multiple Chief Architects, then there is more room for disagreements and to get into “analysis paralysis” mode.
Management
Many times, the Chief Architect has to manage a team of architects. At Citigroup and MetLife, I managed multiple groups which fell under the Architecture organization, and these groups included performance optimization engineers, project managers, and business analysts.
Since I have typically managed teams of architects, I have had to slice my architects into different domains. For example, at Citigroup, I had an architect responsible for Cash Trading Systems, an architect responsible for Derivatives Trading, an architect responsible for Risk, etc. I also had architects devoted to SDLC, architects devotes to performance optimization, etc. Each architect was responsible for a vertical slice of the entire organization, but the architects had to work horizontally as well.
Since the Chief Architect was regarded as a senior or area manager, the Chief Architect often reported to the CIO or CTO of a division. The Chief Architect would often be the CxO’s “right-hand man” when it came to technology. It was unimaginable that a Chief Architect would report to a development manager, since part of the architect’s responsibility was guiding development practices and doing architecture and code reviews (something that would sometimes put the development manager and architect at odds).
Hands-On Participation
A constant question revolves around how hands-on the Chief Architect should be. I advocate for a hands-on architect for various reasons.
The Chief Architect should not be known as a “yellow pad architect” if the CA is to get the respect of the development organization. The developers want to know that the Chief Architect has walked in their shoes before they accept his advice. A Chief Architect should be able to speak to any CxO or sit down and pair-program with the lowest-level developer.
Since the Chief Architect is also responsible for exploring new technologies and delivering proof-of-concepts, the Chief Architect should be able to code these POCs personally.
Therefore, I strongly advocate that the role of Chief Architect not prohibit the CA from diving into a coding role on occasions.
Roles and Responsibilities
The list below is a union of all of the responsibilities that I have had as Chief Architect.
- Manage the Architecture Organization
- Attend meetings with current and potential vendors
- Be able to face off with the CTO or Chief Architect of a vendor and do technical vetting
- Evaluate vendors and technology using an Architecture-team-developed scorecard
- Keep abreast of new technologies that might be beneficial to the organization
- Run the Innovation Lab
- Meet with vendors
- Do proof-of-concepts, often involving coding from me or a member of my architecture team
- Attend industry conferences in order to be able to see what new technologies are hot, and to even see what our competitors are doing.
- Occasionally give talks or sit on panels at conferences
- Software development
- Sometimes, the architecture organization will develop a POC or MVP in order to prove out ideas or to relieve pressure on the normal development organization
- Give architectural approval for “big ticket” projects
- Attend executive meetings
- Often called on to decipher technology or render opinions on technology
- Liaise directly with senior business stakeholders
- Find out what kinds of business problems the stakeholders wanted to solve and propose solutions based on their needs
- Guidance
- Come up with reference architectures
- Serve as a general technical resource for the development organization
- Roadmaps
- Provide roadmaps that show how the organization will move towards a certain future state
- SDLC process
- Do Architecture and Code Reviews
- Attend Sprint kickoff and retrospectives
- Provide approvals for code to be deployed into production
- Advice on coding practices
- Performance Optimization
- Help the engineering team with the optimization of certain systems
- Governance
- Ensure that the organization is using the appropriate technology and software
- Ensure that the organization is not using End-of-Life software
- Architecture Review Boards
- Run or participate in architecture reviews and approvals
- Socialization of architecture across the enterprise
- In the instances where I have been CA of a specific division, I would make the effort to find out what other CAs in other divisions were up to