 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA News > Architects cite complexity and reuse as key challenges |
| |
|
|
|
|
| SOA News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Integrating enterprise applications can be a complicated and messy affair, but increasingly IT architects are beginning to turn to Web services for help. Attendees at the recent Gartner Application Integration and Web Services Summit touted Web services for enabling loose coupling and greater flexibility amongst systems. However, many companies are still relying on traditional enterprise application integration (EAI), which some fear can be a cause of vendor lock-in.
Jennie Balcom, an enterprise architect at Meridian, Miss.-based Pioneer Inc., is working with all the agricultural and nutritional business units of her company to set a foundation for understanding and connecting their processes. "We have one of those [process] spaghetti charts," she said. "We're trying to unravel the pieces before jumping into Web services." Pioneer needs to integrate its SAP modules with its existing IBM middleware. However, the company still wants the agility of exposing its assets to its partners, without being tied to any particular vendor, Balcom said. "I think Web services management and security will be essential to our future deployments," Balcom said. Sean Kateeb, a Web architect at Tacoma, Wash.-based Russell/Mellon, said his company, which provides investment analysis tools, uses a variety of systems and platforms ranging from Java and .NET to mainframe applications. "Application integration is vital to what we do," Kateeb said. "Our mainframe does the engine-based processing and the Web layer provides the front end and data collection functionality. We use WebSphere and .NET for our front-end office and WebLogic for our back-end integration." Russell/Mellon is trying to move away from application integration toward something more open and loosely coupled, what they refer to as functionality integration, Kateeb said. "We're not a large company, but we still face the same application integration complexities," Kateeb said. "With EAI, you're still building silo applications and connecting them behind the scenes." Architectural principles "Complexity is not the result of errors or bad decisions," said Yefim Natis, a vice president and research director at Stanford, Conn.-based Gartner Inc. in a keynote address at the show. "It's the result of an evolving and changing enterprise. Once you identify it, you can mitigate and change it." Some of the sources of IT complexity include immovable legacy systems, business pressure, laggings skills, mergers and internal politics. "You will not be able to solve complexity by buying one tool," he said. "You need to step back and look at the big picture of the enterprise. You need to look at the city and understand the different neighborhoods and components and see how they can work together."
Natis prescribed several principles to help reduce IT complexity and ease integration projects. Gartner's black box principle prescribes a "normalization" of component interfaces. Initially, programmatic software modules can be accessed by any application. As interfaces are normalized, data becomes more encapsulated and aligned with business processes. According to the community principle, organizations need to integrate their legacy systems by using common, interoperable protocols and by building interfaces for integration. These interfaces then need to be housed in a registry. "A searchable repository is fundamentally important to create an integratable, composable enterprise," Natis said. "This will allow much greater control of your environment. You need to catalog first but [you] also [need to] manage and compose." The onion principle prescribes that the underlying layers of software be abstracted from composite application designers. For instance, just as third-generation language programmers coding in Java or C++ don't need to worry about assembly or machine code, business analysts should not have to worry about objects when composing applications. Separation of concerns and collaboration are key to this approach. "Systems will not collaborate unless people who own those systems collaborate," Natis said. "In order to have an organized IT, you're going to have to have an organized IT department." "The answer to complexity is not a fix, but a cultural shift," Natis said.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
