Posts Tagged ‘IT’

IT High Priests and the Lost Art of IT Innovation

Wednesday, July 22nd, 2009

The High Priests of IT.

IT management can so easily get into a rut when it comes to IT innovation. I am sure that most people that get into the information technology field have a great desire to innovate. As the years go by innovation seems to become their lost love. This especially happens in IT management.

The High Priest of IT - a religion that shuns IT innovation

The High Priest of IT

A religion that shuns IT innovation.


IT High Priests – a Religion of Governance and Cost Management. There is something about being in IT management that it becomes so easy to forget about innovation and just start managing your costs and infrastructure. Instead of being innovators, IT management become High Priests. Their religion becomes governance, standards, infrastructure, information security, and Return On Investment (ROI).

The Heretics – Super Users and Supper Geeks. Innovation seems to go against all of the tenets of managing IT. The people that even show a glimmer of innovation, the “super users” and the “super geeks”, are the heretics to the High Priests of IT. See Cory Doctorow posting on The High Priests of IT — And the Heretics for more on the High Priests of IT and the Heretics.

IT As Engineers That Innovate, Build, and Maintain Systems.

IT as Engineers. I am a big believer that IT is not a cost center, and that they should be thought of as engineers that innovate, build, and maintain systems. It is so easy to get into a rut where business and IT both buy into the notion that IT managers are just IT High Priests that maintain the systems and manage the costs. Yes, IT needs to maintain systems and have policies in place that maintain standards and security. At the same time, a significant objective of IT must be to innovate, re-event itself, and build new and better solutions that meet future business requirements.

The Need for an Innovation Dialog Between Business and IT. Business and IT both must challenge the notion of IT management just being the High Priests of IT. Without innovation coming within the IT organization, business users will go outside the IT organization to find IT solutions that meet their current business problems. This becomes a disjointed way to introduce new information technology into the organization, but may be the only way to innovate when the organization has a High Priest of IT. A worst scenario is when neither IT nor the business users will shepherd in new IT innovations into the business. If this IT innovation stalemate continues, the competition will eventually increase market share through their IT innovations. Business users and IT need to maintain a dialog and take action to continue to innovate in IT. See Adrian Gonzalez’s posting, Can Logistics and IT Eat Lunch Together? on the need for IT and business users to do a better job of communicating with each other.

Do the IT Titles Architect and Principal Mean Anything?

Saturday, July 4th, 2009

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.

Layers of the Enterprise Architecture

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.

SLAs – Consolidating IT Functions Across Business Units

Saturday, March 8th, 2008

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.