Get Focused: Nine Steps to Better Host Integration

Host-integration projects have a deserved reputation for being large, complex and time-comsuming. The good news is that there are simple steps that enterprise data center managers or network administrators can do to speed up projects, improve user satisfaction and save money at the same time. Here is a list of nine steps to follow before executing your plan.

• 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. 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.

Based on my experience managing host integration consulting and implementation projects, 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. These "best practices" steps will help focus your efforts, as well as make it easier to explain to consultants, systems analysts or integrators exactly where you stand on point A today, and what you want point B to look like. It’s common sense, really, but you’d be surprised how often these steps go right out the window!

The first four steps will help you understand your business processes, and the opportunities to improve them by integrating your systems. The remaining steps will help you gather the technical information that the project team will need.

Don’t get hung up on the details of each step. For example, neatly bound documentation is better than scribbled notebook pages, but scribbled notebook pages are far better than no documentation at all.

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 IT staff understands the processes, they can almost instantly see where to add value and save effort, such as with host integration projects.

For example, I was involved with a project for the U.S. Marine Corps, working on a system which tracked how often officers were considered for promotion, and whether or not they were actually promoted. In the Marines, it’s important to know which officers have been promoted, been passed over once, been passed over twice, and so on.

One organization entered the results of each promotion review into a database. The file was sent electronically to another organization, where a clerk printed out the data file, highlighted entries on individuals who had been passed over, and then manually rekeyed those records into another database! The rekeying process took about eight hours of work and was repeated frequently throughout the year.

Once we understood the situation, there was an obvious solution. We built an automated system using terminal emulation and screen-scraping that took the same clerk about 15 minutes to operate. But until someone observed the actual processes involved in handling the personnel records, this problem languished unresolved.

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. Understanding the processes is good, but it’s not enough: Not if you want to get emotional or tangible buy-in from participants in the process, or if you want to estimate the financial cost of maintaining efficient processes, or even explain those processes to outsiders. 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.

I suggest documenting processes in "use cases." Use cases are simple English statements which describe how systems work, almost by telling a story. 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. Those actions, in turn, may prompt other actors to perform other actions. (A good book on use cases is Geri Schneider’s Applying Use Cases: A Practical Guide, from Addison Wesley.)

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 and say, "Hey, that’s not how we do business!"

Who should take the lead on building the use-case model of your business processes? Well, it 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.

By the way, when interviewing line-of-business staff to build the use cases, don’t just talk to managers, or just talk to line workers. Talk to both: There’s a good chance that you’ll discover a disconnect between how the process is supposed to work, and how it really works, either because of a lack of training, or because line workers have found shortcuts. You may end up with two use-case documents for certain processes. That’s okay: Just quietly document them both. The discrepancies can (and should) be resolved later in review meetings by addressing the actual processes, not just your documentation.

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. To speed the flow of information? Reduce errors? Improve the quality of reporting? Implement new revenue opportunities? If you can write a list of all, or many, such requirements, unifying them into a grand plan, that’s even better.

Think big. In our example, perhaps the second database could be eliminated completely by providing its users and applications with direct access to the original database. Whenever data is duplicated from one system to another, there’s a good change that efficiencies will improve drastically by using eliminating any superfluous data stores, and host integration is a great way to do just that by making data more widely accessible.

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, and which can be met by the end of the year, and which are just "wouldn’t it be nice?" musings, he’ll be better able to produce a bid and action plan that truly matches your needs.

Step 4: Perform an ROI Analysis. Once you know what you’d like to accomplish and why, you’ll want metrics to determine if those requirements are truly worth implementing. If the cost of a current data-entry system is $80,000 per year, it’ll cost $500,000 to reengineer it, and the only benefit is reduced data entry labor costs, that’s not necessarily a great investment.

If, on the other hand, you’re spending $80,000 per year on a data entry process in your commercial warehouse, and that same $500,000 investment will allow you to fulfill customer requirements for product shipments 24 hours faster, thereby improving the storage efficiency of the warehouse by 20 percent … well, you do the math.

Performing that ROI analysis will also help you justify the expense of the project to upper management as well as help you evaluate bids. You won’t know if a consultant’s estimate is reasonable, until you know what the project is worth.

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, 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 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.

How detailed? Not very in a host-integration project; workers need an overview of the network, not the firmware revision levels of your Ethernet cards. Just provide enough information so that anyone planning for the project, or involved in its implementation, can see where the data and business logic lives, and how to get there.

Step 6: Create a Logical Diagram. Once you’ve figured out the infrastructure, the next step is to develop a logical view of the applications and resources involved with the host-integration project. Ask yourself, "If I run this application, where is it going to get its data? Is it pulling from DB2 on the mainframe, or SQL Server on a Windows NT server?" 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.

Note that other common software denominators, too. If all users have Microsoft Office 2000 on their systems, then your Web-integration process might be able to take advantage of Microsoft’s Visual Basic for Applications; if Office isn’t used, or isn’t ubiquitous among your target users, then VBA’s not necessarily a viable option.

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.

In terms of the actual development of the Web-to-host system, knowing the number of applications, the number of screens, and the complexity of those screens will also allow outside vendors (or even internal developers) to make an accurate estimate of the time required to create the host interface.

Step 8: Visually Describe Your Dream Application. Now that you know that you want to create a new application, what’s it going to look like? Although you can certainly explain its functions in words, 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 bunch of screens or Web page layouts sketched in a yellow notebook can describe how you see users interacting with the application, and provide designers with an idea of what data you see being provided by users, and which information the system should respond with, and in what format. Charts and graphs? Point and click? A picture really is worth a thousand words, or thousands of dollars of a consultant’s time.

If you feel more adventurous, construct a mockup. That’s particularly helpful when planning a Web-to-host project. End user Web tools, like Adobe’s PageMill or Microsoft’s FrontPage, can let someone build tiers of Web pages, each in its proper hierarchical order. You don’t need to code the business or other underlying object in order to make the mockup meaningful. As an added bonus, the mockup might prove to be helpful in jump-starting development, so the effort’s probably not wasted. Those screens, too, can be printed out for documenting the interface requirements whether on paper or phosphor, the mockup can give consultants or vendors an immediate read on the complexity of the project.

Step 9: Start Small. After you’ve analyzed your processes, documented your systems architecture, and determined the tasks that would benefit from systems integration … don’t do it all at once! 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. When end users, managers, and everyone involved sees tangible results, that gives them confidence that you’re making progress. Also, once they get a taste for what you’re building, they’ll be begging for more, and their pleas might also give you more resources, and even dollars, if the situation reaches higher management.

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.