The Technology Architect Organization Quiz is a brief set of questions you should ask a potential employer during the interview. In fact, you should always ask informed questions, after all that is a huge component of an architects job. Getting a good idea of how a company views, structures, enables architecture is important as there is significant variety. In some companies architects are looked to as strategic gurus, technology experts, but in others simply quality and design draftsmen, or worse Ivory Tower babblers. The variety is compounded as there are differences between industries and between Europe and the US. I have been refining the Technology Architect Organization Quiz for several weeks which and it is in the spirit of
The Joel Test by Joel Spolsky. I highly recommend checking out
The Joel Test as it succinctly provides a good measure for development maturity while remaining simple yes or no questions. I hope the Technology Architect Organization Quiz is just as simple and obvious. The quiz questions and discussion are more software and application architect focused, but should generally apply to infrastructure, business, enterprise architecture as well.
1. Are architects engaged in strategy and annual planning/budgeting activities?
2. Do developers/engineers within the company want to be architects?
3. How many leaders are between the most senior architect and the CIO/CTO?
4. What is the architect's career path within the company?
5. Does Architecture have regular weekly meetings?
6. Do architects write code, review code, create proof-of-concepts?
7. Is there a defined/followed architecture governance process?
Bonus. The Joel Test Score?
1. Are architects engaged in strategy and annual planning/budgeting activities?
A positive answer is critical to your success as an architect within their company. There are two major reasons architects must be involved in both strategy and annual planning. First, simply put the longer a project or initiative goes without architecture visibility the more difficult it will be to guide, help, find efficiencies, etc. Companies often fund what appear to be distinct and separate business initiatives but in fact from a technical perspective have huge overlap, affinity, re-use, interdependencies. Early plans and strategies can be likened to icebergs. Icebergs after all remain about 87% below the surface. Despite only seeing the tip of the iceberg staff structures/workloads and all sorts of hard to change implications can solidify during the strategy and planning meetings. Architecture must influence before foundation hardens and becomes immovable. Second, architecture organizations should be providing their own ideas, initiatives, and roadmaps for consideration. Realistically many great architectural improvements often do not lineup directly with immediate business needs/funding. Architecture should be submitting proposals and expect to participate early in the process.
2. Do developers/engineers within the company want to be architects?
Architect roles should be a desirable advancement opportunity for a developer/engineer. Architects within the organization should be respected, enabled, trusted, and as such have senior positions. A related question might be: Are many current architects respected past developers? If developers don't what the job, why not? It could be a sign that developers don't respect the current architects or that architecture is not well accepted/adopted. Perhaps the developers and delivery teams have all the real control, feely ignore architecture, or architects are viewed as non-technical overhead. There could be any number of reasons and all of them are significant warning signs.
3. How many leaders are between the most senior architect and the CIO/CTO?
Architects typically require a separate chain of command for support, escalation, and engagement. Also simple measure of value/importance is how connected to the CIO/CTO is architecture? If all the architects within a company are four levels removed from the executive leader it will almost certainly limit influence, exposure, and budget. Will delivery focused managers support architects that often have different priorities and potentially conflicting recommendations? Architectural maturity must be supported, understood, demanded from at the top. How else can architects be expected to contribute cross-organizational ideas, improvements, paradigm shifts, process changes, and multi-year strategies? While nothing is impossible and there are great supportive non-architect leaders often there is no substitute for direct architecture path to executive leadership.
4. What is the architect's career path within the company?
You want to join an architecture organization that is viewed as the 'rock stars' and 'leadership material' within the company. Who doesn't want to know that there are advancement opportunities? This can also provide a window into what peers and leaders expect of architects. It can help you understand if architects are truly consulted/engaged, respected, and valued by peers and leaders. It is easier to get ahead if architecture is critical to success and engaged on large initiatives. If architects aren't promoted who is?
5. Does Architecture have regular weekly meetings?
This question should help you understand if there is an architecture culture at the company. It is hard to maintain any consistent organizational/practitioner culture if you are not meeting frequently with peer and leader architects. There may in fact be no real architecture organization, just embedded architects that only take direction from delivery managers. While this might be fine in some cases, it most certainly would limit architecture success and progression. How do you get leadership exposure or support combat cost and schedule blinders? Will your accomplishments only be valued by one delivery leader? Would such a leader be mature enough to respect that you cannot do your job if you always agree with them?
6. Do architects write code, review code, create proof-of-concepts?
A healthy architecture organization that is grown and respected from experienced developers and engineers will thus be composed of active programmers/practitioners. Architects need not always code, but having a sharp relevant (coding) tool set is critical to success. Architects must be able to understand the systems and technology environment using primary sources, such as code, XML, scripts, etc. Without practitioner skills architecture must rely on developers. Moreover a non-technical architect will remain removed from the solution domain and unable to step-in and lead by example, create a proof of concept, learn about the system directly, or even help review quality. It is not enough for a technical architect (there are other less technical architecture roles) to have not programmed within the last 3 years.
7. Is there a defined/followed architecture governance process?
In large enterprises the projects need to have scheduled reviews, period. It should be part of the standard project plan and start-up process. The format is not as critical who attends and the timing. The governance meetings/reviews provide critical opportunities to influence, call in leader support, raise awareness, set expectations, and build consensus. The right mix of technical and execution focused leaders must be present to help drive commitment. Without these agreed upon check points project teams can let cost and schedule drive decisions requiring more than just an email to adopt a strategic alternative. These reviews provide checkpoints which reduce last-minute meetings, firefighting, and the feeling that architects are escalating all the time.
Bonus. How does the company/group score on The Joel Test?
Architects depend on and can be at the mercy of the quality of applications and systems. Those systems must be maintainable, mature, reasonable to change, and re-useable.
The Joel Test seems like a reasonable way to measure that. Make sure to account for the type of company and how they use/leverage technology. The score should be higher for a software development or technology company than a traditional retailer or shipping company. Just as with other questions a challenge can be an opportunity for an architect/leader given support to make improvements. However in more junior roles your great ideas and own coding skills might be no match for the chaos and disorder of poorly developed and unmaintainable systems/processes.
How should a company score?
There is no right score or recommendation. Obviously, the more correct/positive the better, but a low score might signal a tremendous opportunity. Maybe they are creating a new architecture function or re-investing in technology staff. If you are an architect that thrives on challenges and improving processes, standards, etc, a low scoring organization with the right executive support might be a career defining challenge. Ask these questions or similar ones to set yourself apart from the other candidates. If they don't like you asking questions then you certainly do not want to work there.
Comments