Getting organized

Organizing your New Enterprise can be a major headache, but it's made easier with simple architecture.

By Randy Johnson & Harris Kern

In columns past, we've argued strenuously that the key to our rightsizing success at Sun was to "Unixfy" traditional mainframe disciplines and practices (RAS). We've described the technology infrastructure and centralized controls that extend glass-house benefits to the New Enterprise, and we've detailed our Unix Production Acceptance (UPA) that formalizes the process. In future columns, we'll go into greater detail about the strategies, services, and procedures we use to make it all work.

But while you are neck deep in all that IT infrastructure, don't forget you've got to get it organized. Who's in charge? Who reports to whom? Centralized or decentralized? Do you need a system administrator at each server location?

Nearly every rightsizing book author and technical expert has a different organizational plan for distributed-computing business environments. Ours was molded from tried-and-failed schemes and finally, successfully, adapted from organizational structures that have been tested-and-true for over 20 years. Theirs might work in theory; ours works in reality, today. Who will you believe?

Live and learn
Throughout 1991 and 1992, Sun was going through a decentralization frenzy. It, supposedly, was the Unix "way." Distributed computing means distributed services and practices, right? We decentralized nearly every- thing. For us, the biggest and most costly mistake was decentralizing Sun's IT utility functions. We're still paying for it.

We replicated each utility function -- network services, client services, integration services, and the data center -- and placed those cloned groups geographically: the Pacific rim, Europe, and the Americas. Everyone deployed whatever systems they wanted. The only standard was that there weren't any standards. There was little if any communication among groups when selecting new technologies. Soon everyone was implementing their own networking standards and configurations. The same things happened with client services and data centers. Connectivity problems became immediately apparent. There was a lot of duplication of effort.

Sun let this rogue decentralized IT organization go on for about a year and a half. In 1993, we put Sun's business-production IT utilities under the control of a centralized management structure.

Recentralizing
For those of you who are still skeptical about centralized IT organizations for decentralized computing systems, here's another example. In 1991, we were part of Sun's centralized, mainframe-based Unix Data Center that supported a majority of the business units. Also throughout Sun, there were small, autonomous support groups for certain business units. They had their own systems programmers, database administrators, and production-control personnel; usually a group of about five people and a manager.

In 1992, Sun reorganized and made the Data Center responsible for those other, disparate support groups. That's when our biggest headaches began. Those maverick groups vociferously opposed the reorganization out of fears that they would be swallowed up by our "outdated" centralized-computing paradigm. The shouting was so loud that we hesitated. We thought perhaps they're right about the need for decentralized services in distributed-computing environments, so we left one group intact. It supported an autonomous business unit and our centralized services supported most of those remaining.

The results were staggering. We maintained systems availability at 99.9 percent. They didn't even measure availability. We had very rigid systems and software change controls. They changed systems "whenever." Bad practices on their part, though remediable. Other problems weren't so easily fixed. Because they had a small staff, if two people were out, they were in trouble. They kept asking us for more staff and were constantly begging us to cover for them.

After a year of dealing with these problems, enough was enough: We folded that group into the Data Center where our practices and systems were reliable, available, and serviceable. We had sufficient staff to cover operations even though, proportionally, we had fewer people per system. Through the centralized IT utilities, we could apply economies of scale to hardware and software, as well as to personnel.

There's another very important lesson from our experiences: The members of small support groups had no clear career path. In a centralized Data Center infrastructure, there are more positions and, hence, many more career opportunities. So fears of being "swallowed up" were certainly backward.

From the top
The best centralized organizational infrastructure for your IT system from the CIO on down is shown in the diagram The rightsized IT organization. Your company's CIO should control (own) everything in the IT organization -- down to the desktop. These include corporate financial and human resources systems and applications development, as well as the utility services of the data center, network services, integration services, which work with your business units to improve their information technologies, and client services, which also includes systems administration. This centralized hierarchy is the most effective way your enterprise will be able to deploy standards, implement distributed systems, provide the best possible customer service, and control user environments.

Reporting to the CIO and serving the IT infrastructure are the system architects. You need a chief architect to be responsible for developing the overall IT technology architecture. Depending on the size of your IT infrastructure, you might have anywhere from one to four architects, each responsible for developing an architecture for each service. The chief technology architect has authority of compliance with the IT technology architecture, while the CIO has final approval authority.

The architects define the following for each IT service:

Roles and responsibilities
Functions
Organization
Current state
Target state (three- to five-year plan)
Operational standards and procedures (day-to-day operations and support requirements)
Hardware and software standards.

Also reporting to the CIO are managers for each IT service. These managers and the architects should work as a team, headed by the chief architect and the CIO, to develop and implement the IT system architectures. All should agree on the details and achieve full understanding of the process.

Each utility service should designate key personnel who are responsible for each major function throughout the entire organization. For instance, the database administrator in the Data Center should be responsible for all databases within the IT infrastructure. Only through that kind of centralized control can you ensure systems consistency and reliability throughout the enterprise.

Decentralized applications
In the diagram, notice the dotted line between applications development and the business units. It's there because applications development has a dual reporting structure to the CIO and to the individual business units they serve. This is the only IT organization that should reside in the business unit.

Why? Because applications development is the crux of decentralization. The overall goal of distributed computing is to be responsive to the needs of individual business units. They know their information needs the best. Their applications serve their individual needs. A centralized IT infrastructure, on the other hand, provides the systems expertise, economies of scale, and enterprisewide consistency through standards that best serve the overall com- puting needs of the enterprise.

The central message is you don't need to reorganize and decentralize your IT infrastructure to implement client/ server distributed-computing environments. Yes, give the business units primary responsibility for dictating their information needs and, with your assis- tance, for developing the applications that deliver that information. If you have a solid IT infrastructure, it should be able to manage any of those new applications and technologies and ensure that they are reliable, available, and serviceable. Why change something that's been working for 20 years?

[Harris & Randy photo] Harris Kern (harris.kern@sunworld.com) is Sun's Open Systems Migration Consultant for NAAFO Market Development. Randy Johnson (randy.johnson@sunworld.com) owns R&H Associates, a full-time rightsizing consultancy in Boulder Creek, CA. R&H Associates helps people worldwide in implementing and supporting client/server infrastructures based on their proven methodologies. © 1994 Harris Kern and Randy Johnson. All rights reserved.

Pick up a copy of their book Rightsizing The New Enterprise: The Proof Not the Hype, SunSoft Press/PTR Prentice Hall, ISBN 0-13-132184-6, or their new book Managing The New Enterprise: The Proof Not the Hype by Kern, Johnson, Hawkins, Law, and Kennedy, SunSoft Press/PTR Prentice Hall, ISBN 0-13-231184-4. Browse SunSoft Press offerings at: http://www.sun.com/smi/ssoftpress

[Amazon.com Books] You can buy Managing The New Enterprise and Rightsizing The New Enterprise at Amazon.com Books.

If you have problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/asm-07-1994/asm-07-unix.html
Last updated: 1 July 1994