In most enterprises data is stored in silos and applications are stand-alone. It is frequently necessary to link applications to applications or data to applications or data to data. If these are to be long lasting and durable connections then this interoperability can be hard-wired (coded) but that is expensive to accomplish. However, it is often the case that such connections are merely temporary: to support a particular marketing campaign, for example, or a specific research project. Indeed, in today's fast moving world one of the characteristics of an agile company is to be able to build, drop and re-build such connections rapidly and as required. In addition, the proliferation of APIs means that any sort of tightly coupled solution is becoming more and more impractical. Further, this is becoming even more of an issue as company resources become increasingly dispersed with some data and applications in the Cloud, some on premise and some in hybrid environments.
Unfortunately, the technology to enable the agility just described is not generally available, but this is precisely want EnterpriseWeb aims to provide. It enables ad hoc connectivity between application and data resources in a declarative manner: that is, you tell the software what you need while it works out where the relevant resources are and how to access them. You don't need to know what the infrastructure looks like or how it works.
EnterpriseWeb does not have a dedicated salesforce and it is marketing its products primarily through partners. Utopia Inc. of Chicago has begun to market an EnterpriseWeb based solution, a lightweight data management and governance fabric for the SAP eco-system. At a recent Cloud event, Global consultancy PwC outlined a data integration pipeline in which EnterpriseWeb provided "orders of magnitude improvement" over a conventional middleware stack. EnterpriseWeb also has partners using its platform for integrating advance SDN and NFV-based solutions for the Telecom industry.
EnterpriseWeb is deployed within large Universities and Academic Medical Centres on four continents, including Mount Sinai School of Medicine in New York and Warwick University in England. While its partners aren't disclosing specific customer details, Utopia indicated it has already deployed the SAP fabric with a leading life sciences company.
EnterpriseWeb works by having a resource pool (data and code, where the former includes reference data, user interface data, log data and so on, as well as conventional data; and the latter includes rules, analytics, process logic and so forth) at the bottom of its stack. You can think of this as a repository that stores meta-information about both data and code in rich entities, exposing diverse and distributed end-points as objects.
In the middle is a design environment for composing objects into higher-level application, data, process, network and UI models. Composition is code-free. Solutions can be rapidly prototyped by simply using link and metadata references to system objects. These models are persisted as objects that are co-located in the logical store.
At the top is a Universal Interface, a façade over the logical store. All events are handled by intelligent software agents (called SmartAlex™) that act as smart intermediaries between the user and the rest of the EnterpriseWeb environment. These interpret requests, dynamically translating links and metadata references to construct responses in real-time. The whole environment is loosely coupled with the run-time agents performing extreme late binding of just the right objects for the job. This is a 'lean' processing method as agents interpret objects in real-time on short-lived, non-locking threads, with the resource pool dynamically provisioning compute, storage and network resources. This approach should be both efficient and elastically scalable.
To clarify how this works, consider APIs. What EnterpriseWeb does is to logically differentiate between the business exchange that is requested (the "what") and the technical handshaking (the "how") that is required by the API (dependencies, assertions, protocols, transformations, and so forth). The result is model-driven "Dynamic APIs", which logically separate business logic from implementation details. This de-coupling enables the rapid prototyping noted above and allows for flexible implementations based on conditions, making the environment much more agile.
There are a number of particular features worth mentioning. First, all indexes and tags are updated automatically so the environment is curated for you. Further, there is cross-process governance built-in with universal version control across the environment. Secondly, you can explore the environment using graph-based visualisation and, because EnterpriseWeb understands temporal relationships, you can not only drill down (and across) to individual resources you can also look at lifetime history. Thirdly, it is worth clarifying that EnterpriseWeb processes are ACID compliant and, finally, that the product is stateless so that it doesn't crash.
The meta-information collected by EnterpriseWeb is stored in key-value format which can be stored within a standard relational database as a file or, of course, you can use a NoSQL database. While it does not use a graph database per se you can think of it as a graph store: hence the graph analytics that are supported.
As mentioned, EnterpriseWeb is an Intellectual-Property based Company, which goes to market through partners. It does not have or seek to build a services arm. Rather it has been training partner resources to develop and deliver highly-differentiated solutions for a wide variety of domains.