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.
The environment supports but is not limited to REST, SOAP, WSDL, JavaScript, JSON and so forth and can be deployed in private, hybrid or public clouds. The product has a multi-tenant architecture. Security capabilities are built into the product. EnterpriseWeb has a small footprint (15mb) and has few requirements (Servlet Container, SQL or NoSQL database of choice). It can deploy on dedicated servers, VMs and Containers. It can also be embedded in appliances and devices.
