Back to Front

The onslaught of e-business has presented IT managers with an Integration nightmare. Something has to harmonise backend applications with customer facing front ends.

  • E-Mail
By  Matthew Southwell Published  September 9, 2001

What exactly is middleware?|~||~||~|Middleware is the layer of software between a company's network and its applications. Often referred to as the 'glue' that keeps information systems together, it covers many different functions, from integration to messaging, application processing to remote client routing, and tasks such as identification, authentication, authorisation and security. As such, it means many things to many people.

However, in order for this 'glue' to be considered as middleware it should have certain facets. These include the ability to be independent of any network or transport protocol, allowing it to connect anyone to anyone; a messaging engine that takes and delivers messages in multiple formats, whether it be XML or other legacy documents; the ability to define relationships between sources and destinations that have business rules, such as agreements and contracts in place; plus transaction, encryption and security support. Essentially, it is the electronic environment where software components come together and interact.

The importance of middleware has increased dramatically in the past few years. Paramount to this growth has been the onslaught of e-business, and the increasing number of applications that are deployed in today's enterprise.

As businesses purchase more 'best-of-breed' applications in an attempt to gain a competitive advantage, application integration is becoming ever more important as they have to communicate at the middleware layer. Enterprises want to ensure information flow throughout the organisation as well as automating systems wherever possible.

The problem with this is two-fold. Firstly, there is little point in trying to automate systems unless data is captured at its source and, secondly, applications from different vendors are not necessarily designed to communicate with each other.

In the past, companies wrote their own C code to link two applications together. The problem with this one-to-one communication came when an enterprise had a number of applications that needed to talk to each other as an interface had to be written for each new application link. In addition, every time the company upgraded an application the 'adapter' programme became obsolete and had to be rebuilt. Gartner Group christened this epidemic of third part application development 'application spaghetti'.

Diyaa Zebian, business development manager for the Middle East at BEA, explains that this cost enterprises a huge amount of time and resources.

"70% of [IT departments] time is being spent making applications compatible with the backend. [By using middleware] there can be 100% focus on business logic [and] building the application," he says.
Haider Salloum, product marketing manager at Microsoft Gulf & Eastern Mediterranean (GEM), adds that constant coding work also wastes resources as companies continually develop what is actually reusable code.

These time factors end up costing money. "You have to have some sort of mapping [to allow applications to communicate with each other] and it is this mapping exercise that has been very expensive [in the past]," explains Nauman Ahmad, business solutions specialist, government sector, Microsoft GEM.

The thoughts of local vendors are supported by global research. A recent report from Meta Group revealed that, on average, 25% of a company’s IT budget is spent on trying to integrate business systems. Backend integration represents up to 90% of implementation work.
The size of the network that this exploding number of applications have to communicate across is also growing. "As networks continue to increase in size, the patterns of communication are… centred around programs talking to other programs. At the same time, the variety of devices and services that populate the network is also expanding," explained Jim Waldo, Sun Microsystems, during his Middleware 2000 keynote speech.

Network growth and the increasing volume of applications is, perhaps, most prominent in the e-business space. Whether it be business-to-business (B2B) or business-to-consumer (B2C) e-commerce, it is essential that applications talk to each other across both a company's own environment and those of it's partners.

||**||Why does the Middle East needs a middleware layer?|~||~||~|Ayman Abouseif, marketing director, Oracle Middle East and Africa, explains that the ability to deliver a B2C model is "not just about having the product in your inventory. But rather [knowing] where it is in the supply chain and where it is on the production line."

In other words, unless a company’s warehousing application can tell the customer facing shopping cart software that the product is available the sale cannot be made. For this to happen, the applications have to able to communicate. This movement towards a transparent, information sharing supply chain is the essence of what Gartner Group have termed 'c-commerce' — otherwise known as collaborative commerce, which takes place between existing partners.

"Today integration goes further up — before you would have data from one subsystem going to another [but now] data has to flow from different places as all the information affects everywhere else," adds Abouseif.

The B2B side of the equation has its roots in electronic data interchange (EDI) — the standard ANSI X12 format for exchanging business data such as business documents or forms, between trading partners, in pre-Internet model times.

Ahmad explains that EDI consisted of three basic components; enterprise application integration, business process automation, and process orchestration. However, this method of data exchange was both complex and extremely expensive to set up. Only with the advent of the Internet did business-to-business data exchange become cheaper, simpler and more widely accessible.

Whether it is EDI or Internet-based exchanges, the reason for employing application integration across partners and customers is to make the supply chain both transparent and automated. This in turn reduces costs and saves time — whether it is e-procurement or a company's own capital outlay.

Bashar Kilani, manager of business transformation & integration software, IBM Middle East and Africa, also points to mergers and acquisitions contributing to the demand for middleware.
"Mergers and acquisitions [increase the use of middleware] as, typically, one company has one hardware and software infrastructure and the other has a totally different one. But now they are one company they need to integrate," he says.

All of these market dynamics that have led to the global growth of middleware are all present in the Middle East. Salloum explains that the majority of enterprises in the region suffer from incompatible applications that cannot talk to each other.

"You can go to a customer here [in the Middle East] and they tell you that they have an Oracle Financials application and a PeopleSoft HR and an EXceed warehousing application. The three are separate independent islands of information [that don't] speak to each other," he says.

Kilani agrees. He says that "in the Middle East we have a culture of buying best-of-breed packages and that results in different departments having different software and hardware infrastructures, [which creates] islands of computations."

In addition to this, he explains, the purchase choice is often department-centric, as they buy what suits their needs best. "You end up with systems running on NT, some on Unix and others on mainframes," he adds.

Ahmed believes that part of the reason for this is the region's organisations think that they can reduce costs by completing integration themselves. "This is not the case, in fact, integration software can cost up to US$100,000 — so it is not cheap," he says.

There is however a recognition that the situation needs to change. Salloum explains that "now every enterprise has multiple applications, a lot of people are saying that they want to utilise what they have in a much more efficient way."

||**||Middle Eastern industries that are using middleware|~||~||~|According to BEA's Zebian, the financial industry has been the first to embrace middleware within the Middle East. He says that the nature of credit and debit transactions means that, if they are to be completed online, they must offer the kind of guarantees that only a fully automated middleware layer can provide.

In fact, such transactions require more than just a general middleware layer. Abouseif explains that financial institutions have to implement a synchronous solution. This means that a transaction will only take place if it can access all the data sources at once, for example, if you are moving money from one bank account to another, it will only happen if authorisation is gained from both account gateways.

"Banking and finance is number one [in terms of middleware usage] because it has got backend systems that need to integrate with branches, with the internet, with call centres and with ATM infrastructures — plus they often want to integrate with other financial institutions that offer complimentary services , for example, when they want to do 'swift' transfers," adds Kilani.

National Bank of Kuwait has utilised its middleware layer to allow online transactions and also to deliver WAP functionality to its customers. Using internally developed COM objects, the bank has ensured integration between its Internet presentation side and the backend IBM systems.

In addition, by using COM objects, the NBK team was able to change the presentation layer from HTML to WTML and integrate a WAP server into the existing infrastructure, rather than having to develop a specific Internet side for WAP delivery.

"We did this whole project in 60 days and it was very cheap. The reason that we could do this was due to the object architecture that we had put in place two years earlier," says NBK's general manager of its e-business group, Simon Clements.

In addition to the financial services industry, the region's retail sector is also starting to get to grips with middleware. Emirates Airline uses an asynchronous solution to link its ticketing system into its frequent flyer points database. Once a ticket is sold, the points are credited to the customers account. In addition, Kilani explains that "airlines have to integrate all of their travel agents systems into their booking and reservation systems."

MMI has used its middleware layer to bypass its commerce server. Rather than going through it's public facing e-commerce web site, customers can now enter order data directly into MMI's ERP system. This helps reduce the number of processing errors as well as bringing the company and its customers closer together.

Zebian also believes that the telecommunications industry is starting to employ increasingly sophisticated middleware. He explains that "they have a lot of silo applications. The middleware comes in and makes the backend transparent." Kilani adds that "telcos use middleware to integrate billing systems and call centres and also with their Internet portals."

Evidence of the industry's middleware adoption comes from Bahrain's Batelco, which is completing a serious amount of work at its middleware layer as it establishes a vast call centre for all of its customer channels which will eventually be linked closely to the Internet.

||**||Middleware issues|~||~||~|These and any other organisations planning to deploy a middleware layer face a number of issues, from high-end strategy down to the granularity of messaging languages.

Assuming companies realise that internal 'adapter' development is too time consuming, too expensive, flawed and essentially futile, there are two main ways of approaching the middleware layer. One option is to select a vendor that provides a platform on which its applications run, such as Oracle's 9i offering or IBM's WebSphere platform. The other is to select an independent middleware layer. This brings in a whole host of companies at the regional level, including Microsoft, Sun/iPlanet, HP and BEA.

Abouseif explains that while using an independent middleware solution is both simpler and quicker than the C Code route, using Oracle's platform is even easier as all the applications are already designed to talk to each other through the middleware layer. He adds that the problems caused by things like upgrades are eradicated as Oracle takes care of them in the development stage.

"If you look at Oracle's integrated suite rather than individual best-of-breed applications then they [Oracle's applications] talk and work with each other already," he says.

Supporting this theory is the belief that no company can integrate more than three best-of-breed applications anyway. Abouseif says that Oracle CEO Larry Ellison went on record as saying that he would give $1 million to any company that could prove that they had integrated three best-of-breed applications.

Oracle's argument is almost convincing. While offerings such as Oracle's and IBM's allow companies to outsource its middleware integration, there is a down side at the application level. By taking all of its applications from one vendor a company will undoubtedly miss out on the best-of-breed applications that may suit its needs better and provide the additional functionality and deliver a competitive edge. Microsoft's Salloum concurs. "The problem is that there is no single vendor that can satisfy every need," he says.

If a company selects the best-of-breed route then it needs to deploy a middleware solution from a vendor such as Microsoft or BEA. The upshot of this is that development work is necessary but, due to the benefits of middleware, only one adapter is necessary per application as once it can communicate with the middleware layer it can talk with every application in the organisation.

Just which vendor a business should select is a moot point. The whole essence of middleware is that it is non-proprietary as it has to communicate across all programming languages and protocols.

Therefore, decisions on which solution to purchase will boil down to additional features, company preference and issues such as support.
The same applies to the language used at the messaging level. Given the choice of COM+, Java, or COBRA, Microsoft, for example, plumps for COM+.

Ahmed explains that "Microsoft likes COM+ because it is language independent and all other languages output COM+ capabilities." The fact that it developed out of Microsoft Transaction Server (MTS) is also a factor.

Microsoft's dominance of the operating systems market also influences the middleware messaging language debate. As Windows accounts for around 90% of platforms used globally, COM+ has a significant head start over the likes of COBRA, even if the latter is more widely used for Internet development.

However, given the fact that all of these languages have the ability to communicate with each other means that again the choice is a moot one. Obviously, Microsoft would rather you used COM+ and Sun or IBM would rather you used Java, but essentially it is a non-issue.
When it comes to languages, the one that every vendor and business employs is eXtensible Markup Language (XML). XML is a flexible way to create common information formats and share both the format and the data on the Web, intranets, or through middleware in a consistent manner. In essence XML is the language that transports data across systems, and enables the sharing of information.

For example, an order for a computer part would, in a typical interface, be represented by the following data stream:
"ABC47-Z", "100", "STL", "C", "3", "28"

The same data stream becomes much simpler to understand when delivered in XML:


Ahmed explains that because of this simplicity — he likens it to all computers suddenly being able to speak English — it has become a standard.

Kilani adds that "XML improves [a business’] ability to communicate with different systems and reduces cost. [It also means] that they do not have to constantly change or modify their systems.”

Analysts at Butler Group believe that in the next phase of business over the Internet, organisations will have to radically change their practices to support wide-ranging exposure of their services to both customers and partners. These links, it says, "will be largely automated, must be seamless and flexible and will be underpinned by XML as the lingua franca of business integration."

Tim Jennings, senior researcher at Butler Group, believes XML must be made a core part of companies' IT strategies if they are to successfully integrate business processes.

"XML should be seen as a competitive weapon. Managers must think how the potential of XML can be used in their particular organisation and put in place the infrastructure that will service-enable the business. Companies must build up XML expertise, talk to others within their industry, and produce a strategy for deployment of XML-related technology," he says.

"This strategy should focus on integration, with a single architecture that achieves A2A (application-to-application) integration now, but which also lays the foundation for B2B integration in the future," adds Jennings.

As the Middle East’s IT systems move into this future, middleware is something that the whole enterprise has to understand and appreciate. It is where the real business value of IT is to be generated, as XML schemas are core to the B2B and c-commerce visions. Unless this happens the region's technology assisted business strategies and e-commerce initiatives will fail before they get off the ground. Zebian emphasises this need for the deployment of middleware as he says, "you cannot predict the future, but at least you can prepare for it."||**||

Add a Comment

Your display name This field is mandatory

Your e-mail address This field is mandatory (Your e-mail address won't be published)

Security code