Unlike the desktop, mobile is far less forgiving for the developer and requires an effective experience that is not just about UI but also responsiveness, reliability and trust. This means that UX brings together multiple IT disciplines such as Architecture, Security and Analytics. Having a UX process as part of a mobile development strategy will reap rewards both for the business and IT. Going further and adopting a UX Strategy to incorporate all apps extends those benefits and fortifies long term value as mobile apps evolve.

The report demonstrates:

• how essential UX is to the success of any Enterprise Mobility strategy
• the ways in which Enterprise Mobility Apps aimed at the employee will improve workforce productivity and business competitiveness leading to significant ROI
• the business benefits beyond mobility of embracing mobile UX
• the power of Analytics that track user interactions

It also gives an insight into the solutions and strategies from vendors like IBM for supporting Enterprise Mobility.

The report is available free from our Research Library.

Adobe Creative Suite has been a mainstay of the print and web creative industries for a decade. It was created out of the various tools that Adobe has created and those that it had bought through an aggressive acquisitions strategy in the late 1990′s and early 2000′s. Adobe was always keen to ensure that it supported both the Mac and Windows platforms in order to get the greatest possible sales and market coverage.

Over time, the number of tools available, meant that Adobe had to split Creative Suite into several packages as well as sell the tools separately. This created quite a problem for Adobe in terms of co-ordinating product release schedules and managing the huge support burden of a large and constantly growing software empire.

Two years ago, Adobe created Creative Cloud which provides access to all the tools in the Creative Suite via s Software as a Service (SaaS) solution. At the same time, it announced that Creative Suite would in future be based on a yearly release cycle.

On 6th May 2013, Adobe announced that the future lay with its online subscription solution rather than with boxed software. So what does this mean for the market?

Adobe cuts costs and stabilises revenue.

Creative Cloud provides Adobe with a number of key cost cutting opportunities and delivers a more stable revenue stream.

The key savings are:

1. No longer creating physical media, manuals and packaging.
2. No shipping or warehousing costs.
3. No channel discounting (up to 35% in some markets).
4. Lower support costs by reducing the number of products to be supported.

As well as savings, there are revenue improvements for Adobe:

1. Monthly subscriptions mean that revenue is more stable, predictable and not subject to the vagaries of product cycles.
2. Customers buying boxed Creative Suite rarely upgraded with each new version. This means Adobe has a lot of customers on old versions that are not revenue generating. With subscription only, every customer generates revenue.
3. Once customers are in a subscription service, it is easier to upsell new products. This is a lesson that satellite and cable TV has proven.

Creative Cloud delivers customer benefits

Creative Cloud is not just about Adobe reducing costs and stabilising its revenue stream. It offers a set of real benefits to customers as well.

1. Access to ALL Adobe products.
2. Ability to take short term access for specific products.
3. Team licences.
4. Access to latest versions without having to worry about patching.
5. Cloud storage.

Simplifying the acquisition and management of key business tools is a real cost saver for businesses. While the main subscriptions are yearly based, there are times when access to a specific tool, eg Photoshop or Dreamweaver, might be a customer requirement. With Creative Cloud you can quickly take out a monthly license as part of the project costs.

Not everything is perfect

Unsurprisingly, not everything is perfect yet with Creative Cloud and there are things that Adobe needs to address.

Creative Cloud needs to relicense itself at regular intervals. If you are working without an Internet connection at this time, you will be given a maximum of three days to relicense. The rational from Adobe is that this prevents people taking a subscription, cancelling the payment and still having access to the tool. As a user, I get this but it is frustrating and there needs to be a better way to handle it.

While nobody doubts Adobe will do its best to keep data safe there is no encryption of the data on the Adobe servers nor is there any backup process to pull it back locally. Instead, you have to copy it to your local servers. Adobe needs to make it easier to backup the cloud storage to a local machine and make it clear how you get your data back should your subscription expire or be lost.

A model for other software companies

By moving the bulk of its products to a SaaS model, Adobe is putting a seal of approval on cloud as a delivery model for software vendors. It is not the only software vendor to take the view that cloud is mature enough for business. Microsoft is looking at cloud delivery for email and Office although it is extremely unlikely that it will completely close its physical shipment model.

It will be interesting to see how long it takes other software vendors, particularly those in the mid-market to emulate Adobe. The lower costs and stable revenue models will be extremely attractive to a lot of software businesses but that doesn’t mean it will work for them. Adobe is a market behemoth and as such, it knows customers will stay with it and provided it doesn’t encounter huge cloud problems, business will be good.

Adobe is currently allowing some resellers to offer Creative Cloud subscriptions but for how long as at what price? This is something that the channel will want to know because should Adobe decide to go it alone, it will have serious ramifications for the whole distributor model.

Smaller vendors are also watching what Adobe is doing with the channel. Unlike Adobe, they lack the sway and market reach to work outside the channel. To be frank, many of them are happy with the channel as it means they do not need their own sales teams.

Conclusion

Adobe is once again causing waves in the market. With Creative Cloud now two years old and stable, Adobe is betting that customers are now ready to fully embrace it. Early signs from customers are that they like what Adobe has to offer and are willing to move away from boxed software to cloud.

Provided Adobe addresses the issues raised here and can scale up Creative Cloud as customers come on board, Adobe should be able to ride this wave of change for software delivery.

Wikipedia describes orchestration (computing) as ”the automated arrangement, coordination, and management of complex computer systems, middleware, and services.”

In the last three years, we have seen an increasing amount of attention on orchestration with vendors such as Serena, IBM, Microsoft, HP and Oracle beginning to deliver orchestrated software suites and best practices. Many of these products have their roots in earlier tools such as system, product and configuration management. With multiple starting points, it should come as no surprise that there is a fair amount of confusion as to what orchestration really means for customers.

The Wikipedia description above, sets a very wide scope for orchestration. It allows that any tool that can project manage the delivery of software in a distributed environment, has a claim to be an orchestrated solution. It also means that there are a lot of very poor orchestration solutions out there which are little more than a bunch of scripts that do a marginal job or orchestrating certain tasks.

For Orchestrated IT to mean anything, what is needed is a proper framework. This might be vendor driven or, in a perfect world, standards based or based on a standard. The solution also needs to be more than just random scripts. There must be a clear hierarchy of tasks that have a common reporting engine through which they can be monitored and audited.

More importantly, any solution must be inclusive and able to interoperate with solutions from multiple vendors. Too many practitioners today complain about having to use multiple orchestration products because those that they have deployed cannot manage the complexity of their environment.

The problem isn’t just confined to the management of current datacentre based solutions. As companies look to incorporate cloud into their deployment platform choices and buy access to third-party cloud solutions, there is a requirement for orchestrated IT solutions to address all platforms.

All this raises a serious point. If vendors are shipping orchestration solutions that cannot manage complex environment then can they really claim to be a valid orchestration solution? If we take the Wikipedia definition, the answer is no.

DevOps may well act as the catalyst and framework for many vendors to sort out their orchestration. This is because DevOps requires common processes across the entire IT function. Creating those common processes will enable orchestration vendors to use them as a foundation for a multi-platform, software agnostic solution.

The onus is now on vendors to prove that they are capable of managing more than small, discrete solutions. Those vendors who deliver a solution that manages the complexity of multiple platforms, supporting heterogeneous solution and do so in an open manner will win. Those who continue with limited engagement across the IT infrastructure will eventually be seen as white noise and either find a discrete niche or disappear.

You can obtain the report from IBM by clicking here or in the Research Library.

The Guide is available as a free download from the Research Library.

In a separate but related report, we profile the support delivered to improving Enterprise development and operations relations (DevOps) by Serena Software’s Release Management and Automation portfolio (also available from the Research Library).

In January 2012, I mused over the implications of IBM’s acquisition of Green Hat, vendor of a product that simulated external interfaces for software testing. Fifteen months later, I’ve had another look to see whether things have panned out as I imagined.

It seemed to me that Green Hat was an excellent acquisition for IBM. It was good because IBM would have an offering that addresses a major headache of complex application testing, so filling a real market need. And it was good because it added a capability not typically found in the major test tool suites, so possibly acting as a fillip to IBM’s position in the test tools market.

Both aspects, I suggested, might reinvigorate investment in test tools suites from IBM and others, which had long centred on test management and test execution in simplistic environments – environments that have ceased to exist. The old suites have been looking tired in an agile world and ineffectual in the face of increasingly complex application architecture.

Looking again just over a year down the road, it’s impossible for me to know with certainty, but there have been signs that the gist of what I said was correct.

A market in Service Virtualization

It was the advance in test automation made through integration of SV with a major test tool suite that was significant about the IBM/Green Hat acquisition. CA was annoyed that I made no mention in my original blog of LISA, a product it acquired with SOA testing vendor iTKO in mid-2011. But iTKO was not a ‘major’ test tool vendor (nor is CA) and LISA was rooted firmly in SOA. It didn’t seem an equal comparison, but over time, SV is becoming a key component of test tool suites generally. A few months after IBM acquired Green Hat, HP announced HP Service Virtualization. You now have SV in test tool suites from IBM, HP, Parasoft and CA.

IBM testing tools: a bigger picture

But are there any signs that Green Hat has helped IBM grab any extra attention – and sales – with its wider testing tools offering? IBM says sales of both Green Hat and its whole test offering have seen big increases in sales. The way IBM is expanding and fine-tuning its test tools portfolio does suggest it is having some success.

Three years ago, the strategic IBM quality and testing tools were Rational Functional Tester (RFT), Rational Performance Tester (RPT), and a fairly immature Rational Quality Manager (RQM) that tied the testing processes into the Jazz platform. That test portfolio appears to be undergoing some restructuring around what IBM identifies as three key quality management drivers:

• Continuous integration, testing and delivery
• Test prioritization and analysis
• Multi-channel test automation

Continuous integration, testing and delivery

Here, test environment management meets The Cloud. IBM is counting on SmartCloud Continuous Delivery to solve the usual problems of test environment provisioning by orchestrating test platforms, test data (using InfoSphere Optim Test Data Management) and – with Green Hat – external interfaces. The same platform definitions are used for production deployment ensuring the fidelity of the testing to the configuration in live operations.

Test prioritization and analysis

IBM appears to have new ideas how to manage proliferation of test cases. Its goal is to pare tests down to a minimum set that maximizes coverage. If it carries this off, IBM will be bringing a useful analytic capability to test automation.

Multi-channel test automation

Multi-channel test automation is how IBM describes the need to support multiple sources of tests that are run independently by any of a diversity of test execution tools. To achieve this, IBM has introduced the Rational Test Workbench (RTW) and a common test description language called ClearScript. In time, RTW will consume ClearScript and drive tests through any one of the supported test execution engines, which include IBM’S RFT, of course, and also Green Hat (as IBM Rational Virtual Services Server) and even open source Selenium.

Overall, the multi-channel approach is a straightforward architecture for decoupling test definition from the technology to automatically run it. It nods in the direction of the keyword testing approach that has been around for many years, where the work of test automation is segmented so that business experts can concentrate on the business intention of tests and technical specialists do the automation.

But the architecture is not an end in itself. It appears to be a stepping-stone to enabling IBM to do some analytic magic for optimizing and reusing tests. We’ll have to wait to see what it produces.

One for the roadmap

Green Hat has settled in well with the Rational portfolio of test and quality tools. The product has been rebranded and integrated within two releases in the first year and it has an obvious position in IBM’s roadmap.

More widely within the Rational test automation offering, we like that not only is IBM rounding out its capabilities to address the mechanics of testing – such as test environment configuration and management, but it is also aiming at the analytic problems of testing – like how to optimise test sets.

The opposition to Pinochet was faced with the dilemma of how to win despite the cards being stacked against them. They needed to convince people to vote no. Their leadership was full of downtrodden miserable politicians who had been suppressed and even tortured under Pinochet. They wanted to mount a campaign revealing the misery and injustice the dictator had caused them. But one opposition leader had his doubts and decided to turn to a marketing agency with a radically different idea.

A young ‘madman’ at the agency produced a brilliant campaign that concentrated solely on images of the bright things the future might hold by voting ‘No’. By the end of the campaign, the Chileans had roused themselves from their resignation, rallied around the colourful marketing images, slogans and song, and trounced Pinochet in the voting, to the point where the Army abandoned him as a lost cause.

As compelling as the film was, it was nowhere on my mind when I received an invitation to a breakfast briefing resembling a 1960’s agitprop poster, sporting the slogan Viva la Revolucion. I dismissed the imagery as irrelevant hyperbole. The invitation came from Coverity and SQS. The briefing was about Development Testing and as I am interested in Development Testing and breakfast, I accepted, even though breakfast was to be interrupted by, ‘revolutionary speech and crowd response’. Would there be a bun fight, I wondered?

The revolutionary theme stemmed from the notion that testing is undergoing revolutionary change, with a shift in emphasis from late-cycle to development stage testing. The briefing had three participants:

• Coverity who uses Development Testing as a ‘theme’ around which to market a set of development stage static analysis tools,
• SQS, a service provider traditionally in the late-cycle testing space, now partnering with Coverity to provide development testing services, and
• Aviva, a joint customer in the throes of the revolution.

The presentations – essentially by the Aviva managers – were suitably low-key: there was no hard sell. In fact, it was hard to know except in the loosest way how Coverity and even more so, SQS, figured in the Aviva story.

Aviva’s story is that of a typical large financial institution needing to modernise its development processes to be more responsive, agile and innovative. In other words, to deliver faster and more efficiently. Their journey is to overhaul their end-to-end development process, and development testing is only part of that. Streamlining development processes like source management, builds, integration and delivery – and the automation of much of that – was really the narrative. Use of Coverity’s products in development figured as they shift some error detection away from late-cycle ‘system’ testing to the development stage.

In the Q&A, it became clear that Aviva’s revolutionary road still had some way to go. The organisation is still grappling with how to shift testers (never mind the testing) out of their late-cycle comfort zone back into development. Agile practices are part of that move, but developers are still not predominantly responsible for their unit tests. And the use of Coverity analysis tools is still the subject of a period of developers learning to accept them (much of the usual talk about minimising ‘false positives’ from static analysis.) So the revolution might be started but it is certainly not yet won.

At the end of briefing (after the agitated masses had mostly dispersed), I managed to speak directly to Ben Riches, head of application design and delivery at Aviva UK’s General Insurance (GI) division, about the ‘selling process’ needed to gain acceptance and take the transformation to its conclusion. He explained how he was doing what I consider to be the usual practical things for change management: establish clear goals, get management buy-in, do education and training, give high visibility to achievements, encourage light competition among teams, find local champions, do progressive rollouts, run pilots, etc. All sound stuff.

There was still one specific point I was curious about. Given that the Coverity story is rooted in static analysis, why had I heard nothing about one of the linchpins for introducing static analysis: reduction of technical debt? As I had outlined in my paper, Static analysis for business agility, technical debt is the source of a lot of the friction that stops IT responsiveness. Was it not a problem for Aviva?

The answer could have been straight from the mouth of the adman in the film, NO. According to Ben, technical debt is just a reminder of their past misery and mistakes. The only way to sell the change – to the whole development process, not just development testing – is through painting a positive vision of what will be possible in the future: a responsive, effective IT organisation capable of defending and enhancing Aviva’s competitiveness. Will Aviva have a clear-cut win? We don’t know. The revolution has still to take its full course.

The announcement of a single overarching mobile strategy and portfolio of products and services is a welcome development. If IBM’s organisational machinery can deliver on it, this much-needed coordination alone could go some way to dispelling the perception that Big Blue is not serious about mobile.

The portfolio is comprehensive, spanning the entire application lifecycle and with good support for multiple delivery models and devices. As you would expect, there is a strong security and management story. There is also a welcome focus on the user experience, based on a recognition that the diversity, heterogeneity and dynamism of mobile platforms makes it hard to ensure a consistently high quality experience.

What makes the present moment ripe for a coordinated push? It’s the unstoppable trends of consumerisation and bring-your-own-device (BYOD), creating new opportunities for enterprises by putting powerful mobile platforms (in particular tablets) into the hands of their customers, employees and partners. Enterprises who plan to roll out high volumes of integrated mobile apps also need a credible and comprehensive application lifecycle management strategy, which is where MobileFirst comes in.

But IBM is also making a big bet that the mobile application landscape will change as enterprises increase their involvement.

Today, most mobile application development takes place in the context of the mobile content and B2C marketing value chain. It is an incredibly dynamic business, but it’s also a creative cottage industry with the lion’s share of design and development carried out for big brands by agencies, in a piecemeal fashion. There are many specialists, and work is not just contracted out but frequently sub-contracted to smaller agencies and freelancers.

IBM is ringing the changes by targeting MobileFirst directly at large enterprises, who it believes will be churning out hundreds of apps rather than commissioning them from specialists. There will be industrialisation: future mobile apps will roll off factory production lines, not crafted in the workshops of Soho and Shoreditch.

It is yet to be seen whether high-volume mobile application development will come fully home to the enterprise. Of course, some innovators (such as IBM customers TBC Corp and Air Canada) have already developed some of their own mobile apps, and some will undoubtedly continue to do so. But most in-house development teams do not have – and are unwilling to pay for - the specialist skills needed to create highly dynamic, user interaction-heavy applications. This sort of work is frequently outsourced to specialists, even in PC-centric web development which has been around for longer than mobile. Indeed IBM itself has benefited via IBM Interactive, its agency business which forms part of the service organisation.

It seems most likely that mobile development will continue to happen in the context of a digital supply chain. Many enterprises will take a hybrid approach, working in partnership with integrators, agencies and other specialists, including IBM of course, and some (not all) will outsource altogether. Many more will rely on the mobile functionality provided by their application partners. But IBM is right to point out that whatever the model, all of these organisations must pay attention to lifecycle management, or risk security and management issues spiralling out of control. Whoever does the coding, the enterprise must remain in control of its architecture.

Let’s also not forget that specialist suppliers play a crucial role in generating demand for new mobile projects amongst customers. Creative agencies especially are frequently superb marketeers, and their people often set the agenda in terms of how big brands can use mobile to innovate. Could their energy be harnessed in driving forward the mobile B2E opportunity? These are potential new partners for the IBM ecosystem, albeit not the sort of organisations that it is accustomed to working with.

With MobileFirst, therefore, IBM has a very interesting opportunity on its hands. We will watch with interest to see how quickly it can persuade customers and their partners to kick the habit of one-off mobile projects and move to a more sustainable approach for the future.

For programmers this means a variety of things. Existing applications need to be optimised (or indeed re-optimised) for mobile; and this includes considerations from screen size refactoring to re-engineering for accelerometer usage, touch input, GPS-enablement and more.

Developing on a moving surface

Given the still-nascent state of touch, mobile-based speech input, constantly developing mobile form factors and (if we are quite honest) just about every other element in this dynamic equation, mobile-first is probably not best defined or addressed as a philosophy. Instead we need a methodology here incorporating aspects of Agile and other essentially iterative ingredients to allow us to “develop on a moving surface” so-to-speak.

The days of disconnected mobile and desktop development are not over; there are too many enterprise-scale monolithic development environments on the planet to break that mould. But constructing two separate code bases, in two distinct teams that are typically poorly connected and badly synchronised doesn’t make sense any more, if it ever did. Whether the target deployment is a web-based service or a native mobile app, a unified and truly dynamic approach is now a prerequisite.

Mobile needs to look to the web; this is the space where a state of “perpetual beta” is not uncommon and an inherent appreciation for cyclical reiteration of application code is an accepted fact of life. This does not necessarily mean developing in an environment where everything changes, but at least where a constant stream of change is brought to bear at a specified point in time and location upon the application surface.

Esoteric wildcard what-if development

Parallels with Eric Schmidt’s 70/20/10 programme come to mind where the Google boss has suggested a split of work targets to accommodate for constant change. In the software programmer’s universe this equates to a scenario where 70% of the code base should stay essentially the same, 20% should be focused on new project integration, then a final 10% exists as the “esoteric wildcard what-if” development factor, so that we can build for the unknown before it arrives. If this is indeed an element of an agile (and/or Agile) mobile first methodology, then at least it accommodates for a much needed insurance factor that may have been missing up until now.

But there is a caveat here for which we must draw a cautionary breath. Any mobile-first philosophy or methodology also needs to be hinged around a secure-first operational ideology. We only need to look at the case of HTC to see how dangerous a poorly conceived mobile development can be. The firm admitted charges of distributing insecure software and putting users at risk after the Federal Trade Commission (FTC) found that it had failed to properly train its developers or to comprehensively test the software it produced.

HTC actually ended up introducing security vulnerabilities into its software through customisations it had purposefully engineered. These vulnerabilities resulted in third parties being able to exploit sensitive information stored on users’ devices. Attempting to address mobile-first secure-first obligations now are programmes such as IBM’s MobileFirst strategy. IBM’s accepts that enterprise mobile today is an end-to-end solution responsibility that demands application design services with the requisite level of secure integration functionality. This truly is the only way forward.

So with mobility at the heart of our newest apps we can be pleased about the fact that connectivity is everywhere, but despite this truth, the prudent mobile programmer will develop as if there is “no juice in the pipe” and provision for a good degree of offline application functionality. Judicious mobile first development also accepts that there are a far wider variety of users of every type of application at any one point in time.

As mobile now grows further, development teams will need to act as close bedfellows; separating streams of work across different development platforms and/or operating systems will only result in duplication, disconnection and ultimately more chance of project failure. Aligning teams around application features rather than devices features can work out to be a progressively productive move here. Carrying those teams’ workloads through to delivering those features on iOS, Android, BlackBerry or Windows Phone can provide the end-to-end cohesion needed to succeed in the rapidly shifting mobile marketplace.

Features, functionality and form factor finesse

Ultimately, whatever approach a development team adopts it should embody a lean approach where application elements are componentised — or at least clearly defined enough to act as target mini-projects of identifiable functionality. Developing with speed as the primary objective (despite the transient and often disposable nature of mobile applications) is not the way forward. Features, functionality and form factor finesse should be our five Fs even if we don’t succeed in creating a new de facto mobile development methodology in formal terms.