Better Host Integration

Host-integration projects have a deserved reputation for being large, complex and time-consuming. The good news is that there are simple steps that enterprise data center managers or network administrators can take to make the projects go faster, improve user satisfaction and save money at the same time. Here is a list of nine steps to follow before bringing in vendors or consulting organizations, or even assigning your team to devote specific resources to the project.

• 06/01/2000

Getting from point A to point B isn’t always simple, especially when point A is on your host systems, and point B is somewhere on your enterprise LAN or the Internet. That’s why host-integration projects have a deserved reputation for being large, complex and time consuming. I’ve put together a list of nine steps that I encourage you to follow before bringing in vendors or consulting organizations, or even assigning your team to devote significant resources to the project.

Step 1: Know Your Business Processes. I’m often amazed at how rarely IT managers understand how their business works. They’re often too concerned with "are the computers up and running" and "what’s the response time on the server" to know how line-of-business users actually operate the company’s information resources. Once the IT staff understands the processes, they can almost instantly see where to add value and save effort, such as with host integration projects.

When you look at your business processes, pay particular attention to anything labor-intensive. As we move to a Web-based data-processing infrastructure, automating these applications can give you a huge return on investment.

Step 2: Document the Existing Business Processes. The documents you create in this stage will affect every step in the host-integration project, or for any process-reengineering project your team undertakes. Document processes in "use cases"– simple English statements which describe how systems work. A process’ documentation includes a description of actors, actions and events. The actors are the computers or system users involved in the system. The actors perform actions, often in response to certain events.

In a formal software development setting, the tasks of creating use cases can be incredibly complex. Here, you don’t need to be so detailed. The benefit of the use-case model is that anyone in the organization can read them and understand the statements.

The lead on building the use-case model of your business processes should not be someone involved in the process! If you don’t know the business process, you won’t skip steps, but will ask the real "now, what do you do next" questions that unearth how the business really works.

Step 3: Develop and Document Your Requirements. Now that you know where you are, where is point B? Write down your requirements in a statement of work. Start with something as general as "Automate the transfer of information from system X to system Y to eliminate eight hours of retyping," or "Provide near-realtime access to the officer promotion database." Be as specific as you can, and if possible, write down why you want the systems changed. If you can write a list of all, or many, such requirements, unifying them into a grand plan, that’s even better.

Once the requirements have been documented, now it’s time to prioritize. Which will provide the biggest bang for the buck? Some tasks may take two weeks to automate and others might take two months. If your consultant knows which requirements must be met this quarter, which can be met by the end of the year, and which are just "wouldn’t it be nice?" musings, a bid and action plan that truly matches your needs will be easier to produce.

Step 4: Perform an ROI Analysis. In addition to wanting to know if your requirements are truly worth implementing, performing an ROI analysis will also help you justify the expense of the project to upper management, as well as help you evaluate bids.

Step 5: Create an Architectural Diagram. When you’re ready to talk to consultants, vendors or systems integrators about your host-integration project, you’ll save them time, and therefore, complete the project more quickly and less expensively, if you can provide them key technical data up front. That will also improve the accuracy of their project proposals, and eliminate false starts.

A great place to start is with a simple network diagram. What’s where? Where are the mainframes and how are they connected to the LAN? If a data center is off-site, what’s the connection between it and the rest of the enterprise’s data infrastructure? Which connections are routed, switched or shared; which use IP, which use SNA or IPX? Chances are that you already have this information, perhaps manually drawn with a diagramming tool or automatically created by a configuration-management suite’s live databases. Either way, make sure the information is presented up front to anyone potentially involved with this project.

Step 6: Create a Logical Diagram. Make sure that everyone understands where all the data is, where it goes, and which applications access it.

As part of this process, document not only the applications, but the versions and operating environments. Knowing it’s an SQL Server on a Windows NT server is helpful, but specifying that it’s an SQL Server 7 running on Windows NT Server 4, service pack 4, is better. Noting that there are five other databases on that same server, which has dual 400MHz Pentium II processors and 256MB RAM is even better in helping determine which systems are bottlenecks, and which have room to grow.

Don’t just focus on the servers and switches. When you’re building systems for end users to operate, it’s important to know their baseline. Which operation systems? Which Web browsers? It certainly makes a difference to know that you want a Web-to-host application designed to exploit Netscape Communicator’s unique features, as opposed to building one that’s going to perform equally on any browser. To developers, Netscape Communicator and Microsoft Internet Explorer really are different products.

Step 7: Capture and Document All Host Application Screens. With many Web-to-network or Web-to-host projects, data is captured from the host system, and fed back into the mainframe, via direct interaction with emulated 3270 or 5250 screens. This allows the projects to leverage the business intelligence, error checking and other features built into the host application, and doesn’t require changes to any of the host applications in order to provide the integration project’s new functionality.

Knowing the composition of those screens helps everyone not only see which applications contain which data, but where in the application that information can be accessed, and in which formats.

Step 8: Visually Describe Your Dream Application. There’s nothing like an interface document to really make sure that everyone’s on the same page. This can be as detailed as you’d like. A picture really is worth a thousand words, or thousands of dollars of a consultant’s time.

Step 9: Start Small. It’s better to take a month to tackle one small, but vexing problem, deploy the solutions and begin to realize its benefits, than to take a year to work on a huge project and then plan a massive rollout. Most users would prefer to have limited functionality now, than nothing now, but everything sometime in the future. Incremental development and deployment give you feedback early in the process, so you can see which concepts worked, and which didn’t. It also continues the buy-in process.

About the Author: Rob Innella is the Business Solutions Manager for Attachmate's Federal Services Group (Seattle). He can be reached at robertin@attachmate.com.