How many Architects does it take to change a light bulb?
Posted by Doug Walters on 1st January 2014
After reading my article The problem with (too many) Project Managers a very good friend of mine, who is a Project Manager by trade, conceded that I had a point, but then continued with "but don't get me started on how many architects it takes to change a light bulb!" While I maintain that the IT world would be a better place if there were more good architects and they were given more influence, I must admit that the architecture fraternity seems hell-bent on undermining its own credibility.
My article on this website The problem with (too many) Project Managers articulates how I believe a Project Manager should contribute to conducting a change endeavour, and how many fall short, but after 36 years in IT, I would be extremely dim if I didn't recognise that project management plays an absolutely vital role in successful delivery of the end- product on time and to budget. My comments about the "cult of the project manager" are a tongue-in-cheek attempt to redress what I believe to be the imbalance that exists between the relative importance given to the project management and architecture roles.

I firmly believe that architecture is fundamental to the success of any endeavour of substance. Good architects ensure that assets and resources are used effectively and efficiently. In a business context, the architect is the most important role in the range of skills and experience required to deliver business benefit through change. How can you deliver a change if you don't have someone who can draw up the plans of what the end-product will look like, identify the components which comprise the end-product, and tell you the best way to implement and integrate those components?

It is unquestionable that the failure rate of change initiatives is unacceptable - my contention is that we need more good architects to address this.

Because I believe the above so passionately, I have been vociferous in my criticism of the "cult of the project manager" which prevails in many quarters, particularly in government and not-for-profit sectors. This "cult" suggests that the PM "owns" delivery of a solution and is the primary (sometimes only) point of contact for those commissioning the piece of work. It implies that an architect is a technical resource (i.e. a geek) who should remain in the background because he / she talks a different language and (because they are usually passionate about creating a quality end product) can't be trusted to toe the party (project) line about what is and isn't possible within current constraints.

Naturally, I don't believe this is correct, but I must admit that architects often do not do themselves any favours, and part of the problem is that there isn't any industry-standard definition of roles and titles within architecture, or a sensible prescription of the set of skills and experience required for the roles.

Let me give you a couple of examples; a couple of months ago I attended a trade event in London. As I took a seat after the nibbles recess, I overheard a neighbour say that he had just moved out of Account Management into Architecture. With some difficulty, I maintained decorum and good manners, and refrained from interrupting (I didn't even know this guy) to ask what qualifications he had to justify the title "architect." On reflection, this was probably wise, since I might have been embarrassed if the enquiry revealed that he was eminently qualified. However, experience has taught me that the most likely outcome would have been that he had no prior experience that remotely qualified him to provide architectural input to any issue.

My second example - a couple of years ago, I undertook a short assignment working with one of the world's largest and most respected IT companies. My role involved planning the virtualisation and migration of hundreds of windows server solutions for a blue-chip client, based not only on technical considerations but also factoring in business benefit and risk. Obviously, the first stage was a significant Discovery exercise, and I was leading a small team of Data Analysts who were tasked with completing (by various means) lots of questionnaires that I had compiled. Two of these analysts were "fast-track" management trainees newly-graduated from university courses in Computer Science. The second phase required complex scenario-modelling of possible migration approaches and therefore a different set of skills. To my dismay, these 2 trainees were re-branded "Solution Architects" (presumably for billing purposes) and assigned to tasks for which they were not equipped (guess who had to take up the slack?)

In both the examples given above, although I might be justified in my outrage, the people assuming the title of "architect" were not doing anything wrong - they were not perpetrating any misrepresentation. There isn't any industry-standard definition of roles and titles within architecture, or a sensible prescription of the set of skills and experience required for the roles.

TOGAF v9 makes a valiant attempt to address this industry-shortcoming in its Capability Reference Model. I'm pretty much in agreement with the titles listed in the Reference Model, and I can't fault the list of required skills and skill levels. The problem is that the Reference Model is just not practical as it stands. Like much of TOGAF, it is an academic or theoretical exposition of the ideal and it isn't really tempered by practicality.

To be fair, TOGAF expects the practicality to be supplied by the exponent, picking and choosing the tools and methods appropriate to the task from the menu provided by TOGAF.

However, many people mistakenly believe that simply achieving the TOGAF certification qualifies the proud owner to be called an architect, and that a practitioner requires the certification to be truly qualified as an architect.

My misgivings with the TOGAF approach is compounded by the method used to assess certification. Basically, the use of multiple choice questions significantly "dumbs-down" the assessment process - I know this to be true both through recent personal experience (in 2013 I passed a Microsoft MCP certification, based on Prometric's multiple-choice assessment technology) and through the research to which I was exposed while working for a professional accreditation provider who were looking to move to e-assessment.

I am aware of the contradiction in what I am saying – we need more architects, and yet I am denigrating a method by which we can recruit talent and give them a base from which they can start their journey as an architect?

My answer to the conundrum above:
- establish the principle that IT architecture is a trade, which must be learned and assessed through a mix of classroom and on-the-job training over a period of time
- agree a set of basic skills, qualifications and/or experience as pre-requisites for entry to the certification process
- include components in the certification process which ensure that the apprentice architect is proficient in one or more of the core IT Practitioner skills (e.g. Testing, Operations, Coding etc.)
- an assessment approach which places more focus on case studies and practical examples
- implement a formal system of mentoring which not only guides the trainee through the certification process, but also provides on the job feedback on performance that can be factored into the formal assessment
- create a "fast track" on-boarding process for experienced architects which gives recognition to their experience and skills, but still ensures that they are conversant with the methodology
- establish a regime of CPD for architects (too many who get to my decrepit stage of life refuse to regenerate their skills.)

I'd be very interested in any feedback on this; for a start, I'm well aware that the certification process is a significant money-spinner, and that the relationship between TOGAF and Prometric is very lucrative for both parties. That in itself is a major obstacle to change

blog comments powered by Disqus

Sign up for extra content

Register here to access premium content - the only information we require is your user name and a valid email address

Follow me

Latest private posts

Latest public posts

—1st July 2014
—18th April 2014
—9th April 2014