Unix Enterprise by Harris Kern

The most common IT organizational problems, continued

Last month, we listed the basic complications -- here we break down the IT organizational structure layer by layer and delve further into the responsibilities of each group and tell you why conflicts often crop up

SunWorld
December  1997
[Next story]
[Table of Contents]
[Search]
Sun's Site
Abstract
In this continuation of last month's column on the most common IT organizational problems, we analyze the functional groups within IT and consider the potential conflicts that may arise when responsibilities become blurred. (1,700 words)


Mail this
article to
a friend
In further examining the most common operational problems within IT, we should start by showing you the top layer of the IT organizational structure and work our way down.


Applications Development hasn't changed too much over the years except for the fact that systems are being developed and deployed at a much quicker pace. In the 90s the Architecture and Planning function was born and developed with some bumps and bruises along the way, but it's still around. Enterprise Services is your global support group. Most of the issues discussed last month are directly related to the Architecture/Planning and Enterprise Services functions.

The Architecture and Planning group will work just fine if they keep to their original functional responsibilities. This means keeping one ear to the business, one ear to the customer, one ear to IT, and one ear to the competition. This function is important to IT's success, but it cannot lose sight of why it exists. In most shops we visit this function needs to be reengineered mainly because of the problems highlighted in last month's article.

Advertisements

Enterprise Services
Now let's take a look at where most of the money gets spent for IT. It's the operational support arm of IT -- what I like to call Enterprise Services.


Let's start with the boss -- there should be only one global general. If you are a global company you cannot have multiple bosses -- one for each region or territory. So many companies have a support boss for Asia, one for Europe, and one for the Americas. They all report to the CIO. This is a huge mistake. With the duplication of efforts everywhere and no one adhering to corporate standards, politics will run rampant. Your infrastructure costs will double because everyone will do whatever is necessary to make their customers happy. They rarely look at the entire picture and don't count on the CIO to keep their generals in line -- they are too busy politicing and getting those new systems deployed as quickly as possible in order to meet business requirements. If you must organize by region or territory due to the size of the organization then each area should have a lieutenant general reporting to the infrastructure general, and not to the CIO.

Applications Support
In most shops this function resides within Applications Development because it's pretty difficult to get programmers to do a not-so-pleasant job like support. But if you can put together such an organization that can do minor development and enhancements and provide support your company will be better off because your hardcore programmers won't have any excuses to get those systems out on time.

Operations
Operations is still Operations. Nothing really changes here. This is the traditional glass house support with onsite 24X7 computer operator coverage. Your goal should be to have a minimal operations staff, and their main function shouldn't be monitoring systems. Systems should be monitored via tools first (e.g., SunNet Manager or HP OpenView). The tools should automatically page the appropriate staff. Operators function as tape librarians -- this position will always be required along with print distribution clerks. They should provide hardware support/assistance to System Administration and Production Control. Their career path should flow into Production Control.

Technical Support
Technical Support is your bread and butter for building your new streamlined heterogeneous infrastructure. Remember how you relied so heavily on your system programmers and database administrators in the mainframe years? Well, there's no difference today. They're the ones that will implement the processes and system and database management tools, and they will keep those databases and operating systems humming like finely tuned race engines.

They're also the ones that will architect an efficient and cost-effective infrastructure with as much automation as possible. But don't expect to implement a truly "lights-out" environment. In our third book, Networking the New Enterprise, we actually define what "lights out" could potentially be, but it's really time to put this fallacy to bed once and for all. There really is no such thing as "lights out," but you can get pretty close. If they had the time they could build scripts to help monitor and automate many of the manual processes used today in production environments. With this in mind, we'll say it one more time. You've got to give your system administrators or system programmers and database administrators the time to do this stuff. Unfortunately, in most of the shops we visit the nature is reactive vs. proactive.

The cry is for more resources. Ok, in many of the shops this cry is warranted, but unfortunately support will always take a back seat to development, and that's where most of IT's budget will go. The CIO knows what gets them brownie points, and that's putting the latest and greatest system in front of the users to help them run their business. The latest widget and gadget is the politically correct thing to do. But all those pretty little systems will come to a halt if you neglect that infrastructure, and about 90 percent of the companies I visit are doing just that. It's mind-boggling how companies can pay millions and millions of dollars to Big 6 firms (we mention no names) who rip them off by bringing in new college graduates to develop new systems (and pay them peanuts) and charging them gazillions. Resources are scarce for every department. It's all about doing more with less; but if the time is not taken to develop this new infrastructure everyone (customers, IT, and the vendors) will suffer.

Database Administration
One other big question mark these executives have is whether the database staff should report to Technical Support or right to the Enterprise Services level? It can be either. It just depends on the size of your shop. If it reports to Technical Support you would have a pretty large organization. This is fine, but you'd better have a very sharp individual with good people skills. If you have a small shop the DBAs can certainly report to Tech Support.

Another issue that comes up in many of my discussions is whether the DBA group should report to Applications Development or Technical Support. If you had to pick one area I would pick operational support, a.k.a Enterprise Services. If the DBA reported into the Applications Development arena the focus would always be on the latest and greatest. If they were located in Technical Support the focus would be on ongoing maintenance and performance and tuning which is critical. It doesn't really matter as long as the DBA is involved at the different intervals of database design including implementation and support.

System Administration
This is my personal favorite because these are your system programmers of the 90s. Back in the 70s early 80s, the system programmer was the one person who could figure out what the problem was when no one else could.

Production Control
Production Control has a brand new role in the 90s and beyond. In the legacy world they owned scheduling, resolved nightly production problems, and owned change control. Now you can add owning those production servers. All of Enterprise Services owns production, but you only need one owner in the end to consult.

But it's more than just production ownership. They are the junior administrators for the senior system administrators and database administrators. Most of the cries for resources comes from these two areas and legitimately so. Servers are popping up everywhere. New technologies are evolving by the hour. Who can keep up with it all and try to keep their education current. This is critical. Hey, you executives out there. Do you remember how much we invested in our mainframe staff for training? So, not much has changed -- things are just more hectic, crazy, and distributed.

Production Control should be able to take some of the workload away from the senior techies and help out with operating system installs/maintenance, hardware implementations, and third-party tools support. Their career path is to System or Database Administration. Also, Technical Support owns security. This includes the junior analysts in Production Control.

Here we summarize the roles of System Administration, Database Administration, and Production Control:

System Administration:

Database Administration:

Production Control:

Resources

About the author
Harris Kern is Sun's Open Systems Migration Consultant for NAAFO Market Development. Reach Harris at harris.kern@sunworld.com.

[Amazon.com Books]Harris Kern and Randy Johnson are authors of Rightsizing The New Enterprise: The Proof, Not the Hype and coauthors of Managing The New Enterprise: The Proof, Not the Hype, and Networking The New Enterprise: The Proof, Not the Hype. You can buy these at Amazon.com Books. Select the hyperlinks to learn more about each and Amazon.com.

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
 -Too long
-Just right
-Too short
 -Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Sun's Site 		[Search]
Feedback 		[Next story]
Sun's Site

[(c) Copyright Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-12-1997/swol-12-unix.html
Last modified: