Burlingame, CA?Mergers and acquisitions happen. IT environments expand as new applications are added to keep pace with business goals. New technologies spring up, as others that were once the latest, greatest thing become yesterday’s news. Change is inevitable in the application development field, but one issue that remains constant throughout every permutation is systems integration?somehow, some way you have to make the technologies in your ever-changing IT environment talk to each other. As Richard Soley, Chairman and CEO of the Object Management Group (OMG), put it at the opening keynote event of the OMG’s Integrate.2003 conference, “integration is the problem that won’t go away.”
Tuesday’s keynote brought together a panel of five CIO-level executives from large enterprises ranging from Sun Microsystems to Telelogic AB to Covad Communications to discuss how they have each tackled the never-ending integration problem at their respective companies. Although each panelist’s experience was quite different, all agreed that the issue is as complex as it is critical.
Russ Daniels, vice president, Software Global Business Unit Strategy and Technology Office for Hewlett-Packard, spoke of the increasing heterogeneity in IT environments and the convergence between development and deployment that mergers and tighter deployment times have brought about. The wall that once existed between the two?over which developers would throw their completed applications for the deployment team to implement?is being chipped away.
Of course, integration is not a new phenomenon. Paul Grantham, Vice President, Software Development for Covad Communications, acknowledged that integration has been a recurring problem during his entire 20-year career in software development. In his current position, he’s tasked with managing the integration of eight telcos among thousands of central offices, each of which may use its own business semantics. Even with central offices that use XML as their data format, a discrepancy as simple as one office using “7” in its data while another uses “seven” could cause an entire system to freeze. He currently needs five people on staff to monitor such changes?a process he’d like to automate but as yet hasn’t found a suitable solution.
Magus Christerson also stressed that integration is not merely a technology concern. In fact, the Director of Product Strategy for Rational Software said integration is fundamentally a business problem. When IT becomes a bottleneck, he explained, it creates a lot of pressure.
Christerson noted that we already have an excellent model of integration, one in which billions of machines exchange data seamlessly everyday: telephones and fax machines. Despite evolving standards, networks, and devices, as well as the issues surrounding tone versus pulse dialing, legacy systems that are up to 50 years old, and analog-to-digital data conversions, Christerson said he still makes a phone call today the same way he did decades ago with the same confidence that it will get through.
So why can’t developers and IT managers achieve the same seamlessness in their own integration projects, virtually all of which are surely on a smaller scale than the telephone network?
Modeling: The Starting Point
The one procedure that was common to every panelist’s integration methodology was modeling, from a common, architecture-level model for the entire enterprise to one for each application that’s brought into the enterprise. By all accounts, it is an important first step that eases all the steps that follow. “If you have a good model and a good framework, you can manage the majority of the problems in [integration],” said Ingemar Ljungdahl, Chief Technology Officer, Telelogic AB.
William Vass, who is responsible for some 500 applications as Vice President of Information Technology for Sun Microsystems, stressed that modeling upfront is important, before any other work begins. “Once you understand the plumbing, it’s easy to [build out apps],” he said. Daniels pointed out that models are needed for distributing your defined architecture, and when asked about the painful process of analyzing the proprietary business semantics of legacy systems at the beginning of an integration project, Grantham stressed that you must have your own reference model into which you can bring other systems.
Even models, however, are not without complications. Soley indicated that this important step is sometimes overlooked because development teams often find it easier to concentrate on their specific responsibilities within larger projects than on higher-level strategies that make the applications adaptable.
“Even when models for separate systems are determined, how are they pulled into a common model?” asked Vass, describing another challenge he faces in his projects. Ljungdahl added that this creates the problem of preserving the value of your models for future deployments in what will then be different environments. Your modeling work should be useful not only for present-day projects but for any that come later.
Keep Them Separated
Although concrete solutions were hard to come by during this 1.5-hour discussion, Vass proposed a clear strategy to ensure a flexible enterprise application environment that can accommodate the inevitable technology changes it will face. He advised attendees to keep the three layers (business rule layer, data layer, and presentation layer) of their architectures separate.
“Own your business layer, utilize your data layer, and your presentation layer will change every few months,” said Vass. Under this structure, once you’ve defined your business rules, that layer can remain constant regardless of the changes you need to make. You can register any new applications that come online in a universal business registry that you manage in the business rules layer using UDDI or WSDL. No need to reinvent the wheel because now you’re required to support wireless functionality, for example. Putting those business rules in something that you can use on any platform (Vass suggested Java and XML) adds to the architecture’s adaptability.
The other two layers can then accommodate any new technology. As the data layer is continually updated, the presentation layer can go from providing a Web browser interface, to a WAP phone interface, to a PDA interface simply by adding the appropriate apps and registering them in the business rules layer.
Preparation Leads to Agility
Why, in his 20th year as a software developer, is Paul Grantham?and sooner or later every other developer?still grappling with enterprise application integration? In the age of platform independence and interoperability afforded us via technologies like Java and XML, shouldn’t a brand new Java app be able to interface with an old Cobol mainframe the same way a new Nokia cell phone can call an old rotary telephone? In a perfect world, sure, but you don’t work in a perfect world. Standards are splintered, legacy data employs proprietary business semantics, and the amount of training or consulting help necessary to connect it all is cost-prohibitive for many organizations.
The best you can do is utilize the available tools and strategies that assure that the struggles you have in your integration project need not be repeated when that next project inevitably rolls around. First, use modeling technologies to define your application and systems structures. Then maintain abstraction between the layers in your architecture. These principles will enable an agile IT environment that can adapt to any change.
Communication Breakdown
Even more fundamental to the integration issue than technology is the human element, according to Soley and Tim Sloane, Director of Business Modeling and Collaboration at Aberdeen Group. A main reason why integration is a problem that won’t go away is the IT development and business management sides of most organizations have yet to work together effectively.
Sloane explains that developers often code to the requirements of a given project without ever communicating with the business side to examine their roles in the larger organization. This narrow focus can cause situations in which a developer writes code to kludge together a solution in his small section of the pipeline, and when other systems are later brought online at a higher level, that code causes bugs and needs to be changed. And as system complexity increases, making changes to old code becomes more difficult and time consuming, even if you wrote the original code yourself.
Soley offers this simple advice for the IT department as a whole: design the system, document the design (through modeling), communicate the design, and manage everyone’s adherence to it. Responding to why that’s been such a difficult policy for organizations to implement?despite the resulting ease of integration, Soley said: “It’s a change in how people work, and people don’t want to change how they work.”
Although he acknowledged that moving from myopic code work to a process-level responsibility and skill set would be painful for many developers, Soley?who comes from a programming background himself?submitted this challenge: “To be an engineering discipline, we have to be engineers.”
