If your SaaS product does not have an API then its not valuable

Myself and others at SystemSync Solutions Ltd have spent a lot of time recently looking at Cloud SaaS Payroll systems in the UK. And during that time we’ve also migrated our traditional accounting package (which use to sit in a server in our office) into the cloud. Our findings and experiences from these activities has lead us to understand that if a SaaS product does not have an API then it is no better than a traditional desktop software product.

Here’s why:

Firstly, there’s no financial advantage to using a cloud SaaS tool. Our old desktop accounting package used to cost me a monthly fee to license. The SaaS version is approximately the same monthly fee. 

Conclusion: in this case SaaS gives no significant financial advantage to the customer

Secondly, there’s only a small productivity advantage to using a cloud SaaS tool. True that SaaS can be accessed anywhere (such as from home) but my in-office desktop accounting package was also accessible from home via VPN. It’s also true that cloud SaaS does not require me to install new software versions. But to be honest the job of installing new software versions on desktop software is trivial and reduced to a few clicks. Most desktop software packages do a great job of updating themselves in the background. But it has to be said that one clear advantage from using a SaaS accounting package is that my accountant can access my account on a regular basis to keep my books in order. That’s good for them, but irrelevant for me. 

Conclusion: in this case SaaS gives some, but not significant, productivity advantages to the customer.

Thirdly, when it comes to security there’s no real advantage to using a cloud SaaS tool. Personally I think my companies financial software is now marginally safer then when it was stored in my office. When I moved my accounting package into the cloud I made a choice to trust my company accounts to a very large established business which I believed could be relied on. And at the same time I removed from my own business any responsibility for local security/back-up/access/password management to the server containing my accounts package. But the advantage is small. Security of my desktop accounting software was already pretty good: I know who has access to the room its in; I know who has access to the machine it sits on; I know it cannot be accessed without 2 sets of usernames/passwords which only I know. Plus in the back of my mind I know that SaaS companies store all their customers data in one place meaning if a hacker did get through then they would be able to steal thousands if not millions of companies financial data in one go. 

Conclusion: there’s no real security advantage to using Cloud SaaS.

So if there’s no clear advantage on price, security or productivity for customers of cloud SaaS then what’s left? The answer is data integration. Enabled by SaaS platform APIs.

Using Cloud SaaS tools which have APIs means I can “add on” additional functionality to my SaaS accounting platform. I can link it to other SaaS products I use like time sheets, e-invoicing platforms, e-commerce markets and so on. This helps me reduce my manual data entry tasks. And that gives me real justifiable productivity gains and the possibility to scale my business without getting slowed down by admin.

And that leads me back to my opening sentence of this blog: if a SaaS product does not have an API then its not valuable to the customer because its not helping them move their data around their business. Instead its keeping their data siloed and isolated. Which is a situation that is no better than the old desktop software equivalent. The big incumbent software houses want to move you (their customer) into the cloud so they can stop supporting multiple desktop software versions. I understand why they’d want to do that. But if those same companies don’t also provide an API into the SaaS product then their customers data is just as “locked in” as it is in desktop software.

The UK Payroll market is dominated by legacy desktop payroll software products. But there is a new breed of emerging Cloud Payroll products. But to date I have only encountered one which has an open API: PaySuite. That’s amazing. Its amazing because almost every other software market sector is dominated by SaaS products with APIs which are chaining together to provide seamless data integrations. That seamless exchange of data is eradicating the mundane office tasks meaning that businesses which are adopting Cloud SaaS tools are overnight becoming more productive and efficient (than rival businesses which are not). That means that SaaS with APIs gives competitive advantage to customers who use them. SaaS without APIs does not give any advantage.

Right now my policy on buying cloud SaaS products is “if it doesn’t have an API then I’m not interested”. 

Managing Enterprise Identities in the Cloud.. using an Excel sheet

Last month I travelled to Munich, Germany, to demonstrate a visionary concept at a prestigious IT trade show: the European Identity and Cloud 2013 conference organised by Kuppingercole.

Specifically, we were invited by Craig Burton (Distinguished Analyst at Kuppingercole) who had spotted an opportunity. Craig’s vision was that datownia’s ability to create Cloud-hosted APIs from spreadsheets could be combined with Microsoft’s Azure Active Directory and Graph Store services to drive federated single-sign-on to a mobile web app using an Excel sheet (as the employee register) and Social networks (as Identity verification service). 

• You can see a YouTube demo of our app here: http://www.youtube.com/watch?v=YAUmcPKBdNw
• Access the source code of the project on GitHub here: https://github.com/datownia/waadmanager
• We've published some tech-tips for Developers on Graph Store here.

If you are in the identity management business, and you know about Kuppingcole’s “Computing Troika”, then you will know this concept is a big deal: the frictionless management of employee identities at the epicentre of the three seismic shifts which are impacting businesses today: cloud computing, mobile computing and social computing. 

For the rest of us it means “making it very very easy to administer secure employee access to a cloud-hosted Enterprise mobile app using their Facebook/Google/Yahoo login”. 

So why is this so important?

Metaphorically speaking “Enterprise IT” is under incredible tension right now because its being stretched by unstoppable forces (cloud, mobile and social computing). One of the biggest points of tension is “identity management” which is a subset of “security”. ‘Security’ is the single biggest obstacle thrown up by any and every IT team when their business teams want to use their own devices for work or access amazing features in new cloud apps or just work remotely. 

Identity management is the answer to the question “Who in my organisation (or from other organisations) is allowed to access something (like a cloud SaaS product), and when they get access to that something then what can they do with it (what level of authority to they have)?” The big boys (the global corporates) can afford to spend $250K on a Enterprise Identity Management solution. They can also afford to employ staff to operate that system. The trouble is that 96% of the world’s businesses are SMEs. Those SMEs are exactly the type of businesses which are rapidly adopting cloud, mobile and social technologies. They are exactly the type of business which now has an identity management problem.

Identity management in the cloud/mobile/social world is a real headache for every business. Its a headache because its difficult to technically sort out and it’s difficult to administrate. Identity Management is not a core expertise of most businesses. Yet as soon as an Enterprise ‘extends’ itself beyond its office premises (and the safety of its physical networks, routers and firewalls) Identify Management becomes an issue. Solve the Identify Management problem and you are a long way down the road of helping every business in the world operate securely. And that’s exactly what we did (guided by Craig at Kuppingercole and enabled by Microsoft’s Azure Active Directory and Graph Store services).

Our demo is very simple. It has 2 actors: 

1. a company identity management “administrator” (could be an HR person, or a CEO) and 
2. someone else (could be an employee or a business partner). 

The administrator wants to grant the employee access to password-protected content a cloud mobile app. In our example the cloud mobile app is actually a “conference agenda app” for the EIC 13 conference. The administrator facilitates access to the app by adding the employee’s name, email address and the chosen access level to an Excel sheet stored on their computer. The employee then opens a browser, surfs to the mobile app’s URL and logs-in with the same email address. The identity of the employee is verified by a single sign-on via a social network (either Google Gmail, Facebook, or Yahoo). Once authenticated the user can access the cloud mobile web app but only to the correct degree of authorisation (as specified by membership to the appropriate user group as detailed in the Excel document). End of demo.

High level architecture of WAAD Manager, showing the integration between a cloud app (EIC conference app), social networks (Gmail, Facebook), Azure Active Directory/Graph Store & user data stored in an Excel doc

Behind the scenes things are a little more sophisticated, but not much. Lets walk through it step by step.

1. The Excel sheet is turned into a cloud-hosted API by datownia. 
2. A simple app called “data pump” synchronises the contents of the Excel sheet with Azure Active Directory (for Identity Management) and Azure Graph Store (to store the content to be displayed in the mobile web app)
3. The employee logs into the web-app, which instantly polls Azure Active Directory to make sure it recognises the employee’s email address and then re-directs the employee to their chosen social network. For example Gmail.
4. The employee logs into Gmail, and thereafter is automatically returned to the mobile web-app which recognises the employee as an authenticated bonafide user. 
5. The mobile web-app only displays content or functions which are appropriate to the access level of the user (as stored in Azure Active Directory).

In this way we have made the secure identity management of employees in the cloud as simple as typing data in Excel: something which is within the capability of any business no matter how small. 

Footnote: 
The credit for this concept belongs entirely to Craig Burton who spotted the opportunity to combine datownia’s data sharing APIs with Microsoft’s Azure services. It was his vision and his encouragement that brought it all together on stage at EIC 13.

We’re also indebted to Kim Cameron (Chief Identify Architect at Microsoft) for spending half of his key note speech at EIC talking about this demo and telling the audience of CIOs it was the shape of things to come. And finally to James Baker, Technical Product Manager at Microsoft, and one of the brains behind “Graph Store”, for supporting our dev team as they put the demo together. 

Tech tips for working with Azure Graph Store

In April 2013 Release Mobile built a demo app using Windows Azure Graph Store. We put this tech blog together to share some tech tips on using GraphStore.

The project objectives:

We built the Windows Azure Active Directory "Manager" app in collaboration with Kuppingcole and Microsoft to demonstrate how single-sign-on access to a mobile web app (in this case a replica of the EIC13 conference all) can be governed, via Azure Active Directory, by information held in an Excel doc. The user identities are authenticated by Social networks such as Facebook, Google and Yahoo. 

The project had three aims:

1) Present a vision of the future in which access to Enterprise Cloud apps are securely managed by single-sign-on authentication facilitated by Social Networks.

2) Present a very low-friction method for Enterprises to manage their employee identities, using Azure Active Directory, Excel and the datownia.com API-as-a-Service app

3) Demonstrate how Azure Graph Store is a multi-function schema-less data management service that can be used to both extend Active Directory and to hold App data.

Resources:

• GitHub source code for the project: https://github.com/datownia/waadmanager
• YouTube walkthrough of the app: http://www.youtube.com/watch?v=YAUmcPKBdNw
• URL of the web app itself: http://waadmanager.cloudapp.net

What is Windows Azure Graph store?

• A Graph store is a named data store, containing data tuples.  These are identified with a compound key (_Item1 & _Item2) and have a value property, capable of holding complex data types.

• The Windows Azure Graph Store is an extension of the Windows Azure Active Directory Graph (https://graphstoreapp.windows.net/documentation.aspx).

• The tuples are formatted in JSON.

• It is managed by a RESTful API.

Pre-Requisites

• In order to start using a Windows Azure Graph Store, you will need an Azure subscription and an Active Directory Tenant http://technet.microsoft.com/library/jj573650.aspx.

• More details on pre-requisites can be found here: http://msdn.microsoft.com/en-us/library/windowsazure/hh974464.aspx

How to access a Graph Store

Consider this URL: https://graphstore.windows.net/myTenantDomain.onmicrosoft.com/myGraphStore/id1/id2

• This is an example of  a URI to a tuple with item identifiers “id1” and “id2”, within the “myGraphStore” named graph store of my active directory tenant named “myTenantDomain.onmicrosoft.com”

The resulting object might be of the format:

{

"_Item1" : "first item",

"_Item2" : "second item",

"AttributeName" : AnyPrimitiveValue,

"ComplexAttribute" : {

"AttributeName" : "value",

"AttributeName2" : "value2"

},

"AttributeCollection" : [

{

"Attribute1" : 100,

"Attribute2" : true

},

{

"Attribute1" : 200,

"Attribute2" : false

}

]

}

• Http operations to manage data:

Action HTTP Operation

Create POST

Update MERGE

Replace PUT

Delete DELETE

• Posting a new tuple to a non-existent graph store will automatically create the store and tuple.

• Permissions on a graph store are managed via a permissions document which can be found at https://graphstore.windows.net/{tenant}/{graphstore}/$permissions

• The permissions document specifies the name of claims that must be present in a bearer token obtained from Windows Azure Access Control Service (ACS). For information about obtaining access tokens from ACS, see the following link; http://msdn.microsoft.com/en-us/library/gg429786.aspx. 

• If anonymous access is permitted to a graph store via the permissions document for a given operation (AnonymousRead or AnonymousWrite are true), the REST request need not include an access token.

Extending Active Directory

• Each AD Tenant has a specially named graph store called “graphextension” which is used to add properties to AD entities.

• For example, to add a property named “programme” to an AD User entity, you can post the following:

{

"_Item1" : "users",

"_Item2" : "programme",

"OwningTenant" : " myTenantDomain.onmicrosoft.com",

"ValueFormat" : "{graphstore}/targetGraphName/{id}/programme"

}

Then, calling: https://graph.windows.net/ myTenantDomain.onmicrosoft.com/Users('joe@mytenant.com')/ myTenantDomain.onmicrosoft.com /programme

will return  the url:

https://graph.windows.net/ myTenantDomain.onmicrosoft.com/targetGraphName/joe@ myTenantDomain.com/programme

When this url is called, the joe@ myTenantDomain.com/programme tuple is returned, containing the extended data.

Querying the graph store

A data tuple is identified by a tuple id.  It is possible to use wildcards (*) in place of item1 or item2 in order to return a concatenated result set.

thanks Ovais Oozeer @ Release Mobile Ltd for providing the tech tips for this blog.