In-Depth
Ten Tips for Developers
Working to improve your company's agility
Demands on IT are ever-changing. In tight economic times, especially, rollouts have to be faster and payback periods shorter. But overall requirements haven't changed, however. Users still want to be able to make changes in a timely fashion to react to market conditions and opportunities.
The IT services, technology, and product industry is constantly adapting to these conditions, says Markus Nitschke, VP of Marketing at Attachmate. Nitschke is also responsible for product management at the company.
Attachmate has been in the mainframe emulation business for 20 years (each of them profitable—an enviable feat). Three years ago, Nitschke says, the company started molding customer input into new product lines. While customers still wanted host access, now they wanted to extend mainframe applications into new e-business initiatives. Creating tools that permit users to interact with backend systems without having to know the technical details (SNA or COBOL, for example) was the goal. The company was looking for a way IT users could publish business logic in current industry-standard interfaces (such as Java, Web services, and MS .Net), allowing interaction with mainframe systems using an interface other developers (such as the CRM team) can tap into. The result: a product called myEXTRA Smart Connectors.
Nitschke recently stepped back to get the "Big Picture." He looked at what customers were requesting and what his own company was demanding. It was clear that some topics were coming back to the boil, but many predictions (such as the prediction that IT would be "turning off the mainframe soon") simply weren't coming true. Recent IBM announcements show that company's commitment to big iron, and when considering costs per MIP, "mainframes are still the place to be," he notes.
A list of "top ten" tips for developers evolved from this examination, and Nitschke shared them recently with Enterprise Strategies. His tips suggest how to get the most from working with lines of businesses (e.g., accounting, sales, customer service) and the CEOs they report to.
1. Be aware of open standards, but don’t expect too much from them.
Some open standards are now ready to fill their promises; early rollouts (especially around Web services) were functional—they provided the raw technology standards—but they didn't address security and performance priorities. Some enterprises use a combination of standards—Nitschke says 25 percent of his customers use Java technology, 25 percent use Microsoft technology such as .Net, and the rest use a mixture of both.
An application should always work well for its intended purpose and must achieve its goal for the line of business, he says. He warns developers, however, to keep in mind "that requirements change and evolve, so always add the need to be extensible as a requirement and build in hooks up front."
2. Market your applications internally.
Want to be a star? You can meet multiple departmental needs with one application, which results in increased efficiencies and cost savings, but the mainframe "owners" need to push these applications out to other departments and lines of business within the organization. Let other departments know what's available on the mainframe, find out if the applications have relevance for other groups in your organization, and demonstrate the benefits of re-using all or part of the application
"Demonstrate how easy it is to re-use the application solution in total or in part. Again, it is imperative to develop the application as an abstract set of components/or functions – monolithic or pure point-to-point solutions tend to have little reusability." Make your applications available and communicate their availability, he advises.
3. Be aware of the concerns of the "guardians of the mainframe" – those people who are responsible for the mainframe.
If you understand the concerns of these people, you know they are wary of making changes to the mainframe, so use a non-invasive approach.
Nitschke notes that it's fine to leverage existing applications, but he advocates looking for developer tools that allow you to safely use the portions of the legacy application you need so you can efficiently tap [them] without raising well-founded security objections. "You can't just roll out solutions and then raise issues about security and performance later on," he warns.
4. Don’t bind your communication logic.
Reusing mainframe assets—that's what it's all about. While some assets wrap presentation, business logic and data access into one big bundle, you need to take those monolithic applications and integrate them into the modern world. Note IBM's push from CICS-based transactions into ECI-compliant "open CICS" transactions.
"Don’t build the application’s communication logic directly into the application; use an abstraction layer," he suggests. "This allows you to embrace the changing client requirements—COM to .NET to Java … Building in this flexibility allows for future changes to architectures without the requirement to rebuild solutions from scratch."
5. Technology is not for technology's sake.
Use newer technologies so people can meet business goals without knowing mainframe code. Those old applications aren't going away because they do meet line-of-business requirements. "Some software packages, especially ERP, take a long time to roll out because of high customization efforts. A company’s business model is reflected in its legacy systems. Legacy systems have grown with the business and hold the competitive differentiator—which is one more reason to breathe new life in the legacy system. Instead of replacing the legacy system, continue its use by integrating business logic and applications into new e-business initiatives. "
6. Don’t exceed the requirements of the request.
Integration should be a step-by-step process, not done all at once at the enterprise level. Rollouts must occur within six months, payoffs recognized within six to eight months. "Use standards to come up with a solution that is versatile but not enormous. Lines of business don’t want to pay for another department’s project, but they will want the flexibility a standard interface provides." You can ensure long term viability, Nitschke says, through "tactical baby steps that ensure long-term strategic viability." It's all about giving your users immediate benefits and allowing them to make immediate changes to the system.
7. Proactively ask lines of business how you can help.
There's the communication theme again. "Nothing impresses business managers more than this. Other departments may not know how you can help make their groups be more productive, so it's essential to communicate with other groups and lines of business.
8. Reduce duplication.
Don’t develop a task like ‘account-lookup logic’ 10 times. Develop it once in a fashion that applies to all departments, "componentize" the business logic, and turn it into a service. Then make it available to different people within the organization. "With the right tools, you can leverage these efforts without having to recreate or even replicate them. Find out what tasks are needed, what already exists, and how you can extend the use of these applications for greater business efficiency."
9. Look for opportunities to give more control to lines of business.
"There are some great tools out there that let your users tweak applications for a specific scenario." Nitschke notes that these tools must not be development tools but rather process flow tools, because more workflow procedures are happening at the department level that don't involve IT.
10. Keep central management in mind.
If each department creates its own applications or Web site, the result is chaos. Nitschke's recommendation: "Make sure each solution built is manageable from a single, logical point. Older solutions are constantly being tapped to service newer requirements; this raises management challenges as modern day solutions often span systems, platforms, and technologies. Centralized management allows you to manage and control workflow processes more effectively. Control needs to be at the source to better use existing assets."
Conclusion
It's all about communication and standards. A company's call center knows there are transactions on the mainframe and there's CRM data and the company could benefit by integrating the two. Nitschke knows you can't throw out the old mainframe systems. Instead, the key is to use industry standards to interface with those systems, write those interfaces once, find tools that capture business knowledge without requiring technical knowledge. By cutting your project into smaller steps with faster paybacks, and publicizing what's available to other lines of business, your business can improve its integration efforts, and in the process become more agile.