Electronic Cash News @

How does someone become qualified to be a senior information technologist (architect, senior project manager, principal, and so on)? Or are these titles given out fairly liberally with no real standard of what the title signifies or what that person can do? From what I can see these titles are fairly arbitrary where the only common denominator is the number of years (usually 7 - 15 years) of experience the person has in the information technology field. This is not the case in other technical fields such as civil engineering or medical field. If someone is a doctor, it can be assumed that person can do their job in their particular medical specialty.

Who is really qualified to architect your systems?

Qualifying senior information technologists is a critical issue. Over the years, I have seen many IT projects fail or go on-and-on that have caused large companies to fail. On the other hand, I have seen many companies succeed because they had talented, experienced people creating great IT systems that added extreme value to the business.

People hold many important titles with the word architect, senior IT project manager, and principal, but can they do the job? They may be qualified or not. It is hard to tell. Even if they deserve the title, can they perform in that given specialty? With IT getting so broad and specialized, an architect can be asked to architect something they do not know how to architect. This is like asking a dentist to do heart surgery.

Has IT relied too much on tools, training certifications, and methodologies to create great technologists? For architects, senior project managers, principals, and other types of senior information technologists, there is a dire need for an apprenticeship program. Seems like there is a need for an internship program for information technologists much like doctors have to go through after they complete medical school.

Another question is where is academia on this? I may be out of the loop, but I do not know of any universities that are addressing this issue of training senior information technologists to solve real-world business problems. Seems like most universities that excel in IT are focused on basic research and applied research, and not on IT architecture and real-world solutions.

See The Tech Evangelist’s posting, Architecture Frameworks Don’t Make Architects on the downfalls of tools and methodologies in making great IT architects.

The business case for consolidating IT functions from several business units is fairly easy to justify in terms of reduced labor, hardware, software, and maintenance costs. The question is - will there be improved service levels after the consolidation? On paper, at least, IT service levels should improve due to the increase depth of consolidate technical expertise and economies of scale.

On the other hand, there are many challenges with consolidating IT functions. The key challenges are with business units losing flexibility, creating a good IT service level agreement (SLA), and the new IT group meeting / exceeding the requirements of the SLA.

I have come in on the tail-end of an internal IT consolidation where no one thought there was a need to have a formal SLA between the new IT business unit and the other company’s business units. We ended up having to setup a new SLA, and then bring many of the IT functions back in-house because the separate IT business unit could not meet the terms of the SLA. Just like with any business contract, a good service level agreement for IT services sets everyone up for success.