Why enterprise mobile applications need an mBroker – part 2

mobile marketingThis is the second in a series of posts about the mBroker, an essential component of enterprise mobile application deployments.

The previous post discussed the general need for broking services to handle differences in mobile and corporate application environments. In this post we will look more closely at the security issues that mBrokers address.

Mobile applications are often written in the REST style using JSON as a format, because these mechanisms are simple, lightweight and perfect for the limited resources available to mobile devices. However, when these applications need to use corporate applications and APIs it can open a number of security holes. For starters, in the corporate SOA world integration is usually addressed through SOAP-based messages and web services. SOAP messages are usually encrypted, and there are extensive security protocols built into the web services standards specifications such as WS-Security. But the REST style of programming has little in the way of security protection; after all, REST is basically calling up URLs in a similar fashion to when you are surfing the net. This means that data may be ‘in the open’ and therefore exposed to prying eyes, and also intercepting the data and injecting malicious content is relatively easy.

The mBroker security services address these issues. For example, policies can be put in place so that sensitive information can be detected and secured, and the traffic can be scrutinized on entry to the corporate network for any injected threats or attacks. For example, content might be restricted to a small set of QueryString parameters, headers may be inspected to identify the type of data expected, and so on.

The other tricky aspect of securing enterprise mobile applications is the authentication and identity management area. As touched on in Part 1, OAuth is a loose standard providing a mechanism for delivering a level of authorization in the mobile world. In essence, resource owners authorize other services to use only that set of resources required for the task. The idea is that instead of having to log in everywhere, exposing your userid and password to different third party systems, the OAuth mechanism enables you to share a token with the service providers that restricts access. However, OAuth is quite new. OAuth was a typical web-based user-driven project which has now been developed, with OAuth 2.0, into a wider reaching standard specification. Not all of the web community are in favour of this wider direction, and the fact that OAuth 2.0 is not backward compatible with OAuth has not helped the situation at all. As a result different third party environments may not support OAuth at all or may support different levels.

Again, this is ideal territory for the mBroker. The mBroker can provide consistent OAuth implementation across all services, as well as bridging between OAuth and non-OAuth forms of authentication as required.

So mBrokers provide the mechanism to ensure that mobile enterprise applications do not compromise your corporate security goals.

Will mashups mash up your infrastucture?

One of the forecasts in the Lustratus predictions for 2008 Insight, available free of charge from the Lustratus web store, deals with the emergence and adoption of mashups.

At this moment it is unlcear how fast mashups will be adopted, but Lustratus thinks that any serious adoption will place massive strain on enterprise infrastructures, causing the unwary to buckle and collapse.

Mashups seem great. The user is suddenly in a position to create his or her own page layout with all the business applications needed to carry out this user’s activities. A great productivity boost, perhaps, but what are the impacts on the enterprise? Basically, as Lustratus points out, every desktop becomes an application. Instead of an IT department having to worry about 10 or 20 applications, all of a sudden there are 100s or even 1000s. Worse still, while traditional IT-controlled applications are usually controlled fairly rigorously with procedures, policies and management practices, the world of mashups could well be more akin to anarchy.

Fundamental to a productive mashup will be the need to drive the different business services required by the particular user, and therefore services will suddenly become tools used by hundreds in many different ways. All of this activity could create huge traffic increase as well as a generally uncoordinated style of operations, causing major difficulties for the infrastructure software trying to hold everything together.

Well, OK, maybe this is a little negative – but the point is, enterprise architects and management should start considering these issues now. Trying to sort this out when the genie is out of the bottle will be a lot more difficult…..

Steve

Putting the suit on Social Computing

I have previously written about the application of Web2.0 technologies to enterprise problems at a general level.

In the past, I have taken the view that the Web2.0 technologies may be of interest, but the enterprise application of the ‘social computing’ side of Web2.0 was still very immature: the general value of collaboration was clear but how it would be implemented and which pressing business problems it addressed were not.  This lack of maturity was reinforced by fighting talk from some Enterprise 2.0 proponents about changing the way enterprises work by up-ending hierarchies and claiming that when the “facebook generation” moves into the workforce all will be changed.

However, I think that the concept is now maturing as can be seen from announcements from both BEA and more recently Progress around what BEA calls Enterprise Social Computing and Progress calls Socially Oriented Architectures.  What is promising is that both announcements focus on the application of social computing (and it’s ability to enable fluid communication and information sharing) to solve business problems.  In the case of ESC (an acronyn to make any tech marketeer smile), the application is to the area of process improvement.  As my colleague, Steve Craggs explains in his new insight on ESC and SOA (which is free to download at the moment!):

“If a company can understand a little more about how employees are solving their day-to-day work-related problems, it should become possible to establish best practices or carry out training to improve employee performance. The traditional approach to solving this problem is to engage an external business process re-engineering expert. However, these experts are both expensive and disruptive. In many cases, the best practice expertise is already there—it is just that it is un-communicated, locked in the heads of one or more expert employees.”

And of course, it isn’t a huge leap to realize that SOA is a fertile place to start using such an approach – as this requires a high degree of communications across organizational boundaries and involves tech-friendly staff more likely to adopt new concepts like ESC.

Ronan

Web 2.0 and Enterprise 2.0: What’s that?

A recent item on SearchSMB provided an excellent piece of sanity counter-balancing the hype around Web 2.0 and starting to bubble up around Enterprise 2.0.

A speaker at the IDC IT Forum and Expo in Boston asked his audience how many of their employers were using Web2.0 technologies: The answer zero. The writer points out that this is in stark contrast with IDC findings that around 45% blogs, 43% RSS and 35% wikis (the core technology components of Web2.0 by most definitions). Unfortunately, he goes on to claim that the divergence is because rogue users are experimenting without telling the IT managers – a conclusion which I find a little implausible. It seems more likely that the 0% rate is probably too low but the other findings are much too high (reflecting the usual over-statement when asking people soft questions like ‘experimenting’ and ‘piloting’ or ‘planning’ as I have previously blogged about).

Of course, there is real value in Enterprise 2.0 – taking the Web2.0 technologies and philosophy of user engagement and putting them into the work context. As a starting point, I would mostly ignore blogs, and instead focus on wikis and RSS and of course AJAX-based mash-ups if you regard them as part of the web2.0 palette. For those of you who have yet to get to grips with Web 2.0 concepts, look at the now famous and still excellent article by Tim O’Reilly here. On the Enterprise 2.0 side, Don Hinchcliffe has a blog worth tracking.

Ronan

SOA: Slowly breaking the IT innovation bottleneck?

So often discussions about SOA return to the subject of how to communicate the SOA message to business, convince them to invest and to have faith in the opportunities that SOA can generate.

In these discussions, the CIO is often held up as both the potential champion and the potential bogeyman.  A bogeyman in the sense that they are sometimes considered to be the blockers to innovation.  SOA proponents sometimes mutter what some Web2.0 proponents shout from the rooftops.  As Chris Anderson, inventor of the Web2.0 “Long Tail” concept put it recently:

“CIOs, it turns out, are mostly business people who have been given the thankless job of keeping the lights on, IT wise. And the best way to ensure that they stay on is to change as little as possible.”

Chris is right in pointing out that there is an underlying problem with enterprise IT and innovation.  However, I think it is simplistic to point the finger at CIOs and their perceived defence of the status quo.  Rather I believe Christopher Koch is much closer the mark in his excellent piece titled “Oh right, we forgot that CIOs are unimaginative as well as being fat, lazy and reflexive” (I couldn’t resist repeating the title).

“The predominant view, even in companies that claim IT to be “strategic,” is that the business owns innovation, not IT”

To put it another way: We may be able to reel off the IT successes that transformed the business from Walmart’s supply chain management to Fedex packaging tracking.  However, these are exceptions rather than the rule.  In many if not most cases, business managers simply do not believe that IT can be an engine of significant change and do not expect or even want IT to innovate.  Partly, this is a cultural legacy with organisations not realising the degree to which their business is IT driven.  It is also partly a cultural legacy of IT departments, only too willing to stay in their comfort zone.  As Christopher puts it:

It’s time for CEOs and business management to acknowledge that just as their businesses are now completely reliant upon IT, they are more reliant on the geeks to help them innovate. And the geeks need to worry less about development languages and start worrying more about the business.

Obviously, it is also due to the technology legacy we are all familiar with which makes change hard and running to stand still enough of a challenge for many.  To quote from Christopher again:

“As long as we persist in the naïve assumption that CIOs should be able to use 10-20 percent of their budgets to create a constant stream of breakthrough innovation on top of a creaky infrastructure that consumes nearly all of their management time and staff’s attention, we will not have significant progress.”

Is it all too bleak?  Business regards IT as plumbers and IT is spending all of its time and resource patching leaky pipes.  Of course, this situation is precisely that which leads to the enthusiastic acceptance of the SOA concept by enterprise IT:  IT embracing the need to align with business and SOA providing the groundwork for a more agile environment and hence potentially facilitating a steady stream of small and well-targeted innovation.  To quote Christopher, a final time:

“These small innovations add up, but more importantly, they can change more quickly, giving CIOs something they’ve never known with traditional applications and infrastructures: a measure of agility.”

This is precisely what we begin to see in organisations successfully moving along the SOA adoption path:  CIOs, who have gained sufficient agility, can begin to play a role in driving innovation and a role in business strategy.  However, this may take a long time in many organisations as it requires both delivery on the promise of SOA and a revolution in the perception of IT by business managers.  And we must accept that during the process, there is no point pointing figures at the champion or other people who “don’t get it”.

Ronan

Web2.0:”Stuff of the future” or “Stuff and nonsense”

Spurred by Steve’s remark dismissing Web2.0 technologies as flaky,

I thought a few words in defence of Web2.0 would be worthwhile (a subject I have written about over the last year in my ebizq blog ). I should however state that I have no sympathy with the hyperbole and bizarrely anti-enterprise IT attitudes of some Web2.0 evangelists such as David Girourard of Google who says:

“Enterprise software is entirely bereft of soul. It is designed for business not for humans.”

Or the respected Enterprise Web2.0 visionary, John Hagel, who back in April stated that SOA had failed because

“SOAs were hijacked by an alliance of CIOs and IT consulting firms, each with their own reason for extending the effort required to deploy SOAs.”

And then went on to propose the way to getting over this problem for Web2.0 is:

“First, Web 2.0 technologists need to work on connecting directly with line executives of large enterprises without trying to go through the IT departments.”

Man the barricades, business line executives all you have to lose is your IT chains!

However, Steve’s skepticism is valid: Much Web2.0 technology is immature and hard to use. As he mentions, anybody who has set up a blog with RSS feeds (both of which are well established Web2.0 technologies) will know that it can be surprisingly tricky and unpredictable: Not the usual characteristics of a technology that one would consider unleashing on those disinterested in technology – the type of people that some claim Web2.0 technologies should appeal to!

However, as with any new wave, some of the Web2.0 technologies will mature and gain ground in the enterprise while others wither. One of the ground-gainers is enterprise wikis because they provide real value. Now, I am not saying the wiki tools are perfect but they are good enough and good enough is a key metric: So long as they are good enough to use, for most people that is sufficient if they can see the value. Using enterprise wikis to reduce the mountain of email with yet another version of a project plan or discussion document attached is clearly a good thing. When you can do it with little cost and little need for IT department to handhold, better still!

A web2.0 guide is next on my task list – so expect more this subject soon!

Ronan

The CIO challenge in 2007: Innovate but spend less money – suggestions welcome!

According to…

…a sneak preview of CIO magazine’s annual state of “State of the CIO” survey the challenge is

“Innovate and grow [the business], but be very buttoned down when it comes to costs, risks, security and regulatory compliance.”

Also quoted in the article is Gartner CEO Gene Hall who says:

“many CEOs believe that their CIO is [too] cost-focused and not capable of contributing to growth—and they need IT to contribute to growth”

It sounds a little like the old “work smarter, not harder” approach is the only way out of the double squeeze to deliver more with less. So how can CIOs regain the innovation habit that might have been stamped out while cost cutting was the only virtue. Well here are three quick ideas on how to simultaneously innovate and spend less money:

Obviously, SOA is a key candidate as Steve points out: SOA is an architecture which supports software as a service/service outsourcing (i.e. reduces costs) and also increases internal agility (i.e. increases agility and hence supports growth).

Something that may sound a little surprising when first raised is investing in hardware upgrades . Not only will this increase the processing power available, more importantly it will reduce the power bill by phasing out old power hungry machines.

I would also look at some of the Web2.0 technologies and in particular wikis. While they may be less sexy than the horribly named “enterprise mash-ups”, the technology is more mature and provides an excellent way of simultaneously reducing the volume of email flowing around with yet another updated project plan attached and increasing collaboration within the organisation and where there is collaboration, there is innovation.

Any other suggestions?  Comments welcome – as always.

Ronan