Software Ecosystems

We saw it happen first in the realm of computer hardware. There was a time, when every computer system had the 'IBM' label. Every component (except perhaps its processors) was actually made by IBM. And then as standards became more open and transparent, we saw the emergence of companies each producing different parts and components. So you could have the central IBM core, HDDs from someone else, printers from another and so on. Still, it would be a single system and perhaps be still supported and maintained by IBM. Software apparently has now reached this stage.

Today, the growing complexity of software has made it difficult for vendors to provide effective after-sales services such as, patch-deployment, shipping upgrades and updates, and asset tracking. Of course, users also have become more aware and demand that 'customizability' and 'bottom-line' be a part of what they buy. In large software (such as ERP, CRM or SCM) systems, the users only want specific modules be present in their solution. For example, Acme Inc wants only HR and Production Management, while XYZ Corp wants Inventory and Accounting in addition.

This has led to the once large software being broken up into fairly independent 'modules'. A module would typically deal with one core functionality. For example, you would have separate modules for HR, Production Management, Inventory and Accounting, so that both Acme Inc and XYZ Corp can mix and match them, as they prefer. Each of these modules can be installed regardless of where other modules are present, but they will work with each other well enough to appear as one single product to its user to create what has come to be known as a 'software ecosystem'.

In a software ecosystem, there will be three types of vendors. The ones who make the ecosystems, the ones who make the various modules that do all the work, and the ones who use the pluggable APIs to add extensions to the product. And all these pieces work as one product as far as the end-user is concerned. Vendors can make combinations of these pieces according to their capability and strategy. That is, someone like Oracle could be making both an ecosystem as well as some modules. These modules may either be specific to one ecosystem or may work with systems that use the same technology. Vendors who insist on creating all the bits themselves will have to have something special in their product to remain in the market.

Ecosystems were first seen in ERP software. Now, even the OS has not been spared. Modern OSs carry components made by different sources. For example, you can have the kernel from one source, the file system from another and the user interface from yet a third one. Saturation plays a big role as well. The so-called 'High-end Enterprise' market (for instance) has become saturated with the likes of SAP, Siebel, Oracle and PeopleSoft having time-proven solutions. Each of them has created a niche for themselves and there is little that can be done to offset that market.

In the mid-market levels, companies now have more money. And, this has prompted them to implement commercial ERP solutions rather than relying on in-house solutions. 'Sizing down' as they like to call it, has resulted in these companies being able to adopt scaled-down versions of the same ERP, CRM and supply chain solutions.

Both Gartner and Forrester take note of this in their recent reports. They say that even ERP vendors would put more emphasis on EAM (Enterprise Asset Management) and functionality. EAM is important for productivity and cost control. And maintaining that, maintains bottom lines. In the modern context, you need to be able to use existing ERP systems with newer information. And, X Internet has helped achieve this, in combination with messaging and ESA (Enterprise Services

Architecture).

SAP announced, at SAPPHIRE 2004, the rollout of a new application base over the next three years that will take their existing client/server architecture to the new ESA model. The new system is expected to contain both common as well as industry-specifics. If they manage to pull it off, they can retain their special integration value as well as gain flexibility in deployment and adaptability. But we will only begin to see the fruits of this by 2008.

Another concern is the demand of the new mid-market customers, TCO (Total Cost of Ownership). It is no longer possible to leave the 'plus taxes' surprise to the final stage. Because of improvements in both Java (J2EE) and .NET, we are seeing a move to upgrade SOA systems into ESA systems for all types of companies. And, vendors are belting along to revamp their product lines to stay in business. Resulting in both openness and flexibility in various platforms. Product APIs will be fully known and published and able to support all kinds of clients.

In a nutshell, architecture and flexibility matters a lot in the mid-market economy and increasingly complex ecosystems are driving new forms of integration. Vendors trying to offer all this have to match demands with TCO. The two markets (enterprise and mid-market) are still distinct, but their demands have become increasingly similar. With players such as Microsoft, Oracle and Siebel trying to grab the market share with new offerings and products, aimed at the mid-market, who knows what the future holds. Perhaps, as has been the fate of hardware, software too will cycle back to its monolithic beginnings.

Sujay V. Sarma