Is 'bollocks' the B in BYOD?

This excellent post by Brian Katz exposes some myths about BYOD: http://www.ascrewsloose.com/2012/05/30/byod-required-for-retention-bollocks/

In particular, this part:

The fact that you have your own device will do absolutely nothing to keep you at your company. In many ways it actually makes it easier for you to move on as your most personal piece of technology is now your own, you will not lose it if you leave. http://www.ascrewsloose.com/2012/05/30/byod-required-for-retention-bollocks/

Yes. It is a very narrow view to think of BYOD as just about "retaining employees". Making employees more productive is much more than just stopping them leaving.

Later, he explains that the key to enabling BYOD all about enabling access to data using APIs:

It is freeing your data by building APIs to access it, involving identity management to make sure the right people can access the data through the APIs, and then building apps which are focused on the task at hand that allow the employees to turn the data into information that they need. These apps have to be built with the user in mind; they need a great user interface (UI) and user experience (UX). They will allow the employee to use the device they have at hand to be more productive and efficient wherever and whenever they would like. http://www.ascrewsloose.com/2012/05/30/byod-required-for-retention-bollocks/

Like so many problems, it's really all about the data. And how is the data accessed? Through APIs. Rather than sitting on devices, the data is available through APIs which can be managed and controlled using identity management.

A great blog post and well worth reading.

ProgrammableWeb: Enterprise APIs: Where to Now?

I've written a guest post on ProgrammableWeb on enterprise APIs: http://blog.programmableweb.com/2012/05/23/enterprise-apis-where-to-now/

It includes info on:
- Key stakeholders (developers, API owners, partners)
- Differences between consumer and enterprise APIs
- Reference architecture

The important of root cause analysis for APIs

I've written before about the relevance to Cloud of the famous Leslie Lamport quote that "a distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.” In the case of APIs, it's also relevant. When an API Gateway is delivering APIs out to clients, such as mobile apps, it needs to provide root cause analysis of any API faults. If an API is returning back the error, it's not enough to just flag this; what you really want is information on why the error occurred. This is the root cause analysis requirement.

APIs generally are deployed in front of existing systems, such as a legacy SOAP service. If the legacy SOAP service returns an error, then that impacts on the REST API which depends on it. That legacy SOAP service itself is probably just a facade into another system (an app server, for example). And it may be the problem If you're just providing management at the API layer, you don't have the ability to provide root cause analysis, to go from "This API has an error" to "This API has an error because we know it depends on this other system which is misbehaving".

We see this benefit spelled out in the Vordel case study for 3 (a mobile telco in the UK).  The case study spells out that:

Root Cause Analysis: The Vordel Reporter reporting structure provides the way to identify common failure points in multi-service transactions. This means that if one service is failing, and impacting the transaction as a whole, the Vordel infrastructure detects this and notifies 3.
http://www.vordel.com/customers/3.html

Root cause analysis is an API delivery requirement which separates out the management of just the API from the management of the application itself. 

Dzone article: API Gateway support for HATEOAS ('Hypertext As The Engine Of Application State')

Dzone published my article on API Gateway support for HATEOAS ('Hypertext As The Engine Of Application State'), code samples and all - linked below:

Pure vs Practical REST

This is a useful table I often go back to, comparing pure REST (such as HATEOAS) with the "practical" REST so often found in the field:

Panel at CTIA today - Tablets in the Enterprise: Increasing Efficiency and Productivity

My colleague Ed King is speaking this afternoon on a panel at the Future of Tablets event at CTIA in New Orleans today on " Tablets in the Enterprise:  Increasing Efficiency and Productivity". Check it out if you're there. Here's the info:

3:30 - 4:30 SuperPanel: Tablets in the Enterprise:  Increasing Efficiency and ProductivityTablets are one of the most exciting technologies to hit the enterprise in some time and they are sparking a wave of innovation, especially in terms of mobile apps. We will examine the future technologies and applications that will drive the enterprise market including BYOD (Bring Your Own Device)

Dimitri Volkmann Vice President of Enterprise Product Strategy & Planning - Good Technology

Ken Parmelee, Sen. Dir. Product Management - Antenna Software

Bryan Whitmarsh, Mobility Solution Manager -SAP
Ed King, Vice President of Product Marketing - Vordel
Leila Modarres, Senior Director of Marketing - Keynote DeviceAnywhere

Job posting: Gateway, SAML and Federation skills: Reading, UK

UK-based readers of this blog might be interested in this one: Computer Futures in the UK is looking right now for two Oracle consultants skilled in SAML and federation. Location is Reading. Vordel skills are specifically mentioned. Check out the job listing and apply here...