Live time
- Article 1 of 2
- Technologies for building the agile enterprise, June 2002
Whatever the advantages of the real-time enterprise, there has to be the technology to achieve it. Can vendors supply it?
Page 1 | Page 2 | Page 3 | Page 4 | Page 5 | Page 6 | Page 7 | All 7 Pages
The bedrock for the real-time enterprise is a unified applications architecture. If applications cannot communicate directly with each other, updates to the finance system may not affect the customer relationship management (CRM) system or the supply-chain management system until it is too late.
The non-integrated enterprise trying to compete in an online, always-on world suffers from all kinds of problems. Goods may be priced wrongly, incorrect delivery schedules quoted, good credit refused, customers upset. Without up-to-date information, information delivered in portals will not be trusted, analytics will be unreliable, poor decisions made, and expensive systems bypassed for expensive, but error prone method methods.
But do any of the application vendors and integrators have an architecture that is able to reliably disseminate information across an enterprise in real-time and get those applications to respond? Inevitably, they all claim they can do this - and, setting aside issues of cost, effort and flexibility, they are probably all right.
“There are three high-level requirements for turning the typical organisation, with all of its suppliers, partners, customers and employees, into a real-time enterprise,” says Bill Barhydt, president and CEO of web-services routing specialist KnowHow. “First, up-to-date, relevant information needs to find you; second, you need a way to connect the systems that hold the right information; and third, you need a way to move this information across these systems so that it arrives in the right place and in the right formats.”
There are two main ways to create a connected (or unified) applications architecture, capable of exchanging data seamlessly between all systems in the enterprise: buying all the applications from a vendor which has designed them (or amended them) all to work together; or, alternatively, taking existing applications and creating links between them using integration tools.
There are other ways, but they are still emerging and may, in any case, still rely heavily on the approaches above. These alternatives can use process level integration, in which different systems are accessed as services through a new workflow application; or they can combine this with web services to create an open, standards based architecture (see box).
These approaches may become more important. But for the present, the two main strategies are dominant and each approach has its proponents: Oracle, PeopleSoft and SAP sit in the former 'one big application backbone' camp, while Tibco, Mercator and other EAI vendors sit in the other camp, arguing for the greater use of integration tools. Web services, which creates a standard interface for applications to exchange data and advertise their services over the web, also has its own followers in the EAI camp.
There are some who argue that ultimately, all these will meld into one approach, and that the debate will ultimately come down to granularity - how big the components are. But that is clearly not today's debate.
Oracle's applications marketing director Phil Wood says the choice is clear. “A unified architecture is the best way and the only way. You wouldn't start out to design any integrated system by designing all the pieces individually and then working out how to put them all together. You need a group of people working together for a common outcome.”
Like its other big suite rivals, Oracle developed most, but not all, of its applications suite in-house, but it also acquired some applications from other companies. And, like its rivals, Oracle also recognises the need for most users to integrate some external applications.
Some of this integration can be done by hard-wiring the applications together. But Oracle has also done its own application integration project, based around a central XML repository, to knit the disparate systems together and create real-time capable systems.
This repository stores information about how the various modules that interface with it work and how to convert data from one module into another. The company has tried to build on its experiences with the OneMeaning Repository it acquired. It has also XML-enabled the various tools, so that customers cam import and export data models, transformations and implementation components between the various tools.
PeopleSoft takes a similar approach. It uses XML as an exchange and integrating standard, with a standardised directory for accessing the various applications.
Wood admits that in the past, people bought Oracle software to automate particular processes, but customers are now starting to take a cross-functional, process view. “Functions cannot really be isolated. The functions are part of a process. What we set out to do was to have a suite of software, all fully integrated, so we could glue together scores of functions”.
This chimes with the approach of PeopleSoft. Rick Berquist, PeopleSoft's chief technology officer, says that the real time enterprise is made up dozens of application components, such as supply chain, manufacturing control, human capital management, CRM, financials and analytics. But, he says, you need to be able to bring it all together in a unified way, integrated at the data level, with processes crossing the application functions in a non-linear way. They also, he says, need to be delivered in an integrated way, through a role based portal.
Trevor Walter VP of product marketing for enterprise application integration (EAI) tool vendor Mercator has a sceptical view of what the big suite vendors actually deliver. He says that although companies may provide suites of integrated products, in his experience, integration is always the last activity done by the vendor during their development. This means that they are not truly integrated.
And, of course, there is the usual classic argument against one big suite: “Most customers can't afford to have a fully integrated suite. And the 'one size fits all' approach doesn't get you best-of-breed components,” David Ince, CEO of specialist integration firm Acuma.
In any case, says Aditya Shivram, director of product management for EAI tool vendor Tibco, building an integrated real time enterprise will usually involve many applications: “In most cases, in large enterprises and decent-sized companies, IT decision-making is a fairly decentralised process. Individual departments buy their own applications to suit their own functions. The sales force will buy Siebel, the market department will buy something else.”
The bedrock for the real-time enterprise is a unified applications architecture. If applications cannot communicate directly with each other, updates to the finance system may not be reflected in the customer relationship management (CRM) system or the supply chain management system until it is too late.
The non-integrated enterprise trying to compete in an online, always-on world suffers from all kinds of problems. Goods may be priced wrongly, incorrect delivery schedules quoted, good credit refused, customers upset. Without up-to-date information, information delivered in portals will not be trusted, analytics will be unreliable, poor decisions will be made, and expensive systems bypassed for expensive, but error prone, methods.
But do any of the application vendors and integrators have an architecture that is able to reliably disseminate information across an enterprise in real time and get those applications to respond? Inevitably, they all claim they can do this - and, setting aside issues of cost, effort and flexibility, they are probably all right.
“There are three high-level requirements for turning the typical organisation - with all of its suppliers, partners, customers and employees - into a real-time enterprise,” says Bill Barhydt, president and CEO of web-services routing specialist, KnowHow. “First, up-to-date, relevant information needs to find you; second, you need a way to connect the systems that hold the right information; and third, you need a way to move this information across these systems so that it arrives in the right place and in the right formats.”
There are two main ways to create a connected (or unified) applications architecture that is capable of exchanging data seamlessly between all systems in the enterprise: buying all the applications from a vendor that has designed them (or amended them) to work together; or, alternatively, taking existing applications and creating links between them using integration tools.
There are other ways, but they are still emerging and may, in any case, still rely heavily on the approaches above. These alternatives can use process-level integration, in which different systems are accessed as services through a new workflow application; or they can combine this with web services to create an open, standards-based architecture (see box).
These approaches may become more important. But for the present, the two main strategies are dominant and each approach has its proponents: Oracle, PeopleSoft and SAP sit in the former 'one big application backbone' camp, while Tibco, Mercator and other enterprise application integration (EAI) vendors sit in the other camp, arguing for the greater use of integration tools. Web services, which creates a standard interface for applications to exchange data and advertise their services over the web, also has its followers in the EAI camp.
There are some who argue that ultimately, all these will meld into one approach, and that the debate will come down to granularity - how big the components are. But that is clearly not today's debate.
Oracle's applications marketing director Phil Wood says the choice is clear. “A unified architecture is the best way and the only way. You wouldn't start out to design any integrated system by designing all the pieces individually and then working out how to put them all together. You need a group of people working together for a common outcome.”
Like its other big suite rivals, Oracle developed most, but not all, of its applications suite in-house, but it also acquired some applications from other companies. And, like its rivals, Oracle also recognises the need for most users to integrate some external applications.
Some of this integration can be done by hard-wiring the applications together. But Oracle has also done its own application integration project, based around a central XML repository, to knit the disparate systems together and create real-time capable systems.
This repository stores information about how the various modules that interface with it work and how to convert data from one module into another. The company has tried to build on its experiences with the OneMeaning Repository it acquired. It has also XML-enabled the various tools so that customers cam import and export data models, transformations and implementation components between the various tools.
PeopleSoft takes a similar approach. It uses XML as an exchange and integrating standard, with a standardised directory for accessing the various applications.
Wood admits that in the past, people bought Oracle software to automate particular processes, but customers are now starting to take a cross-functional, process view. “Functions cannot really be isolated. The functions are part of a process. What we set out to do was to have a suite of software, all fully integrated, so we could glue together scores of functions.”
This echoes the approach of PeopleSoft. Rick Berquist, PeopleSoft's chief technology officer, says that the real-time enterprise is made up dozens of application components, such as supply chain, manufacturing control, human capital management, CRM, financials and analytics. But, he says, you need to be able to bring it all together in a unified way, integrated at the data level, with processes crossing the application functions in a non-linear fashion. They also, he says, need to be delivered in an integrated way, through a role-based portal.
Trevor Walter, vice president of product marketing for EAI tool vendor Mercator has a sceptical view of what the big suite vendors actually deliver. He says that although companies may provide suites of integrated products, in his experience, integration is always the last activity done by the vendor during their development. This means that they are not truly integrated.
And, of course, there is the usual classic argument against one big suite: “Most customers can't afford to have a fully integrated suite. And the 'one size fits all' approach doesn't get you best-of-breed components,” says David Ince, CEO of specialist integration firm Acuma.
In any case, says Aditya Shivram, director of product management for EAI tool vendor Tibco, building an integrated real-time enterprise will usually involve many applications: “In most large enterprises and decent-sized companies, IT decision-making is a fairly decentralised process. Individual departments buy their own applications to suit their own functions. The sales force will buy Siebel, the marketing department will buy something else.”
That argument may prove true in many cases. But it is also clear that PeopleSoft, Oracle and SAP have all had some success persuading organisations to replace their specialist applications and standardise around one product set. And, many analysts point out, the difference between some specialist applications and the suite component applications is not as great as it once was.
All the suites have the advantage that they run off one unified database (although it may be replicated many times) and that all the data formats and processes are standardised. This clearly makes it easier to build integrated processes across the enterprise.
A further issue, says Wood of Oracle, is complexity: “The ogre of integration is always there. Every time you think you've finished, you haven't. I'm not saying Oracle can do everything, but you have to get down to an acceptable level of three or four key vendors.”
But the EAI vendors all claim that their various approaches enable organisations to have real-time information-sharing across the enterprise via a unified architecture and best-of-breed software at the same time. Typically, they offer a 'hub and spoke' architecture, in which individual applications communicate through a common interface rather than by trying to speak each other's 'languages' directly.
Applications only need to be taught this common language via 'adaptors' or 'connectors' in order to be integrated with other applications. Moreover, functions such as message queuing, security, authentication and analytics can be built into the middleware layer.
Chris Worsley, vice president of global marketing at Kalido, says the company has optimised the system's architecture in such a way that it only takes a few seconds at most for applications to exchange data - microseconds normally - by using point-to-point links rather than via a central server.
EAI vendor, Tibco, meanwhile, has excellent real-time credentials, having been founded in 1987 specifically to link financial systems in real time. “We've kept that as we've developed the product,” says Shivram.
Tibco's software uses a model in which applications publish which services they offer and other applications can subscribe to the services. As soon as there is a change in the service, subscribers receive the new information, using any one of a number of protocols including secure web traffic (HTTPS). Some aspects of this have been taken up in emerging web services architectures.
Simon Pollard, an analyst at AMR Research, is not entirely convinced. He says that while EAI is one of the foundations upon which enterprises should run their systems architectures, leadership will ultimately come from “embracing multiple aspects within one technology suite”. “None of the EAI companies are sufficiently distinguishable in terms of current capability or vision,” he says.
Customisation still necessary
Part of the problem for EAI vendors is that instead of making organisations adapt their business processes to the software, the software and the integration has to adapt to the organisation's business processes. This may not be a bad thing as a theoretical business goal - but it is almost certainly more expensive.
Suite vendors, on the other hand, argue that customers should customise as little as possible, sacrifice some flexibility, and then pay a lot less and get better integration.
For the CIO, this issue is at the core of deciding on the unified applications architecture. Some prefer to save money and complexity by adapting pre-set processes; others prefer to customise heavily.
There are many attempts at compromise. Many EAI vendors, for example, are now producing business-process templates for specific industries, partly as a way of reducing the cost of customisation and specialist integration.
Giga Group analyst Ken Vollmer believes that this approach can work well. IBM, Tibco, webMethods and other EAI vendors produce, he says, good templates that organisations can use for advanced process modelling. But, he adds, companies, such as CRM-specialist Siebel, that are also attempting to produce more specific application level templates cannot do so well.
“The only thing common about most business processes today is that they vary significantly from one organisation to another. No single vendor, not even Siebel, has the cross-application and industry expertise to define business processes that work across multiple applications and many industries.”
Another big problem: some of these templates are unsuitable for use in the real-time enterprise. “There are lots of vendors in the marketplace with templates. Sybase created some. PwC [PricewaterhouseCoopers] has created some application templates. They're just not real-time. They are geared up more to the batch-processing environment,” says David Ince of Acuma.
Information not data
Jeffrey T Pollock, vice president of technology strategy at Modulant, an EAI vendor based in San Francisco, argues that the main problem with application integration is that most vendors “have an anaemic, if any, information strategy”.
Most user organisations, he says, focus on transporting data, objects and messages between systems and on performing basic translation tasks, but the software does not help transform information. “By itself, data has no inherent meaning. What does the symbol '21' mean to you? Clearly, it means different things if you are in Las Vegas, if you are 20 years old, or if you are at a military funeral.”
For EAI to work as an approach in the real-time enterprise, there needs to be a standard description or interpreter of data that can preserve the meaning of information, while at the same time converting its semantics for different descriptions.
But conversion alone is unlikely to be enough. The Gartner Group advises organisations to use enterprise-wide standards for business objects. “An enterprise may be able to use one XML-based standard for purchase order documents across multiple application systems, rather than finding itself with five different XML formats for purchase documents, each invented by a different part of the organisation.”
It is not safe to assume that this will problem will not arise if one unified suite is used across an organisation. Tibco's Shivram says that a number of his company's clients use Tibco solutions to integrate multiple instances of SAP that they have customised differently.
Kalido's Chris Worsley agrees. Shell and Unilever, he says, use Kalido software to integrate global instances of SAP. “Shell has 45 SAP systems and Unilever has three across Europe [It has just finished a big consolidation project]. They both use Kalido to integrate them.”
Kalido overcomes the problem by taking the information coming from different sources, holding each in different data structures, then reproducing a unified data source incorporating both. That means it must keep track of the definitions that work with different systems.
So do any of these approaches actually support the real-time enterprise today? Most vendors and analysts agree that while there may be a few technological obstacles still to overcome, it is usually business process issues that stop the company from becoming real-time.
PeopleSoft's CTO Rick Berquist, for example, says that the technology to support a distributed, real-time business is available now. “This is not a vision or a hallucination.”
Michael Hammer, the re-engineering consultant, says simply: “The technical problems are the easy problems.”
For this reason, and especially because organisations are increasingly attempting to integrate with partners in real-time, organisations are advised and warned that going real time involves a lot more than IT.
Page 1 | Page 2 | Page 3 | Page 4 | Page 5 | Page 6 | Page 7 | All 7 Pages