Social Open-Xchange will offer unprecedented capabilities to get application data – also in hosted offerings! – integrated easily.
SaaS is the new kid on the block when it comes to IT ecosystem integration. The unloved truth of browser based applications is their inherent weakness when it comes to exchanging data with a desktop environment and 3rd party applications. Open-Xchange changes the gameplan by doing the integration on the server. With an interface that is about as open and accessible and extensible as it can be: html with semantic markup.
Web2.0 was an attempt to get over data silos and the heavy duty integration business by gluing it all together in a nice and shiny GUI.
The results were often impressive, but did not really substantially help integration. Getting SAP to work with an Oracle stack (above the database that is) or something from IBM or something else talking to one of them requires integration work. The result were these posh consultant people who always used to fly business class, remember? … Browser based integration will not suffice to make them redundant.
One could now argue that getting the big guns aligned is not necessarily the first and most obvious goal in application integration. But if a concept like Web2.0 does not allow for people to think along bigger lines, where is the relevance of Tim O’Reilly talking about Web2.0 making inroads to the enterprise? Web2.0 addresses a small part of the problem. It is a step in the right direction. We need to evolve much further to really meet user requirements.
Integration of applications must be through data from one app becoming reusable in another one. And to do the integration within a browser based application has limitations, just as SOA integration projects do from the sheer financials: it latter will get you results, but at a prohibitive price tag for small companies.
Open-Xchange’s sweet spot is running one installation for millions of users, segmented into virtual partitions for dedicated clients of 5 to 500 people.
There is no inhibition against a single user firm subscribing to our service via one of our partners or a 10.000 people bank deploying Open-Xchange in house. But smaller teams is what we excel in. The objective for all our users is to get their data ecosystems integrated. They must be able to access one address book from all their applications. The same applies to all other types of data, from calendars, to resources, to task management. In many companies a zoo of applications sprouts features repeatingly implemented by many vendors because integration is hard in an IT world without standards.
Enter Semasntic Publish Subscribe.
Some of the points that took us to embrace microformats as the communications channel of choice for Open-Xchange data have been
- data should be easily accessible by users first and foremost
- no development black belt requirement should stand between a user and data, eg. a web designer must be capable to consume it all
- barriers to entry for ISVs must be minimal
- data formats are defined by the application defining / digesting them, onthologies are a dead end.
Data becomes available in an easily consumed, fully marked up format, all it needs to provide an Open-Xchange address book inside a 3rd party application is a parser for Open-Xchange Microformats. It is important to note that this parser is a generic parser for microformats in html. The tags we use are specific to Open-Xchange because the format must be well defined and rich enough to really eventually transfer the whole context around a piece of data.
The requirement of being well defined is ensured by a rather blunt aproach: the code is the spec.
Of course we will make sure that there is proper version information available, and also test cases to check for the integrity of code and data container. But eventually it boils down to us marking up our users content in the way our program works. By using a container powerful enough to span Open-Xchange and any number of partners by simply defining and adding support for new tags (all starting with “company / project name _” there are no limits to the ecosystem this can carry.
We will get into issues like naming conflicts, but expect branding to help a lot – how many companies with exactly the same name do you know? – and things like zoning can be resolved in later versions.
For now it is all about getting a handful of partners to embrace the concept, display Open-Xchange calendaring and address book information in their UIs, referencing respective mappings in their databases, aligning the use of tags between systems etc. . The same of course holds true the other way around and we will grow the types of data from other applications we will be able to consume over time.
There will be arguments made – in fact, we had a lot of discussions along these lines – that we could have used vCard, iCal, hCard, hCalendar etc. . After all, we have most of the code to do just that already. But that would have meant we restrict ox2ox communication to these standards. And that would have meant we leave out at least parts of what our application brings along. Like tagging of filtering results. Such tags can as easily be put into markup, just as the datatypes themselves. As a consequence eventually full replication of user contexts will be possible.
Let’s take this one step further. As internal triggers will respond to data, and as the code evaluating the data on either end of a communication between instances of Open-Xchange is identical, data should be sufficient to replace a fully fleshed API for ox2ox communication.
Where does all that relate back to Application integration?
It means that 3rd party application providers can simply access any and all relevant content inside an installation of Open-Xchange. By parsing published websites, ie. microformatted html at a URL. The same holds true for transferring data back to Open-Xchange. All it needs is a respectively marked up website where third party applications eg. provide address book or calendaring information to make them accessible from within Open-Xchange.
The setup of such an integrated environment is simple enough: just cut and paste respective URLs from the application’s frontends to the other system and off you go. Or provide a script to do that, or a plugin, or a widget.
This is all very much consumable for end users.
From a conceptual angle it is server side mashups. Aligning the data on the server gives users persistence of data intergration and services, the abilitiy to talk to as many servers and clients as necessary at the same time, and generally speaking the same level of integration they would expect in an enterprise environment.
Looking at the marketing terms the evolution of the internet has gone through it is probably only the web2.0 hype we need to consider. In this perspective the early web and all there was before – irc, gopher, ftp, telnet, … – where probably web1.x. Web2.0 was this great phantastic new idea to have code in the browser and do integration within the browser.
So what we are looking at now is a web where all clients also can become servers. The code is GPL and can simply be installed locally. And if this does not happen the hosted copy of Open-Xchange is still managed by the owner of its data. The important part is that these instances, local or hosted, can talk to each other. And to other services from other applications.
One could call it Web3.0.
