IT is About the People!
On thing I have found in the world, is that people are necessary. People are the root cause in everything we do. They are why we go to work. They are why we come home from work. Heck, we encounter many of them on the way to work --some of them not so nice!
In the IT world, they are the doers. However it is important to understand the basic concepts in managing them. What is a technical person? Ask around and you will get answers ranging from, someone who can make their iPod work, works on the helpdesk, performs desktop support, defines IT rules and governance, IT Security personnel, System Administrators and System Engineers/Network Engineers. The list is tremendous.
So why am I talking about this? Well how many times has your email gone down or blackberry acted up? Was it the machine or its software that failed? In most cases it the problem can be traced back to a person. The person didn't design the system with your needs in mind, or something as simple as not checking the system's logs to identify a potential problem. Often this happens because the wrong person was put in the wrong job. "Oh he is technical, he can make his iPod download music from iTunes!" "Oh she knows computers she is on the helpdesk!" Here is where the problem lies --both with IT managers and non IT managers.
This problem is very complex, even when staffing your IT organization. Management needs to know the difference between the iPod guy, the Administrator, the Engineer, and the Architect --never mind what a senior level employee is [in their respected area].
The biggest focus should be on the Architect; an Architect needs to be business savvy and must know all facets of IT (Systems and Infrastructure). The Architect should have an undergraduate degree in Computer Science, or Management Information Systems and a Masters degree in IT Management or an MBA with a focus on technology. Architects work hand in hand with the CIO to define the Enterprise Architecture and align the various IT groups to it.
Next we have the Engineer, be it Systems or Network. This person should be a seasoned IT veteran. They should approach every requirement or problem with a "YES WE CAN" attitude. They have no fear of engaging vendors or other Engineers while researching a project. They are proactive versus reactive. They use MS Project versus a helpdesk ticketing system to manage tasks. This is the kind of person who takes the TV apart to see how it works. They need to know how their products work versus simply knowing how to operate them. They should have an undergrad degree in Management Information Systems or Computer Science. Additionally they should hold current certifications in their product(s) (MSCE, MCSD, CCIE, CISSP, and etc). Certs are not the end all, however they compliment a degree and the keep engineer's skills up todate.
Lastly we have the Administrator, they are like the power users --they keep the lights going. They should exist on the helpdesk and/or provide onsite support. They should not be confused with engineers. However they can become one; provided they set goals (education and experience related) and accomplish these goals. Generally they understand how a system should work in ideal conditions, they do not know what is under the hood. They should hold certifications in the systems they support (MCSA, CCNA, and etc). No degree is required, however encouraged for corporate growth.
Now that I have explained my views on the Administrator, Engineer, and the Architect, I will define how to identify them. In the IT world, we have Administrators selling themselves off as Sr. Engineers. Guess what --they get hired for the job. This becomes a problem when the CIO tries to encourage the Engineers into thinking outside the box –an Administrator can not do this. They can't because they don't understand what is in the box --they just know that a box is a square. That is why their answer to a problem is to reboot, an Engineer will reboot and then he or she will find the root cause. Furthermore when an Engineer designs a system, they ensure unplanned reboots/downtime will not occur. An Engineer's main focus should be on uptime, and how to make systems run as close to 100% as possible.
The above holds true when an Engineer tries out for Architect position. An Architect sees the big picture because they have played in many boxes --i.e. they wore many hats. An Engineer who only knows Systems (programmer/DBA) or Infrastructures (Servers, routers, cables) cannot fit the bill as an Architect. However, they can cross train and meet the educational requirements , set a goal ,or list of goals, to become an Architect.
The above is very important [to me] because in order to build a World Class IT organization, you have to build the foundation. That foundation is the people. Put the right people in the right job. [Then] Design the overall architecture and align it to your people and your business.
My two cents!
In the IT world, they are the doers. However it is important to understand the basic concepts in managing them. What is a technical person? Ask around and you will get answers ranging from, someone who can make their iPod work, works on the helpdesk, performs desktop support, defines IT rules and governance, IT Security personnel, System Administrators and System Engineers/Network Engineers. The list is tremendous.
So why am I talking about this? Well how many times has your email gone down or blackberry acted up? Was it the machine or its software that failed? In most cases it the problem can be traced back to a person. The person didn't design the system with your needs in mind, or something as simple as not checking the system's logs to identify a potential problem. Often this happens because the wrong person was put in the wrong job. "Oh he is technical, he can make his iPod download music from iTunes!" "Oh she knows computers she is on the helpdesk!" Here is where the problem lies --both with IT managers and non IT managers.
This problem is very complex, even when staffing your IT organization. Management needs to know the difference between the iPod guy, the Administrator, the Engineer, and the Architect --never mind what a senior level employee is [in their respected area].
The biggest focus should be on the Architect; an Architect needs to be business savvy and must know all facets of IT (Systems and Infrastructure). The Architect should have an undergraduate degree in Computer Science, or Management Information Systems and a Masters degree in IT Management or an MBA with a focus on technology. Architects work hand in hand with the CIO to define the Enterprise Architecture and align the various IT groups to it.
Next we have the Engineer, be it Systems or Network. This person should be a seasoned IT veteran. They should approach every requirement or problem with a "YES WE CAN" attitude. They have no fear of engaging vendors or other Engineers while researching a project. They are proactive versus reactive. They use MS Project versus a helpdesk ticketing system to manage tasks. This is the kind of person who takes the TV apart to see how it works. They need to know how their products work versus simply knowing how to operate them. They should have an undergrad degree in Management Information Systems or Computer Science. Additionally they should hold current certifications in their product(s) (MSCE, MCSD, CCIE, CISSP, and etc). Certs are not the end all, however they compliment a degree and the keep engineer's skills up todate.
Lastly we have the Administrator, they are like the power users --they keep the lights going. They should exist on the helpdesk and/or provide onsite support. They should not be confused with engineers. However they can become one; provided they set goals (education and experience related) and accomplish these goals. Generally they understand how a system should work in ideal conditions, they do not know what is under the hood. They should hold certifications in the systems they support (MCSA, CCNA, and etc). No degree is required, however encouraged for corporate growth.
Now that I have explained my views on the Administrator, Engineer, and the Architect, I will define how to identify them. In the IT world, we have Administrators selling themselves off as Sr. Engineers. Guess what --they get hired for the job. This becomes a problem when the CIO tries to encourage the Engineers into thinking outside the box –an Administrator can not do this. They can't because they don't understand what is in the box --they just know that a box is a square. That is why their answer to a problem is to reboot, an Engineer will reboot and then he or she will find the root cause. Furthermore when an Engineer designs a system, they ensure unplanned reboots/downtime will not occur. An Engineer's main focus should be on uptime, and how to make systems run as close to 100% as possible.
The above holds true when an Engineer tries out for Architect position. An Architect sees the big picture because they have played in many boxes --i.e. they wore many hats. An Engineer who only knows Systems (programmer/DBA) or Infrastructures (Servers, routers, cables) cannot fit the bill as an Architect. However, they can cross train and meet the educational requirements , set a goal ,or list of goals, to become an Architect.
The above is very important [to me] because in order to build a World Class IT organization, you have to build the foundation. That foundation is the people. Put the right people in the right job. [Then] Design the overall architecture and align it to your people and your business.
My two cents!
Comments
Yes, in my opinion, to become an effective architect, you need a background in administration and engineering. My reasoning is that you need an understanding of the people (administrator) and the Technology (engineering) roles –having a well rounded background will make your decision process easier. Your MS-IST degree is granted from the School of Business and you will see a business flare in regards to your tech classes. Good luck with the program!