It’s a matter of convergence

I’ve been hearing a lot more lately about Social, Mobile, Cloud, and Big Data as a combined theme lately. But it often feels like the combination is used more for convenience, or to discuss them as coincident trends. But the real story is that combination of these emerging capabilities is the actual change agent. Any of them alone is an exciting opportunity, but converged together, they enable things only imagined previously in science fiction. In a lot of ways, it starts with mobile, but not just delivering mobile apps to customers. By mobile, I mean distributed and mobile presence delivered through mobile devices, sensors, and connected “things”. The universe of these connected things is expanding at an alarming pace, providing an unprecedented fabric of sensory awareness that can produce more insights than anything we’ve seen before. But we’ve had sensors for years, so what has changed is the second trend – big data. Big data gives us the ability to glean insights out of this deluge of information, so that we can actually do things based upon it – make decisions, improve interactions, reduce inefficiencies, react to business stimuli. The third trend, social, provides new channels for interaction, but also adds more context to what we know about customers and employees and products, and helps to connect this big data together in new ways. These insights can be transformed into actions at the point of impact by feeding back to those mobile devices. The fourth trend, Cloud, provides affordable computing power on demand, to enable all of this. When everybody has a supercomputer’s worth of computing power at their fingertips, all of this becomes possible.

That’s what we’re talking about at IBM Impact in Las Vegas this week. Join in the conversation by following #ibmimpact on Twitter. See you there.

Malware on Mobile Grew 163% in 2012

Darrell Etherington of TechCrunch posted a new study by NQ Mobile that reinforces the growing problem of security issues surrounding mobile. The report found that more than 32.8 million devices were infected in 2012. Over 25% of the infected devices are in China. It just isn’t realistic to assume that the mobile devices accessing your APIs are not infected…

Protecting Against JSON-Bourne Attacks

Mobile has become the new #1 target for hackers and cyberattacks. As more consumers and businesses become more comfortable conducting business over mobile devices, this becomes a natural target for the baddies who want to steal personal information, or just disrupt business. And if you believe what the experts are saying, you need to be prepared that your mobile phone will eventually be hacked…  With the number of incidents of malicious code (particularly on Android) increasing by the day, it is vital that your organization is prepared.

That’s JSON-bourne, not Jason Bourne…

One of the main targets is not actually what is sitting on the phone, but instead the services that the app is accessing on the back end. These services present APIs that mobile apps invoke to get and put information into back end systems. In the mobile world, most of these APIs use a simple and concise data format called JSON to transmit this data and these requests. While most organizations protect these APIs using traditional firewall technologies, many are not doing enough to protect themselves from malicious content hidden in the JSON. According to IDC, “signature-based tools (antivirus, firewalls, and intrusion prevention) are only effective against 30–50% of current security threats.”

A similar issue arose in the height of SOA adoption, where protection against XML-bourne attacks became standard practice, but with the rise of mobile and lighter weight RESTful services, organizations need to shift to make sure they are protecting themselves against new threats.

The problem is that it is fairly easy to inject malicious content, buried in JSON data, into a seemingly innocuous REST call. Unless the malicious content matches one of the signatures that your firewall is watching for, the content will get through to the server, where it can be made to automatically execute as server-side Javascript. Since this code is generally executed in a less-protected area, it often has access to sensitive back-end systems, where it can do more damage or compromise private information.

Luckily, there is a way to protect against these threats without relying solely on good programming practices. Some of the same security gateways that organizations use to protect Web services can be easily extended to protect JSON/REST services. The best of these (like WebSphere DataPower) can be delivered as secure hardware appliances that prevent unauthorized tampering and provide FIPS 140-2 Level 3 certified protection. These gateways work by inspecting the data payloads and finding and filtering out suspect JSON data (among other things), providing a much deeper level of protection than traditional firewalls alone.

When you take a look at the OWASP top 10 threats, many of these remain relevant in JSON-centric applications. For example Cross-Site Scripting (XSS) and Cross-Site Request Forgeries (CSRF) are still concerns. In addition, hackers can inject very large JSON documents that can cause massive slow-downs in the systems that process those messages. However, the biggest threat is script injection – one that is a bit more specific to how JSON is processed in Javascript, and one that enables direct execution of functions on infected servers.

With all of the focus and spending on Mobile security, organizations need to be considering this threat as much as they are the threats to what is resident on the phone itself. I don’t think this has sunk in for many organizations, yet. Is your organization ready?

An Internet of Things Hub for the Home

An Internet of Things Hub for the Home

Here it comes… Stacy Higginbotham has a nice post on Securifi’s touch screen Almond+ Router based on Zigbee. I want one.

It all changes when “things” get APIs

I’ve been spending an inordinate amount of time focused on the “Internet of Things” lately. I am impressed by how much buzz IoT has been getting lately, with a new connected device seemingly emerging each day. We’re in the early days, but things are moving fast.

In these early days, it seems that most connected “things” are producers of information. Sensors of many kinds are being deployed to collect information on all manner of things. Big data promoters and doomsayers alike rightly point to this information deluge as world-changing, allowing us to achieve an extra-sensory awareness of what is happening around us that opens up infinite new possibilities.

But it occurs to me that things will really get exciting when “things” expand beyond being just data producers, and begin to expose APIs that allow them to be controlled remotely. When a sensor can tell that a motor is overheating, that is good. When the overheating motor exposes an API that allows it to be remotely slowed or shut down automatically before it is ruined, that is even better.

We’re not that far away from this, really. Many of the new connected things are built to be controlled remotely, some with simple Web APIs. And with technologies like MQTT, it is relatively easy to retrofit traditional connected things to be controlled remotely. I think the next wave of consumer device innovation will focus on this – everyone will want a device router (or hack their Linksys router to act as one like T-Rob did), and everyone will expect their new appliances and consumer electronics to be connected so that they can tell you when they are having problems, and of course, be controlled remotely through an API.

“Did I turn off the dryer before we left?”

“I’m not sure – check your home control app”

It’ll be here before you know it…

Reliable messaging for mobile apps

James Governor wrote a nice post on Facebook’s expanding usage of MQ-TT. I’ve written about WebSphere MQ’s native telemetry transport (MQ-TT) capabilities in the past. The fact that Facebook is using MQ-TT protocol isn’t new news, they have actually been using it for their Facebook messenger capability for years. However, the fact that they are expanding their use because of the benefits of the protocol is definitely an encouraging development.

“…this week Facebook announced it would stop offering lame mobile experiences by offering a new native IoS client… and it is deepening its commitment to MQTT”

Read more: http://redmonk.com/jgovernor/2012/08/24/facebooks-new-native-ios-client-a-kingmaker-for-mqtt-ibm-facebook-no-shit/#ixzz25Wc7YcGf

With Facebook expanding their usage of MQ-TT, I would think it is a safe bet that MQ-TT is the dominant real-time messaging protocol for mobile apps. It isn’t surprising that other software vendors like Software AG are announcing support for it.

I talk to at least one organization every week who is looking for reliable real-time messaging between mobile apps and on-premise systems. Most customers are not wholesale adopting WebSockets yet (some because of compatibility concerns, some because of security and reliability concerns, some because of server resource usage concerns). Usually when I tell them they can simply extend the industry’s leading reliable messaging platform (WebSphere MQ) out to mobile devices, using the same management tools and skills they use today, they are both incredulous and thrilled. Add to that WebSphere MQ’s inherent security and reliability benefits, and the ability to support models like pub/sub, and you have a much more complete solution.

The benefits of MQ-TT are extraordinary when you consider battery and bandwidth usage. As compared to HTTPS polling on an Android 3G, MQ-TT has 93x higher throughput with much lower latency, while consuming 1/10th the bandwidth, and well over 10x less battery usage. The scalability of the protocol is probably best evidenced by Facebook messenger’s use, given they have over 350M mobile users.

Enterprise Service Cloud in China

I am in China this week, meeting with customers and partners, and presenting on “Next Generation SOA”. Although China embraced the original wave of SOA, companies here are very quickly extending SOA into new areas. For example, the concept of Internet of Things is extremely advanced here, with most manufacturers instrumenting their equipment to enable better, more proactive response to maintenance issues. SOA is the underlying fabric of this.

While in Shanghai, I had the opportunity to meet with one of our China SI partners, Cap Gemini. They have coined the concept of an “Enterprise Cloud Bus,” which is a layer outside your ESB that exposes services and apps to the outside world. I like this thought, though I think “Enterprise Service Cloud” may be a better name. The idea is that there are sets of services and APIs that organizations want to expose internally and externally. These services may be traditional XML/SOAP services, or they may be JSON/REST services. They may interface to a combination of internal and external applications (cloud and on-premise). These same services can be used across multiple channels: internal applications, Web, partner applications, mobile, open APIs, even devices. Hence, the same service may have multiple interfaces and policies, and may even be presented as an open API rather than a traditional service.

We implement this pattern all the time, though often this layer is not called out separately from the ESB. However, the security and policy management requirements it raises, along with the need to support unpredictable load spikes due to the various ways the services can be accessed, make it prudent to look at this as a separate layer, even though technically many of these capabilities can be handled directly in the ESB. In fact, this concept originated with ESBs, which largely started out implementing service facade patterns on top of proprietary applications. The primary difference (and why many ESBs fail to enable this properly) is that the consumption model has become much more complex while the protocol has become markedly more open. As service/API consumers become more varied and plentiful, and more unknowns creep in around things like who will access, how, and from where, planning for this layer becomes imperative, and simply assuming your ESB provider can do it well is not a safe bet (even if they say they can).

Integrating SAP with Saleforce.com

The race to SaaS has been impressive as SAP, Oracle, and Microsoft have scooped up a variety of SaaS vendors over the past 12 months. Meanwhile the SaaS vendors presumably deemed too expensive to buy, like Salesforce.com and Workday, have continued to thrive, beginning an acquisition wave of their own.

SaaS has clearly gotten the attention of the big application vendors like Oracle, which has bought SaaS plays Taleo and RightNow in recent months. In fact, Larry Ellison even (surprisingly) mentioned wins against Workday on his last earnings call. And in a typical display of Oracle Math, Mark Hurd claimed that Oracle is the second largest seller of online applications. Whether or not you drink the coolaid, it is clear that Oracle, SAP, and Microsoft are moving to SaaS, and moving there fast.

However, Salesforce.com continues to dominate the SaaS space, at least for salesforce automation, eating a big chunk of revenue out of Oracle’s former stronghold. I am continuing to see more and more companies of all sizes choosing Salesforce.com, many of them SAP and Oracle stalwarts. The good news for IBM is that whenever organizations choose one of these applications, they need a way to easily integrate it back into their on-premise systems. There is nobody better at this than IBM.

A great example of this is Philips Healthcare, who combined SAP and Salesforce.com together in less than two weeks using IBM technology. Stefan Katz, Director of Application Architecture at Philips, will be discussing this on a great upcoming webinar on June 22 at 10AM PT. I encourage you to register and check it out: Register Here.

Its Official… Microsoft Will Disrupt the Mobile Market

The reports creeping out from Microsoft’s media event in Hollywood this week are clearly exactly what Microsoft was hoping for. With their release of the new Surface tablet, Microsoft is back in the game. Although this puts some strain on their hardware vendor relationships with long-term partners Dell & HP, it firmly plants them as a player in the mobile tablet space.

Image courtesy of Microsoft

According to Bloomberg analysts, Microsoft may quickly capture 10% of the tablet market. As my earlier post surmised, I believe that Microsoft’s establishment in the business world, and their enormous Marketing machine, will quickly make them the #3 player. Like Apple, their ownership of the operating system and the hardware give them a distinct advantage. Unlike Apple, Microsoft’s dominance on the desktop may make them a more natural choice for businesses.

In any case, Microsoft can no longer be ignored. I expect the app developers to flock there quickly.

Monetizing APIs

Publishing open APIs is one thing, monetizing them is another thing altogether. So how can you make money by publishing APIs?

Adam DuVander of ProgrammableWeb published an excellent blog post on exactly this subject. The Intuit – Twilio story is a great example of how a new economy is evolving around this concept. While Twilio have based their entire model on usage-based charges on open APIs, Intuit has used APIs to enhance their existing services.

“So the story goes, an Intuit employee was checking out the Twilio API documentation on a Friday afternoon. Intuit is a large payroll and accounting software company that wouldn’t have been on Twilio business development’s radar, at least not back then. The Intuit employee looked at the public docs, signed up for a trial account and spend the weekend creating a prototype. On Monday she shared a system that now performs payee verification for the millions of employees processed by Intuit’s systems. All while the team from Twilio was none-the-wiser.”

Though Adam raises multiple other models for monetizing APIs, I think these two will be the predominant models in the market for some time. However, some experts predict that this economy will quickly become much  more dynamic.

Kin Lane posted his presentation from Gluecon that suggests the API economy will change much more dramatically, including the emergence of developer unions and social coding models. There are some really interesting thoughts here, so I suggest you take a look.

Amongst other things, Kin notes that SaaS and PaaS models will emerge that focus specifically on APIs, and that open source tools will emerge for publishing APIs and embeddable widgets. Some of this is already happening, but the possibilities are pretty exciting.

One of the amazing things that Kin points out is how far the API publishing world is ahead of the governance model that typically controls these things. Unlike Web Services, that for years was gated by standards emergence, APIs have flourished in a “Wild West” setting that has encouraged rapid evolution and proliferation, but left gaping holes in some areas. Specifically he notes that service and structure standards have yet to emerge, and that privacy and security are trailing current implementations.

That said, the API Management offerings in the market provide answers to many of these holes, which I believe is facilitating adoption by many large enterprises that would otherwise shy away from the risk.