|Keywords for this document:|
APPLICATION SERVERS, B2B, B2C, BPR, BUSINESS ALIGNMENT, BUSINESS PROCESSES, BUSINESS RULES, CHANGE MANAGEMENT, DATA WAREHOUSING, ENTERPRISE APPLICATIONS, ENTERPRISE APPLICATIONS INTEGRATION, ENTERPRISE COMPUTING, ERP, INTEGRATION, INTERNET, INTRANET, MIDDLEWARE, MOM, XML
What is EAI?
The dis-integrated enterprise
The impact of a new economy
EAI tools and techniques
Enterprise application integration (EAI) belongs to a comparatively long line of IS approaches aimed at enhancing the contribution made by technology to business. Among its antecedents are business process engineering, business alignment and workflow. The problem they all identify is the fact that IS systems do not always or most effectively support business aims and objectives.
This problem has been exacerbated by the often chaotic growth of end-user systems, the spread of the Internet and the failure of large-scale enterprise solutions such as data warehouses and ERP systems to cope with the changes inherent in the current volatile competitive and technological environments.
EAI is not a technology nor even a precise strategy. It is, rather, a statement of aims which has grown out of the recognition that enterprise applications need somehow to work together if they are to achieve their promise. Accordingly, there are a number of different technologies marketed under the EAI rubric, and this can confuse the situation. In practice, EAI technologies either address the need for applications to communicate (application or event level integration) or to work with consistent data models and a single set of business rules. The combination of data models and business rules defines the way in which a business operates through business objects (for example, customers, invoices or delivery notes) and business processes (for example, fulfilling a customer order, sending out an invoice or shipping goods).
Inconsistency of data models and business rules is a feature of uncoordinated enterprises. It is often a product of the ill-considered implementation of particular technologies leading to so-called 'islands of information' and it is a potentially huge problem for enterprises seeking to engage in e-commerce at any level. EAI serves two distinct technical purposes - to allow all users access to a consistent view of enterprise data whatever applications they use, and to ensure that the applications themselves are always consistent. Application level EAI is based on message-oriented middleware, and is particularly suited to integrating legacy applications with new technologies. Data level EAI is based on shared data sources and requires applications to be decoupled from their data. Data level EAI is particularly suited to situations in which new business rules and data models need to be introduced. No single EAI product does everything, but data level products - particularly those supporting distributed databases - are increasingly important for the e-commerce and new economy environments. They promise greater responsiveness and a capacity to innovate.
New forms of EAI may become necessary as e-commerce blurs the edges of the enterprise. The old linear supply chain is rapidly giving way to a view of business as a flexible community of suppliers, customers and partners. The web provides a technological framework for such an architecture, and the development of XML a means of sharing data among disparate applications.
In considering EAI, enterprises should see change as the single most important driver of business. This indicates the adoption of open or standard solutions which decouple data from applications and allow easy modification of data models and business rules.
When it comes to finding a scapegoat for the failure of businesses and other enterprises to achieve real benefits from IT, one of the most popular candidates is always the lack of integration between different systems. As recently as the end of October 2000, the UK Inland Revenue confessed that it had closed the files on over a million people because information had been lost during the transfer of data in April 2000 from the Benefits Agency's computers to its own. According to one news report, 'the computers couldn't talk to each other'.
Similar scenarios are distressingly common, the result - it would appear - of chaotic mergers or inadequate IS implementation strategies. But it doesn't just affect the introduction or rationalisation of large systems. Lack of integration is endemic to organizations in which information systems have been introduced in an unplanned or uncoordinated fashion - and that is almost all of them.
Partly this is because of a familiar and near-universal lack of central control over the introduction and utilisation of IT at departmental level, partly it's due to the persistence of legacy systems, and partly because of the need to introduce proprietary systems for particular functions. A few years ago, the idea of data warehousing was developed in order to address this problem. The data warehouse, as conceived by Bill Inmon, was a means of imposing a single data model on an enterprise, so that operations and decision support would be working with the same information. The undisciplined way in which end-user systems have grown has encouraged software developers to talk about middleware and common object models as an approach to integration. Now the popularity of enterprise resource planning (ERP) with its new focus on the web has raised the thorny issue once again.
There can be little doubt that enterprise applications integration (EAI) would be enormously beneficial. If - as the terminology suggests - it implies integration at the enterprise level, it might even be interpreted in a 'non-totalitarian' fashion - in which end-user liberties and departmental autonomy might be allowed to coexist with corporate order. The possibilities offered by the extensible mark-up language (XML) may make this dream realistic and even practical.
What is EAI?
There is no single technology associated with EAI, and probably no simple definition. Unlike most other emerging buzzwords, EAI expresses a goal not a method, an attitude not a recipe. This may be confusing to those people looking for shrink-wrapped solutions, but EAI has a number of well-established antecedents. Its closest relatives are probably business process reengineering (BPR) and business alignment. Like them, EAI may involve rethinking business processes, and introducing structures, procedures and tools aimed at developing information systems which reinforce rather than weaken each other and, in doing so, address business needs.
In particular, EAI is intended to help enterprises introduce applications based on the Internet and related communications technologies that can exploit legacy systems and databases. In practice, EAI is often used to refer to the tools and techniques that tie together enterprise-level database-centred systems, such as data warehouses or ERP systems, and e-commerce. According to one definition, for example, 'EAI encompasses methodologies such as object-oriented programming, distributed, cross-platform program communication using message brokers with Common Object Request Broker Architecture and COM+, the modification of enterprise resource planning to fit new objectives, enterprise-wide content and data distribution using common databases and data standards implemented with the Extensible Mark-up Language (XML), middleware, message queueing, and other approaches.' (1)
Things aren't as confusing as this makes them sound. A small number of generic techniques have been put forward as a means of achieving this end, identifying different weak links in the chain of operations around which an enterprise is structured. Broadly speaking, these techniques focus on one of only two potentially troublesome elements or levels of any information system:
Simple, isn't it? There are only two ways to facilitate the integration of applications - impose a standard data model, or ensure that the applications themselves are compatible or can, at least, communicate in response to events (for this reason, application-level integration is sometimes referred to as event-level integration). However, as soon as technology vendors emerge on the seen, simplicity goes out the window. Our two levels resolve into two different groups of technologies. The first focuses on shared data sources, while the second focuses on shared objects and methods. Most newer applications decouple database and business logic, making data source sharing easy. However, many databases are tightly coupled with business logic and many applications store data in files or document formats. In these cases, middleware and messaging technologies must be deployed. In reality, any serious EAI implementation will need to deploy several approaches depending on the nature of the systems in use.
EAI has become particularly necessary in recent months because of the persistent failure of enterprise applications to address the changing needs of business. Internet-based e-commerce is just the latest example of how businesses (and other organizations) are faced with challenges to their established operations and technologies, but even before e-commerce became such a hot item the need to manage customer relationships and the supply chain, and the need to cope with the impact of M&A activity, globalisation, and a volatile business environment had encouraged the idea that the integration of applications was a critical issue.
The problem has been most frequently expressed as the failure of systems to implement business rules comprehensively and consistently across the enterprise. It becomes particularly severe when the business rules themselves are susceptible to frequent and often unpredictable change.
'Business rules' are statements describing the policies and practices of an organization - setting out, for example, departmental activities, job descriptions, pay scales, procurement procedures, and stock replenishment practices. Formulating business rules helps organizations to automate business processes, rationalise planning, simplify decision-making, and improve their responsiveness.
Business rules can be either explicit or implicit.
Explicit rules - sometimes called 'declared rules' - have been designed to implement known policies. They invoke business processes - the activities and information flows which together comprise business operations. They are typically expressed as conditional (if-then) statements. An example might be 'If the number of widgets in stock falls below 100, then reorder widgets'. More complicated rules might address more complex policies such as staff development - for example, 'If an employee on a middle management grade, who is not currently participating in a staff development programme, scores more than 80 percent on two successive staff appraisals, and if a suitable vacancy at the next grade exists, that employee will be invited to fill the vacancy'.
Explicit rules should have the following characteristics:
Expressed in simple English
Execution triggered by business event (for example, a sale or the receipt of a communication)
Immediate or deferred execution (a rule may result in an immediate action or a log producing later action)
May be implemented on a server or a client
Execution triggers a system event (for example, the creation, deletion or updating of a database record)
Exception conditions allowed (for example, senior management may be excluded from a staff development rule)
These rules express relationships between business objects - for example, customers, stock items or transactions. As such, they might be said to determine data models. For example, a business rule saying that widgets must be reordered if their stock level falls below 100 can only work if the required data is available. Implicit rules, on the other hand, are a function of data models. Typically, they would be expressed as simple declarative statements attached to system objects. For example, database records may have certain mandatory fields, variables may be defined as local or global, deletion behaviours may be specified to allow or restrict 'cascading', and so on.
In an ideal world, business rules would be comprehensive and consistent, and would provide the foundation of enterprise information systems. In the real world, however, business rules are often left unexpressed or, worse, they are allowed to develop in an unplanned and inconsistent manner. With the chaotic spread of end-user systems and the Internet, situations often arise in which business rules are, regrettably, determined by technology and not the other way round.
The dis-integrated enterprise
The effect of such chaotic progress combined with the general lack of coordination that is such a marked characteristic of most large organizations is that business rules can differ depending on which bit of the business is being considered.
We used to talk about islands of automation when systems were implemented piecemeal and without the proper concern for compatibility or interoperability. Now we talk about islands of information in similar situations, simply because the introduction of hardware and software solutions today is driven less by technology than by the need for information. Accordingly, in many businesses the IS department's biggest and most challenging task is to integrate these islands of information - to create an enterprise-wide approach to IS in which technology plays a supporting role.
In most organizations, systems have been introduced to solve particular problems in isolation from other concerns - for example, payroll, stock control, and accounts. The spread of the Internet has not helped this situation. The trouble is that even if joined-up thinking could be afforded, joined-up thinkers are a rare breed.
In practice, each 'point solution' is likely to be implemented in its own programming language, from COBOL to Visual Basic or Java, and have its own storage formats and devices, from mainframe-hosted hierarchical databases to PC-based spreadsheet files. There may be hundreds of incompatible systems in any large enterprise and almost all of them will employ different data models expressing different business rules. For example, a stock control system may store data about sales, while a CRM system will store data about customers. The same transactions are relevant to both, but the data in each system is likely to be incompatible.
The problem of mismatched data is not just a matter of connectivity or system-to-system communication. These issues have been addressed ad nauseum over the years and, for the most part, we are no better off now than we were when PCs first became serious business tools. Even ERP software (some would say especially ERP software) does not solve the problem.
According to CIO magazine: 'As ambitious and all-encompassing as ERP may be, the system won't run the company by itself. Inevitably, other software must be wired in to handle additional business functions, particularly industry-specific ones. And those other applications, often called bolt-ons, haven't always been trained to communicate with ERP packages. The process of connecting the ERP system to the bolt-ons into one harmonious whole can be quite complex. It can involve conversion of data formats, brokering of messages, writing of procedure calls and other tedious technical arcana.' (2)
In some ways, ERP, data warehousing and other big-ticket software has made things worse. While it is relatively easy to enforce connectivity and even build systems around standard platforms and agreed data models, it is much harder to ensure that business objects such as customers, sales and stock levels have consistent meanings throughout the enterprise. The very scope of all-in-one enterprise applications often encourages people to think that this problem has been solved. Of course, technology cannot enforce consistency in the essentially human processes involved in running an enterprise, and the emergence of e-commerce has thrown this fact into sharp relief.
The business analyst in a retail outlet or a bank may see customers as accounts. To him or her, the business rules that matter are concerned with selecting which accounts to target in order to maximise sales. In an e-commerce environment, this prioritises certain techniques for the collection of transactional data. The customer service representative sees customers as individuals. To him or her, the business rules that matter are concerned with improving the quality of the relationship between the enterprise and those individuals. In the same e-commerce environment, this may prioritise a completely different approach to the collection of transactional data. In theory, the desired outcomes for the analyst and the customer service representative may be identical, but in practice they operate in entirely different ways. They may need the same information, but they require different views of it and they do different things with it.
EAI is the process of ensuring that different views of enterprise information are consistent with each other and with the demands of the business. Its purpose is to improve decision-making and avoid the inefficiencies arising out of conflicting or contradictory data. In practice, there are two dimensions to the process - a horizontal dimension in which data must be 'synchronised' among applications, and a vertical dimension in which data must conform to the requirements established by the business rules.
For example, if a group of customers who regularly buy wine suddenly order beer, this information, based on data collected by a sales system, might invoke a business rule aimed at responding to significant trends in demand. The information should then be used to update the data available to other enterprise applications, such as business analysis, customer service, inventory management, and warehousing. This is often hard enough to accomplish without having to cope with a situation in which basic activities such as stock control are themselves undergoing fundamental changes driven by the development of new business models and a new economy.
The impact of a new economy
The exact dimensions of the change undergoing the economic and social order remains to be seen. Compared to a year ago, today it would be relatively easy to dismiss the Internet as a superficial phenomenon - dotcom shares have plummeted, banks make sceptical comments about the value of their on-line ventures, Internet growth in the US may have peaked according to some recent reports, advertising on web-sites is seen as an increasingly desultory affair. But the changes to business are nonetheless real and are largely technology-independent, having more to do with global economic and political developments than with any particular set of communications protocols. To an extent, change within enterprises is, in any case, self-motivated - people see their competitors moving, so they move - and will therefore continue regardless of the outcome of e-commerce adventures.
According to one recent report, e-commerce will account for 8.6 per cent of the worldwide sales of goods and services by 2004, although even this relatively optimistic view sees the phenomenon developing unevenly, with 12 countries (most of them in North America and Western Europe) accounting for almost 85 percent of online trade (3). According to another report, on-line business is still exploding. In 1998, the worldwide total was $50 billion, comprising $35 billion in B2B and $15 billion in B2C. By this year, the total is expected to exceed $200 billion, and by 2003 it is expected to exceed $1.3 trillion (4).
However you define it and whatever its limits, there is a new economy and it is changing business rules.
The rigid linear model of conventional, 'old economy' businesses in which enterprises are represented along a simple value chain is increasingly giving way to a more multidimensional and collaborative model in which communications allow the value-chain to reconfigure itself as necessary. In the collaborative value chain that increasingly characterises modern retail businesses, 'postponement' - the process of manufacturing or configuring 'on demand' - means that the retailer may engage directly at any point in the chain and may no longer be directly connected to the customer (in fact, on-line retailing may be reduced in certain cases to a simple exercise in branding a web site). This flexibility demands and increases information flows.
Conventional definitions of business functions are breaking down in many areas for a variety of reasons - shorter product life-cycles, the fast-changing competitive environment, a need to focus on building customer relationships rather than simply producing goods or providing services. The result has been a growth in partnerships and a tendency towards information sharing within the value chain. But most information systems are reactive - at best, they tell you what has already happened. The new economy is seen as proactive and business rules are increasingly about transformation not just management. This has shifted the emphasis of many businesses not just from product to customer but also from product to process.
The new economy, however you define it, breaks many of the old business rules. Take, for example, this observation by the Sun | Netscape alliance, www.iPlanet.com, 'Corporations build market advantage on well-designed, personal electronic interactions that bind customers through data-rich services. Formerly private databases now invite customers to review order status, inventory availability, account history, shipping status, FAQs, and custom catalogs (sic). Satisfaction comes from information, entertainment, and need fulfillment (5)'
Enterprises which focus on customer service and innovation now have to implement business rules which foreground staff creativity, immaterial assets such as brands and knowledge, response times, global reach, routine investment in technology, and the quality of the experience offered to consumers and business partners. This places great stress on information systems which have to implement new data models and data types. These must be consistent with existing legacy systems, but even more problematic is the inherent vagueness of many of the ideas underpinning the new business rules. Profit and loss is one thing (and even they can be interpreted in many different ways); creativity, knowledge and subjective experience are another.
EAI tools and techniques
The EAI market is no easier to pin down than EAI itself. Marketing literature often makes it sound like all EAI products are the same. Notwithstanding the preponderance of partnerships and licensing agreements, this is not the case.
As we've seen, there are only two fundamental approaches to EAI or levels at which it works - applications and data - but there are at least five different nuances to these approaches, to a large extent determined by the primary goal of integration. (It might also be argued that an entirely new approach is being developed with the introducing of XML as a means of formulating business rules and business objects for trading communities or organizational interest groups.)
|DATA||Transaction oriented systems: TP monitors and application servers|
Data pushed by one application to shared data sources
BEA Tuxedo, Encina, Microsoft Transaction System (MTS)
|Data warehouses, data marts, ETL tools|
Data pushed by two or more applications to a single data source
Arbor, Informix, Oracle
|Distributed databases, data federation systems (DFS) and gateways|
Data requested (pulled) by application from distributed data source
Sybase DirectConnect, Information Builders EDA SQL, Oracle Open Gateways
|APPLICATION||Message oriented middleware (point-to-point)|
Asynchronous (push) message passing between applications
Active Software, IBM MQSeries, CrossWorlds, NEON, SwiftMQ, Java Messaging System, Vitria, Mercator
|Message oriented middleware (publish/subscribe) |
Asynchronous (push) message passing using an information 'bus'
Active Software, IBM MQSeries, CrossWorlds, NEON, SwiftMQ, Java Messaging System, Vitria, Mercator
Table 1: Typology of EAI systems according to Michael Stonebraker (source: eAI Journal, 2000)
According to Michael Stonebraker, Professor of Computing at the University of California in Berkeley and developer of the Ingres database system, EAI can serve two purposes: ensuring 'cross-system consistency' and providing applications with 'a unified view of information for better decision making'. Describing the typology of EAI shown in Table 1, Stonebraker writes: 'Because cross-system consistency deals with what to do when we encounter an update, we label the left side "update;" the right side is unified view or "read." On the vertical axis, we explore the level at which we can perform EAI.' (6)
Ideally, EAI should be done at the data level. Apart from anything else, it's much simpler. The big problem with message passing or publish/subscribe approaches is that they don't directly address the issue of data. For this, they have to resort to a further level of technology - an adapter. But inconsistencies in data - so called 'semantic inconsistencies' - are the expression of inadequate or conflicting business rules. Adapters which fit one data definition into another data model don't solve this problem. What is needed is an approach that ensures that all data models are consistent and embody the current business rules. Doing this with ten applications may involve 100 separate adjustments. Even if each application operates on its own data source, that is still ten times as complex as rationalising the data sources themselves. In fact, according to Stonebraker, the Forrester Group has estimated that 'EAI at the application level is up to 20 times more difficult than EAI at the data level'. (7)
Application or event level integration is unavoidable in some circumstances, but that should not mean that data models and business rules are ignored. Where data and business logic are tightly coupled, there is no specific data level on which to operate. This situation is typical of legacy systems but is also to be found in some popular current enterprise applications, such as SAP, which implement data models at application level and employ databases of effectively unstructured records. Other situations are less clear cut. Some applications, for example, might support data level EAI when it comes to read operations but not when it comes to updates. This situation is typical of applications that implement business rules involving secondary operations on a database. For example, a TP system which automatically adds new customers to a mailing list could only do so at the application level by issuing a message to the mailing list application.
The fact is that EAI is never simple. When seeking to introduce EAI, your watchword should be flexibility. EAI solutions must be able to handle real-world semantic inconsistencies and multiple application architectures. Some technologies do not make this easy. Conventional enterprise data warehouses, for example, do not support updates: the data is frozen and centralised. They are good for analysing historic data to determine trends, but bad at handling current data and dynamic situations. If business rules change or if you want to link business analysis to supply chain management, avoid a data warehouse-based solution and go for a solution using multiple databases, updating and two-phase commit. If you can't avoid the warehouse, you must be prepared to invest time, money and effort in the EAI project - for example, by replicating the data.
At present, no EAI technologies address all four of Stonebraker's quadrants, which is one of the reasons why there is so much partnership activity within the EAI market. Composite technologies - for example, combining a distributed database and a messaging system - can be very effective, but they are complicated. They do, however, seem to represent the future of EAI.
The growth of the Internet has added impetus to the need for EAI. By any definition, e-commerce will require integrating applications with the web. However, it may be practically impossible to centralise and effectively control information on the web. Accordingly, there is considerable pressure to treat the web as a distributed data source in its own right. When confronted by the web, EAI technology need to gather in customers, suppliers and business partners - the whole trading nexus, in other words. The currently popular solution to this problem is to be found in XML, the extensible mark-up language, which enables trading communities to define data models specific to their communities but accessible through the familiar medium of the web.
The situation is far from clearcut. Applications servers or MOM technology may be more attractive than XML to enterprises which see their relationships with trading partners as exclusive or tightly controlled. Application servers and middleware can support a brokering infrastructure, similar to older-style EDI but on a deeper level. Instead of merely exchanging high-level messages, application servers can allow trading partners to access shared data directly, while business process management software from companies like Hewlett-Packard and Vitria provide a middleware platform for message forwarding. IBM has moved to bridge the gap by adding XML functionality to its MQSeries messaging software.
The advantage of XML is that it is not restricted to integration across organizational boundaries. For example, XML allows an enterprise to publish data on a web site which can then be read into other applications run on remote clients, subject only to whatever access control mechanisms the publisher wants to implement. XML has been called a self-describing data format - a user can access an XML file as a data source, not merely as a passive HTML page. In other words, XML supports local updating of data as well as reading.
Consider the possibilities offered for procurement or individual purchasing. Vendor information from a range of web sources, all using the appropriate XML definition, can be read into a single spreadsheet or database for comparison. Unlike HTML, XML allows the design of a document to be separated from its information content so that, in theory, an XML community can be defined in such a way as to make data access from web sites belonging to the community a seamless operation. The downside, of course, is that security may be only as strong as the Internet - that is, not very strong at all.
The EAI market is still young, characterised by numerous start-ups and much partnering activity and jockeying for position. Like many young technology markets, it is frequently besmirched by dubious claims and confused definitions. But the need for some sort of integration of applications at enterprise level seems clear and gets clearer as enterprises venture cautiously or with abandon into the potentially deep waters of the new, globalised, information-oriented economy.
Nobody can predict how this economy will develop - or even argue convincingly that there really is a new economy waiting in the wings. However, as philosophers have observed since Heraclitus in Ancient Greece, change is the one certainty, and enterprises which embrace change stand a better chance of surviving and flourishing than enterprises which try to ignore it. That is a simple truth. It provides the key to understanding the real benefits of EAI. These are not just that EAI leverages investment in different systems or imposes order on potential chaos, but that - properly implemented - it allows enterprises to be more responsive and more innovative. In practice, this means formulating business rules, imposing a set of consistent and coherent business processes and data models and then being prepared to modify or even abandon them almost at the drop of a hat.
For this to have any hope of working, a potentially large number of different enterprise systems must all be organized and controlled. Centralisation and the adoption of universal systems such as data warehouses and ERP have been shown not to provide comprehensive solutions, especially where the edges of the enterprise are beginning to get hazy. These big technologies fix things in time and place, whereas adaptive organizations need to cultivate creativity, local autonomy and fluidity. Middleware - which acknowledges the diversity of enterprise IS - may offer a more versatile approach to integration and is probably essential at some level, particularly when it comes to legacy systems, but it is relatively complex and probably not the best solution when EAI begins to move outside the enterprise into the world of e-commerce.
Wherever possible, adopt solutions that support open or de facto standards such as JMS, CORBA, XML and MQSeries messaging, and pay particular attention to the ease with which data models and business rules can be defined and modified. Perhaps the major issue in any EAI project is the semantic inconsistency of data models. This can completely undermine attempts to create viable business rules. A focus on data level integration is the best way to ensure that business rules are accessible and manageable. By operating at the data level, it is also possible to change business rules without rewriting applications.
Lack of integration between systems is a significant contributor to the failure of IS to bring real business benefits
EAI is not a uniform technology, but is more of a statement of aims recognising the need for enterprise applications to work together
EAI has a number of well-established antecedents including business process reengineering (BPR) and business alignment
Interest in EAI has grown because it promises to help enterprises introduce applications based on the Internet and related communications technologies that can exploit legacy systems and databases
EAI comes in two broadly defined flavours - application or event level, and data level - and has two broad functions - to ensure data is consistent across applications and to ensure applications have access to consistent data views
Application level EAI uses message-oriented middleware to allow applications to communicate with each other whenever an event occurs requiring data to be updated
Data level EAI uses shared data sources to ensure that consistent data views are accessible to all applications
EAI solutions must be able to handle real-world semantic inconsistencies and multiple application architectures
EAI products come in five or six different varieties and no single product does everything
Solutions combining middleware and shared data sources are inevitable, particularly where legacy systems are involved, because these tend to feature closely coupled data and business logic
Shared data sources promise much more effective control over data models and the implementation of business rules
Current applications tend to decouple data from business logic, making data level EAI a practical proposition
The ability to change data models and business rules is essential to enterprises in volatile environments characterised by rapid technological change, globalisation, increased M&A activity and the development of e-commerce
XML offers a potentially powerful tool for data level EAI in a web environment
1. See http://www.whatis.com
2. Derek Slater, The Ties That Bolt, CIO Magazine, April 1999 (See http://www.cio.com/archive/041599_erp.html)
3. See http://www.forrester.com/ER/Marketing/1,1503,212,FF.html
4. International Data Corporation, Internet Commerce Market Model, IDC, Framingham, Mass. March 5, 1999
5. Understanding the Net Economy Revolution, Sun | Netscape Alliance, 1999. (See http://www.iPlanet.com)
6. Michael Stonebraker, Integrating Islands of Information, eAI Journal, Dallas, Texas. 1999. (See http://www.eaijournal.com/DataIntegration/)
Activity: an action or group of actions involving business objects that represent a single logical step within a business process
Adapter: A component that transforms data so that two or more applications can process it
B2B: Business-to-business - e-commerce trading relationship in which both parties are businesses
B2C: Business-to-consumer - e-commerce trading relationship in which one party is a private individual
BPR: Business process reengineering - a strategy for reorganizing or restructuring businesses
Business object: An abstract physical or logical entity which initiates or is changed by an activity, for example, customer, invoice or database record
Business process: A finite set of activities with a determinable outcome which contributes to the operations of a business
Business rules: Statements describing the policies and practices of an organization; they may represent operational policies and structures (explicit or declared business rules) or system policies and architectures (implicit rules)
COM: Component Object Model - a Microsoft specification for software components that can be assembled into new Windows applications or 'plugged-in' at run-time to existing applications. COM is the foundation of the Microsoft's OLE (object linking and embedding) and ActiveX specifications.
CORBA: Common Object Request Broker Architecture - an open specification developed by the Object
Management Group in 1992 setting out how code segments constituting objects can communicate with each other using an intermediary or 'object request broker' which means that communication can be effected regardless of programming language or platform.
CRM: Customer Relationship Management - a type of application designed to assist companies identify customers, determine macro or micro patterns in their behaviour and control the relationship between them and the company.
EAI: Enterprise Application Integration - a loose concept referring to the tools and techniques used to help the different applications that need to work together within an enterprise to do so.
ERP: Enterprise Resource Planning - a family of software applications based on the idea that the management of resources - such as stock, capital and personnel - is the central activity of any enterprise.
HTML: HyperText Mark-up Language - the code used to control the way in which web pages appear and behave.
Java: An object-oriented programming language, developed by Sun Microsystems, which is designed to be secure and platform-independent. It is widely used to add functionality to web pages. Java programs use a small piece of software called a Java Virtual Machine which enables the same code to be run on different platforms.
JMS: Java Messaging System - a platform-independent messaging technology used for EAI and based on the Java programming language.
M&A: Mergers & Acquisitions
Middleware: An interface between applications which translates data passing between the applications. Used to integrate otherwise incompatible systems.
MOM: Message Oriented Middleware - middleware in which the data passing between applications takes the form of a message typically generated by an external event.
SCM: Supply Chain Management - a type of application designed to assist companies control the sequence of activities by which products (and, less frequently, services) are processed from raw materials to finished item. Increasingly seen as complementary to ERP and CRM.
XML: eXtensible Mark-up Language - a generalised mark-up language used to define practical languages for displaying and distributing content on the web. As such, it can be used to create data definitions and models for use by trading (or other) communities using the web.
Identify your existing systems and integration requirements
Avoid buying unnecessary functionality
An open approach will give you more choice further down the road
Evaluate the impact of change and plan for it - look for solutions that are extensible and versatile
A solution that cannot itself accommodate change will miss opportunities for business innovation
Single vendor solutions are rarely simple - consider if the vendor can provide end-to-end support
Avoid solutions that connect applications without considering the business rules