MenSagam solves the challenge of accessing data across different cloud applications and APIs in two ways. First, it provides a standard way to access all data through structured query language (SQL) by translating SQL queries into the appropriate requests for each underlying API. Second, it allows for data virtualization where a single query can retrieve the necessary data from multiple sources without the user needing to understand where the data is located across different applications and schemas.

2. The big challenge as more data moves to the Cloud–all in different
applications, with different application programming interfaces (APIs)–
is that access to the data becomes incredibly complicated. Not only
do I need to understand what applications the data I want sits in, but I
also need to understand what the APIs of those applications are and
what kind of capability those APIs have. For the user or the
application developer to get at the data, they have to have a very
deep understanding of all the applications they want to access.

3. The first way is that MenSagam provides a standard way to access all
of the data across applications. You send us structured query
language (SQL) and then we translate that SQL into what the
underlying APIs understand. Some APIs only give a certain record
with a particular primary key. For some, you can ask a broader
question such as requesting all records where state equals California
and average value is equal to at least ten thousand dollars. With
MenSagam, you send a simple SQL request and we will translate it
into what those two underlying applications understand. Now, the
developer or the user does not need to understand or know what the
capabilities of those different APIs are.
MenSagam solves this problem in two
ways.

4. The second way is that MenSagam allows you to create data
virtualization. In the complex schemas of the one to five SaaS apps
with which I am dealing, to get the right answer to the question, I
obviously have to understand what data I need to get that answer. For
the typical user, understanding all those schemas is very complicated.
We allow you to create a data virtualization object, question, or query
that requests all customers and their orders for 2012. That query can
then go out to the four different sources that contain the data and
answer that question properly. The user does not have to understand
that this is table X in application one, table Y in applications two, etc.