Tools Can Help Manage Change and Diverse Systems

by Dan Burger

Take a look at the enterprise-level companies, the mega corporations that sit atop the business food chain. What do you typically see in the IT departments? They have iSeries silos, Unix silos, Windows silos, Linux silos, and mainframe silos. And the culture, if you can call it that, is generally that hardly anyone talks to anyone else who is working outside of his or her silo. Change, however, is in the wind.

Let's call this IT evolution silo integration. It has been brought on by the realization that the information that resides in each silo is too important not to share it with the other silos. Some might say tear down the silos. Eliminate them. But that's not likely to happen. The use of multiple platforms in the enterprise is going to go one for a long time, even if there is platform consolidation. But managing these environments together, from a central control point at the application development level where companies spend a lot of their IT budget, will play an important role in an evolutionary process that will allow distinct platforms to play better together and for companies to stop wasting money by not knowing where they spend their money.

Dan Magid, president and CEO of Aldon, a software change management company with a strong iSeries heritage, certainly sees the necessity for a single point of control the entire enterprise application environment. That's what change management software does. It controls. It organizes.

"Once integration begins, changes in one place impact other things," Magid explains. "Companies in multiple-platform environments need a way of managing that."

Managing the application development process within one silo has a lot in common with managing the process across multiple silos. It also has some clear distinctions. One of those distinctions is process-oriented change management versus version control. Aldon's approach to management and process automation comes from the iSeries point of view, which is a very structured process control.

"I see that as a big advantage," Magid says. "In the iSeries world, you go from development to testing to quality assurance to production. In the non-iSeries world, it has always been a version management issue. Tools are built around managing versions of files--people check them out and check them in. The process is something outside of the tool."

Changing the minds of people who are familiar with using version control so they see the benefits of process control can be a big obstacle in multi-platform integration projects. One of the factors that work in favor of the process-control approach are regulations such as Sarbanes Oxley. "It is being interpreted to mean you need to have processes in IT," Magid says. "Auditors are asking companies, 'What are the processes you use to get something into production?'" In most instances, version control doesn't cut the mustard. It's also a matter of best practices standards, where structured processes are required for moving applications into production. As more companies adopt those practices, there's a greater need for process control.

In heterogeneous IT departments, silo bias definitely enters the picture. For many of the silo dwellers, it's a platform-control issue. The Windows warriors or the Unix geeks, for instance, don't want the iSeries people dictating change management. They want the change management tool to run on their server of choice.

Magid says Aldon frequently runs into this situation.

"We spend a lot of time telling customers that the iSeries machine is the most reliable and simple-to-operate machine in your environment, so why not put change control on that?" Magid says. "From the user's perspective, there is no difference. The developer doesn't see where the repository is. He sees everything through his graphical user interface. Why should he care where the code is actually running? But we do get pushback from the non-iSeries people. The justification is that we know how to administer a Linux machine; we don't know how to administer an iSeries."

Magid says Aldon has successfully competed in those situations for two reasons. One is process automation decision, which favors iSeries-based software that manages across the enterprise. The other is the capability of Aldon software to manage the non-iSeries items on a Linux machine or in a Linux partition on the iSeries. The Linux opportunities are primarily occurring outside the United States, he says, which is a very interesting tidbit of information.

"Linux is just a piece of the strategy for Aldon," Magid says. "We did it first because we could run it on our iSeries and do the development easily. We are also going to do an AIX version. That's the next thing. It is due out this summer. The reason to go there next is because we are an IBM shop. Linux, AIX, and iSeries get us coverage on most of what we want to do. There is a lot more enterprise development going on the Unix environment."

In the majority of its successful implementations, the iSeries is central to the organization adopting Aldon software. In other words, the company is doing most of its development work on it. If the main system a company uses is Unix or mainframe or something else, then it is not a benefit to put all the code on the iSeries. "In order to extend what we do to more marketplaces," Magid says, "we have to allow them to run our software on a different server. This idea of open systems and total platform portability is a myth. People have made technology decisions that they have locked themselves into. They think of themselves as an Oracle shop, a DB2 shop, or an HP-UX shop. You have to deal with that."

IT Needs to Be Entrepreneurial

Magid is outspoken on the topics of IT professionalism and of injecting some entrepreneurial spirit into what IT does. He believes it's critical for IT departments to measure and report on what it is they do and what they provide to their companies.

"Internal IT organizations cannot afford to be invisible," he says. "It used to be that IT took the approach of 'You tell us what you want, and we'll take care of it for you. Don't ask us how we do it; and we'll let you know when it's ready.' It can't work that way anymore."

While he's on the pulpit, Magid preaches that IT organizations should be entrepreneurial companies within the company. They should be examining ways to service their customers better. One way to do that is to deliver projects on time and on budget. (Dare we even contemplate early and under budget?) He cites a statistic that 24 percent of IT projects come in on time and on budget, and he shakes his head. IT departments need to tell their in-house customers when it will be delivered and how much it will cost--and they need to be right about both.

The reason for this poor record is that IT departments don't track anything. There's no process involved, he says. If you don't track, there's no way to plan or budget. And when Magid gets on a roll, he'll also let you know there are too many ad hoc requests coming into most IT departments--the bug fixes and the emergency problems that have come up. If you don't track those, you don't know how to predict those occurrences in the future and how they will affect other IT projects.

"The invisibility of IT departments is one of the reasons IT departments get outsourced," Magid says. "If the CEO is not really aware of what IT is doing for him, when the outsourcing guy comes in and says, 'We can give you programmers for $20 and hour instead of $50 and hour, and we are CMM Level 5 certified and ITEL certified,' the CEO is going to think 'Gee, I don't really know what my IT department does for me. I just know they are always late and always over budget. I'm going to try out outsourcing.' And the CEO gives up a huge amount when he does that because he doesn't recognize the value of an internal organization that really understands the business. You cannot buy the domain knowledge that your IT staff has in the way you do business."

By the way, Aldon has a community manager module that is an overall system for keeping track of user requests, which is exactly what Magid is talking about for the betterment of IT departments. It's all about productivity, whether it's managing application development or managing a department. Determining what is successful and what will reduce the number of defects is a direct correlation to what increases productivity.