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.
I'm not sure how relevant my experience will be for your situation, but I'll pass on this anecdote as an example of at least historical value - adjust ingredients to your taste.
At one point in my career, I had to evaluate Java as a potential base language for a new software product family my company was planning to develop. It was early days for Java, so little was known about it in our developer community. Early days also made the Internet far from useful as an information source. We were a Microsoft C / Visual FoxPro shop at that time, but needed much better support for Internet communications than was easily found in those parishes. As well, the possibility of automated memory management was a blessing after our grossly drawn-out foray into C++ design and debugging on another project.
The company bought me one of the “Learn <Programming Language> in 24 Hours / 14 Days” style of books and I sat down at my desk Monday morning. With a paper notebook to one side, I started with Chapter 1 and just motored my way through, taking notes like I was in class and doing paper exercises where possible. We had no Java compiler yet, but the book was a useful hand-holder. In three working days I had finished the book, and was ready to discuss Java intelligently, program with it tentatively, and recommend it as a “possible” for our project.
We obtained the Java development environment and with the recent book-learning I was able to test-build some planned features from our new product quite quickly – far quicker than in C++, the nearest object-oriented equivalent we had experience with. But Java’s then-terrible run-time performance knocked it out of the competition and we ended up continuing with C++, incurring all the pain we already dreaded as well as shiny new pain when we got further into the depths of native Windows development.
The major point I wanted to make about the “Learn X in 24 Hours” book approach is that it made me a just-in-time Java expert for at least a few weeks. The instructional material was very well organized. Easy topics could be skipped (operator precedence), and hard ones pounded into submission (thread communications). The purpose of this style of book is to introduce every feature of the language, so when I finished I was up-to-date on the current state of the art, even though many of the items of knowledge were not useful afterwards (AWT and Swing, dang it!).
This benefit may apply to your situation by giving you an organized and rapid way to recap your existing knowledge of Java. You’ll be able to skip more than I did, as you have already been introduced to the language. But you’ll also be re-exposed to elements you may not have focused on the first time you learnt Java, perhaps programmatic control of garbage collection, RMI (remote method invocation), or servlets. Interview questions often lurk in the language’s darker corners, but you’ll be less likely to be caught flat-footed if you’ve worked through all the chapters recently.
Using the book, as opposed to getting pretty much the same information from the Internet, gives you a sequenced, tutorial-like stream of information. Nothing is under-explained, everything important is touched on, exercises help fix concepts in memory, and there are no kittens to look at. The fat book will appear daunting, but in my experience it’s just a few days work to push through one (on the corner of my desk, I have Java 8 In Action[1] awaiting the same push!). A second-hand programming-language book is also as cheap as a cup of coffee, and equally widely available – usually from the local charity store, where they pile up like last year’s unwanted fashion apparel, or from one of Amazon’s used-book vendors
I think the time / benefit quotient for the tutorial book approach is far better than for the “I’ll just fire up Google and learn the few things I need”. I recently had the experience of trying to evaluate Docker using the vast interwebs as an information source (four months of disorganized, part-time amusement) versus using a book, and the book won once again (four days of concentrated reading, and I’m far more effective at explaining and using Docker than I was after all that Googling).
I also concur with other posts here in pointing out that the books Effective Java[2] and Practical Java[3] are information-rich sources on nit-picky and gritty Java concerns. If I was going for an entry-level Java position and had to minimize my hours of preparation, I’d still go with the tutorial style of book for the low preparation time and broad coverage. But if I was going to interview for a more senior developer position, or face a room full of Google corporate interviewers, I’d grab Effective Java and spend a couple of weeks perfecting the hard stuff (probably do both if I had a couple of weeks, to be honest).
In the second case I’d also do some web research and find out what areas the hiring organization was focusing on. Once you find that you’re budgeting your interview prep time, it just seems smarter to buff what they’re going to look for, rather than be a broader but necessarily shallower “expert”.
I won’t bore you with details of competitor analysis and “web content indexing” here, but I suggest you may be surprised what you can find out about the hiring organization if you’re serious about impressing them. At a minimum, go through their other job postings (preferably over two or three recent years, not just what’s visible today) – you’ll be able to identify some or most of their technology stack and major systems by parsing the job ads.
If their line of business or current project is Java web sites, brush up on servlets and web frameworks (preferably the ones they favor). If they’re looking at big data, load your brain with Hadoop and Mahout (and a half-dozen more – it’s a burgeoning field). If they’re looking at distributed or high-availability systems, swallow a mug of hemlock. You can fill in the rest of this list with a little Googling after your competitor analysis.
I should finish by adding that the twenty-four hours spent learning Java wasn’t wasted, as it has turned out to be one of the last commercial programming languages I learned and needed. I used it prolifically for web service development, corporate data mangling, high-availability data centers, distributed systems, and (most recently) big data and the delicately-named “web indexing” industry. The years of C++ learning and toil finally petered out in the face of languages that were faster to develop in, yet produced safer and more “commercial” final products for desktop and server. Je ne regrette rien!
[1] Java 8 in Action: Lambdas, streams, and functional-style programming (2014) - Raoul-Gabriel Urma, Mario Fusco, Alan Mycroft
[2] Effective Java (2008) - Joshua Bloch
[3] Practical Java Programming Language Guide (2000) - Peter Haggar
I am not sure my loved ones would allow me to add 39,990 speakers to the already-intrusive 10 around the living room in order to achieve ambisonic excellence. I do not completely agree with them, although your suggested approach sounds like it might work better in the basement where I have more room and fewer shared furnishings to negotiate over. And though my days of ruling the clubs are far behind, I would gladly spend the night at one that offered rotating 3D sound fields, as you propose.
As for re-implementing the Behringer in code, I don’t think there are any significant technical barriers for a modern PC, or even a high-end mobile device. I have not used Pure Data, but if it’s adequately performant it looks like a fine platform from which to start.
My original plan was to execute the room response mapping with REW (Room Equalization Wizard) on my PC. Then I would hard-code a set of appropriate digital filters into a software plug-in that I could attach to a digital audio I/O board in a PC or equivalent. That filter system could run headless after that, since all the human interaction ends with REW.
The sorry part for my project was realizing I had (at least in part) to dedicate a general-purpose computer to a single minor use. I gave up designing this system in code when I knew I would it meant yet another little PC with suitable digital audio input / output hardware, built to sit up behind the television with all the other gear that gets turned on whenever a game, movie, or song is needed. But my weakness need not be your own.
More power to you in your future endeavors! I look forward to visiting your place once you've got your project up and running.
I understand this argument, but I choose to treat it lightly it in real life because I am mostly interested in the sound I get in my own living room with my own real equipment making sounds for my skeptical human ears. There is a large and creative cohort of audiophiles generating and repeating numerous claims about audio. I cannot really credit many of these claims because they cannot to be reproduced in blind ABX tests, much like the spirits of the departed or the spoon-benders of yore. In truth, the presence of a side-table for my refreshments has a far larger and more measurable effect on the sound I hear than many of the possibly apocryphal sonic indecencies of the electronic components in front of me.
To address your point directly, equalization (the feature of the Behringer DEQ 2496 I am using and discussing) does change the incoming signal, or it would not be a very useful audio component. My hands-on experience with oscilloscopes and digital audio analysis suites indicates that equalization does induce phase changes in the signal – you can see that by comparing input and output signals, or alternatively by doing the simple math that creates band equalization in the digital domain. These phase changes are pretty much unavoidable by-products of the audio filtering process, whether analog or digital.
Better ears than mine sometimes claim to hear the effects of phase retardation, and I can conceive of extreme situations where this might be plausible. Those with golden ears can test themselves by doing a controlled blind ABX test with a conventional EQ system (as I am led to understand the Behringer implements) and a linear-phase EQ system, and publish results from which we all may learn. But I cannot hear phase retardation effects with current audio equipment and I would be interested to see the blind ABX tests that showed them to exist at all in normal human hearing. Ethan Winer has addressed the real-world impact of phase shifting in high fidelity audio on several occasions – for example:
“More to the point, phase shift occurs naturally and unavoidably in all speakers and crossovers, and in every EQ circuit, with no obvious detriment as far as I can discern. Phase shift can be an important factor in speaker and crossover designs, but only because a tone whose frequency is near the crossover point is radiated by two speakers at once. In that case phase shift could cause the two acoustic outputs to partially cancel each other as they combine in the air in front of the speakers. But any time you stand in front of a loudspeaker and then simply take one step backward, you are inducing a large amount of phase shift at the higher frequencies.” [1]
As to the more general implication that the Behringer DEQ 2496 introduces distortion, specifically the kind of distortion I would hear and dislike, this claim may still be argued. I will say that I have not yet run the full suite of digital audio analytics on the signal coming out of the Behringer DEQ 2496, and it may (against the general practice and standards of commercial audio equipment) distort the heck out of the incoming gunshots, explosions, and piccolos. You cannot prove it by me, and if I live up to my responsibilities I will check the manufacturer’s specifications with a digital audio reference suite some quiet week in the future.
I would note, however, in case anyone else is concerned about the capacitors that may be magnifying harmonic distortion in the Behringer signal path, that its EQ process in my setup is conducted entirely in the digital domain, from SP/DIF digital input to TOSLink output. Only the infinitely delicate fingers of the Fourier transform and its ilk have touched those bits, and the reputedly foul influence of capacitors appears, if at all, downstream in the amplifier.
I recently bought the equipment to do a similar adaptive-audio job for my living room music / home-theater setup. I have the usual multi-decade collection of once-fashionable home stereo equipment, some in use, some collecting dust in the basement. I decided I needed a bit more bass to enjoy more thoroughly the gunshots and explosions of gameplay and epic action films.
I listened to a stereophile friend eager to give advice, and convinced myself to add a self-powered subwoofer to the existing setup. Adding one shook the house but (to my ear) muddied the sound of music when no explosions were taking place. I could blame the equipment, or more properly myself, and replace some or all of the former. But I thought there must be some way to modulate all this unruly gear so that it produced a provably balanced and pleasant sound.
I will skip over some intermediate steps where I tried to learn the science and engineering of acoustics, using a neutral reference microphone and several fine pieces of audio software available to all of us interwebbily. I learned that I was overdriving the subwoofer, which made sense, but I couldn’t seem to go from spectrum graphs and suchlike to an actual balanced sound system. My final setup worked out quite satisfactorily and is an affordable alternative to building the computer-driven speaker cluster for room modeling.
> I have been looking at the idea of doing lots of small speakers with microphones on them attached to a fat lump of computer hardware, that you stick all over and they bleep each other and build an acoustic model of the space they are in, then adjust for it properly.
When I played in a band, we had to work with the club’s sound engineer or bring our own to get a balanced sound setup before the audience showed up. The more recent gigs showcased an interesting technology, a system that generated pink noise through the actual sound system, from the original sound sources before the mixing board, all the way through power amplifiers to the speakers at front of house. The engineer put a reference microphone in a strategic position, turned on the pink noise generator, and twiddled equalizer knobs to get a roughly even spectrograph (plus unavoidable “sound-guy magic” to de-equalize somewhat for specific gig purposes like dancing or seated listening) for the whole room, using the actual speakers and sound-reinforcement equipment we would be using.
This seemed to me to be the thing I needed in my home theater setup. It would let me balance and compensate for the (now) ten speaker cabinets in the living room (including the powered subwoofer), their real-life positions, the walls and floor coverings, the furniture, and even the cat. I think I could also do it with some combo of REW (Room Equalization Wizard) software, reference mike, and pink noise streamed through the amplifier. But while I was trying to get that approach figured out, I found a cheap piece of audio hardware with all that functionality built-in – no need to dedicate a computer to EQing the sound.
This is the Behringer DEQ-2496, a configurable digital equalization gizmo. It has a room equalization function built in, which is a home version of the room-equalization setup we saw in the clubs, and as a bonus it basically automates the sound engineer’s fingers on the equalizer sliders. I am not sure if it’s the latest model supporting this function, as I got mine used, but it was well below $200 and probably the best money I’ve spent on pretending to be an audiophile.
You set up the room for your listening preference (for me, this involves rolling the softest armchair into the center of the room the best to enjoy all those gunshots and explosions), put the reference mike about where your head will be, activate the automated room EQ process on the DEQ-2496, and sit down in your regular seating position to read for a while. It sends pink noise through the power amplifier and speakers and starts modifying an equalization curve to produce a “flat” room signal across all audible frequencies.
After about 15-20 minutes the EQ settings stop changing and the Behringer has generated the EQ setup for acoustically-neutral room sound. You can save the setup and create others (e.g., for group seating), or modify it manually to match your preferences (bigger bass for film audio, slight high-frequency boost for classical music listening, etc.), and save the modified versions as well. All my digital sound sources pass through it (game consoles, video, and music) in digital format and are equalized before they hit the amplifier and speakers – just as it worked in the clubs.
There are usable reference materials on the web to make up for the DEQ-2496’s obtuse user interface and execrable user manual. It’s not quite the super-flexible software-driven system I might have gravitated toward, but it does what I needed without tying up a computer.
What I like most is that it deals with the real world sound of my setup and room – if I change my setup or furnishings (as has happened a couple of times), I just re-run the balancing process and use the new settings as the baseline for my preferred room EQ. If my subwoofer, say, is turned too high the Behringer sets up a balancing cut in the affected frequencies. If the carpet soaks up some high-frequency signals, they’re boosted to compensate.
If my audiophile buddy gushes about the spectacularly flat frequency response of some new bookshelf system, I relax knowing that even my second-hand and slightly dinged-up speakers have been magically upgraded to subjectively flat (or not, as I wish) frequency responses – in the real world of my living room, not just in the lab or the store. It even has a full panel display of das blinkenlites should I need confirmation things are working properly. Very satisfying!
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.