CeBIT – Shareconomy without connectivity?

06.03.2013 by Martin Kuppinger

Yesterday I spent a day at the CeBIT fair, still the world’s largest IT fair. Besides the many interesting meetings I had previously scheduled, I started thinking about the CeBIT “Leitthema” – their “claim of the year”. This year it has been “Shareconomy”. I still do not know what this term shall mean. There is some fuzzy description at the CeBIT homepage, but in contrast to topics like “Cloud” and “Managing Trust” in 2011 and 2012 respectively, Shareconomy – described as “sharing and using information, resources and experience based on new forms of collaboration” – is a very amorphous concept. They then try to associate it with crowd sourcing, smart infrastructures and smart grids, data security, big data, etc.

In fact, I think that there is something behind this rather strange buzzword. Back in September 2012, KuppingerCole hosted an event about the 4Cs: Communication, Collaboration, Content, and Cloud, which was about enabling new ways of collaboration and communication in a secure way. That probably is what the Shareconomy is all about.

When I look at our advisory business, I see another red-hot topic. In German I’d call it “Umgang mit Dritten”, i.e. how to interact with third parties and services provided by these in a consistent, standardized way. That is about Cloud Security, Identity Federation, API Economy and security therein, etc. Opening up the perimeter and supporting business processes that integrate business partners, customers, etc. is highly important. So maybe that is also part of the Shareconomy. For sure, you will be able to learn a lot about this at our upcoming EIC – the real stuff, not the marketing buzz and fuzz. To highlight just some few sessions:

However, the thing that confused me most at CeBIT – in the context of their Shareconomy claim – was the lack of free WiFi. Sharing without connectivity? Or at least sharing without free or affordable connectivity? Will that work? I doubt it. I used my UMTS cards in the notebook and iPad respectively, because I otherwise would have had to pay 30 € for a 4-hour WiFi pass. That is far more even than in the old school hotels that still charge for WiFi. Ridiculous.

SCIM and the Microsoft Graph API

16.07.2012 by Martin Kuppinger

Kim Cameron recently blogged about his view on SCIM and the Microsoft Graph API. Kim explains his view as to why SCIM and the Microsoft Graph API, which is related to the WAAS (Windows Azure Active Directory), are complementary. That reminded me of two older posts in my own blog:

Even while I didn’t focus explicitly on relationships in the second post but more on the management of entitlements, there is much about relationships in there implicitly. And when looking back at the concept of system.identity (which, from what I see, influenced WAAD and the Microsoft Graph API) it is also about a concept which is much more about dealing with relationships and the ability to model a more complex reality than simply access protocols via LDAP.

SCIM as of now has become widely accepted as a concept and has some likeliness not only to become a formal standard but a real one – one that is widely accepted and implemented. However it appears it will remain a narrowly focused standard (to avoid the term “limited”) which addresses a specific problem. That is fine.

The Microsoft Graph API on the other hand addresses a much broader scope, however focused (as of now) on WAAD. As Kim explains in his post, there is a need for a “multidimensional” protocol like the Graph API which allows dealing with an identity and its relationships.

Like Kim, I see both approaches as complementary, not competitive. You should be able to do what SCIM does with an approach like the Graph API (one that is standardized and supported by many vendors). But that isn’t the core target of the Graph API and the concept behind it. So for the fairly simple use cases of SCIM, SCIM appears to be the solution of choice. For many requirements around dealing with information about identities and their relationships, the Graph API (and maybe a standardized successor in the future) will do the job.

There is though, in this discussion, another point which should be considered: RESTful APIs and JSON are far easier to handle than “traditional” approaches in programming. The evolution of what we call the Open API Economy – you might have a look at Craig Burton’s blog and the KuppingerCole report on this topic written by Craig or the video from the EIC session on that topic – shows that the acceptance of such relatively simple interfaces is rapidly growing. So the need for having only one standard for everything diminishes. There is no doubt that we need standards. But standards are also limitations – LDAP is one example for a limited and limiting standard. I know too many cases where LDAP just wasn’t (and isn’t) sufficient for the business’ needs. Notably it never intended to serve many of these use cases. It was built as an expedient, worked well and then suffered as folks tried to pile on grossly inappropriate functions.

So my recommendation is not to artificially create a “battle of standards”. That isn’t of any value. Having a standardized Graph API in addition to SCIM (and maybe some other “lightweight” standards for specific use cases like a next-generation standard interface to XACML fully supporting RESTful APIs and JSON) makes much more sense to me. Even while I think that the name “Graph API” isn’t well chosen (you need to associate the term “graph” with the “graph theory” instead of the “graph” as in “diagram” or “chart” – so it’s more for the geeks), the concept makes a lot of sense. And SCIM (despite my critics) also has a lot of value in itself.

IBM CastIron – delivering on the promise of the Open API Economy

22.06.2012 by Martin Kuppinger

Some days ago I had a very interesting briefing with IBM on their CastIron products. I had been in touch with CastIron way before they became part of IBM, because CastIron was one of the most interesting start-ups around “Cloud Integration”, i.e. the ability to integrate different cloud services and on-premise applications using the exposed APIs.

Since then a lot has happened. The number of available APIs exploded, as my colleague Craig Burton has described in his report on the Open API Economy. More and more vendors are entering the space and are picking up the term Open API Economy. The concept is increasingly understood, enabling new models and real flexibility, going well beyond the big, fat, monolithic SaaS apps we, for the most part, still find today.

When talking with IBM CastIron, they explained their approach of integrating different pieces into a more complete solution. These pieces are

  • IBM WebSphere CastIron
  • IBM Worklight
  • IBM Web API Services

The latter is software – the full name appears to be “IBM Cast Iron Live Web API Services” – which allows creating, sharing, and managing APIs. So the entire portfolio consists of technology for orchestration (WebSphere CastIron), for integration with mobile devices (Worklight) and for the core features of creating, sharing and managing the APIs (Web API Services). This combination allows supporting different use cases for the Open API Economy, from both the “API consumer” side – i.e. the organizations relying on APIs exposed by others – as well as on the “API provider” side – i.e. the ones exposing APIs. Over time, most organizations will be part of both sides, exposing and consuming APIs.

The IBM Web API Services include security features which allow you on the one hand to enable participation of external developers in building applications based on the APIs and on the other to also control which APIs are exposed to whom. Some APIs might need to remain internal, some might be only available to restricted groups of partners and other users, and some might become public. I also like the management features and dashboards, showing, for example, the top API calls, developers, and applications.

The investment IBM is making in that market is another indicator that the Open API Economy will greatly influence the future of IT. The Open API Economy will massively affect the way we deal with data, allowing us to move from Big Data to Smart Data; it enables the integration of different Cloud environments amongst themselves as well as with on-premise IT; it supports the concepts we’ve described in our KuppingerCole IT paradigm, our guideline for how to embrace and extend your existing IT and get a real grip on the cloud; and it allows us to move from building and maintaining apps and web-sites towards just exposing the APIs, allowing others to build the apps they really need. The latter is worth a little more explanation.

Consider the situation of public transportation today: each provider is struggling with building its web sites and apps for the customer. Supporting new devices and keeping things up-to-date costs a lot of money. By exposing APIs which provide information about the current status, a developer will be able to create an app which indicates when you have to leave your home to catch the next bus or train, based on the information provided by the public transportation service. This could run on your mobile phone, order the ticket automatically, alert you, and add whatever other services you might want to have. It would rely on exposed APIs and could integrate with other exposed APIs – the app could also say: Better take your car, because the busses are delayed but the streets are empty.

I really like to see companies like IBM and others like 3scale, Layer 7 Technologies picking up these concepts. IBM has right now, with the addition of the Web API Services, an offering which covers many different aspects of the Open API Economy and really picks up the concepts of this fundamental change we are observing.

© 2014 Martin Kuppinger, KuppingerCole