HP was the first US company to create a joint venture subsidiary in China; three decades later, the vendor has become a major player in the country’s consumer and enterprise markets. Among enterprises, HP has strong brand awareness for its server products and services, traditional software solutions, and IT services, but rather less for holistic application life-cycle management (ALM), especially on the mobile side. I think it’s time for technology decision-makers and enterprise architects to seriously consider adopting mobile app delivery management solutions and to evaluate HP for that purpose. Here’s why:
HP’s portfolio now covers the entire mobile app life cycle.The products HP will bring to market as part of its latest strategy will eventually cover the entire mobile application life cycle from app design, development, and optimization to distribution and monitoring. For example, at the design stage, HP Anywhere — based on popular open source product Eclipse — allows developers to write once to multiple devices within its integrated development environment. And its service virtualization feature can help virtualize third-party cloud services and make them consumable across each layer of the system architecture, including web servers, application servers, and web services.
HP’s solution has rich optimization features suitable for Chinese enterprises. At the mobile app optimization stage, HP’s Mobile Center uses a comprehensive approach to functionality, interoperability, usability, performance, and security to consolidate and automate mobile testing. Mobile Center is integrated with LoadRunner, one of the most popular performance engineering tools in Chinese market.
I hear people talking about Agile 2.0 a lot. But when I look at what’s happening in the application development and delivery space, I see that many organizations are just now starting to experience Agile’s true benefits, and they’re not yet leveraging those benefits completely or consistently. So let’s stop talking about Agile 2.0 for a moment and instead digest and operationalize what’ve learned so far. There’s plenty to improve upon without getting into inventing new practices and acronyms to add to the Agile transformation backlog!
What I see is that app-dev leaders want to understand how they can optimize existing use of AD&D Agile practices like Scrum, XP, Kanban, improve the practices around the more advanced ones like TDD, continuous testing, CI and CD and leverage all with what they’ve learned over the years (including waterfall). Scaling the whole thing up in their organization in order to have a bigger and more consistent impact on the business is what their next key goal is. We fielded the 2013 version of our Global Agile Software Application Development Online Survey to find out how. I present and analyze this data in my latest report. The survey addressed common questions that clients ask me frequently get in inquiries and advisory, such as:
How can we test in a fast-paced environment while maintaining or improving quality?
How can we improve our Agile sourcing patterns to work effectively with partners?
If you've been reading the research I've been writing over the past year, you know that I'm a fan of implementing an application life-cycle management strategy that focuses on increasing development flow and supports high-performance teams. You don't need to religiously implement all 22 CMMI processes or deliver dozens of intermediate development artifacts like some leading processes advocate. Rather, there are certain important processes that you should spend your time on. We wrote about change-aware continuous integration and just-in-time demand management in last year's Agile Development Management Tools Forrester Wave™. They are two of my favorite areas of focus, and they are great areas to invest in, but once you have them working well, there are other areas that will require your focus. In my opinion, the next process where you should focus on flow is everything that happens post build and preproduction. Most folks think about this process as release management or configuration management, but I think there's a better term that focuses on how quickly software changes move through both processes. It's called continuous delivery. When you focus on establishing a process of continuous delivery, you'll find that your capacity to release changes will increase, your null release cycle will shrink, and a larger proportion of the productivity gains you've seen from your Agile development efforts will flow through into production.