The rise of the DevOps role in the enterprise and the increasing requirements of agility beyond infrastructure and applications make the platform-as-a-service (PaaS) market one to watch for both CIOs and enterprise architecture professionals. On December 9, the membership of Cloud Foundry, a major PaaS open source project, announced the formation of the Cloud Foundry Foundation.
In my view, this is as important as the establishment of OpenStack foundation in 2012, which was a game-changing move for the cloud industry. Here’s why:
PaaS is becoming an important alternative to middleware stacks. Forrester defines PaaS as a complete application platform for multitenant cloud environments that includes development tools, runtime, and administration and management tools and services. (See our Forrester Wave evaluation for more detail on the space and its vendors.) In the cloud era, it’s a transformational alternative to established middleware stacks for the development, deployment, and administration of custom applications in a modern application platform, serving as a strategic layer between infrastructure-as-a-service (IaaS) and software-as-a-service (SaaS) with innovative tools.
Cloud Foundry is one major open source PaaS software. Cloud Foundry as a technology was designed and architected by Derek Collison and built in the Ruby and Go programming languages by Derek and Vadim Spivak (wiki is wrong!). VMware released it as open source in 2011 after Derek joined the company. Early adopters of Cloud Foundry include large multinationals like Verizon, SAP, NTT, and SAS, as well as Chinese Internet giants like Baidu.
We attended the recently held CA World 2014 in Las Vegas which we estimate had about 5000 customers. Over and over we kept asking: What’s the intention of CA Technologies for this year’s event?
It’s not just that the event had Magic Johnson speaking about his past career and how he transformed from a world class athlete to a successful business man or the Tuesday night music event by Fray, a rock band from Denver, Colorado. It was the entire atmosphere of the showcase, keynotes and presentation styles which gave us the feeling this is really a new CA – a CA that wants to shed the image of suits and complex solutions and replace it with T-shirts, jeans and cool, digital solutions.
Envision a large solution floor scattered with CA Technology solutions and some of their partners; coffee, food and snack stations, surrounded by presentation theaters which featured topics like Business Intelligence, DevOps, Mobility, Security and Business Intelligence. Very different, very vogue and very modern! Most important we saw a CA which stressed that “every company is a software company and innovation is key to create a powerful advantage” (quote from Amit Chatterjee, CA Technologies during keynote on Tuesday). Sentences like “we are living in the application economy” and “mobile, the new interface for your mainframe” puzzled and excited both legacy installed base, prospects and other clients.
As analysts we have to say “Well done CA Technologies”. For attendees , next steps are how to transform into the digital business. Keynote presenters from Twitter, Facebook, Nike and Samsung made it sound like a walk in the park – reality is proving us differently, but CA is driving innovation in today’s application economy.
The modern business world echoes with the sound of time-tested business models being shattered by digital upstarts, while the rate of disruption is accelerating. Organizations that will win in this world must hone their ability to deliver high-value experiences, based on high quality software with very short refresh cycles. Customers are driving this shift; every experience raises their expectations and their choices are no longer limited. Like trust, loyalty takes years to build and only a moment to lose. The threat is existential: Organizations need to drive innovation and disrupt their competitors or they will cease to exist.
Engaging All Service Engineering Folks: Help Forrester Define “Service Engineering” As A New Role Within Infrastructure & Operations (Or Beyond)! A variety of technology trends such as mobility and clouds are empowering consumers and connects employees who all are interacting and collaborating through apps and devices which are changing the way business is conducted. In response, organizations are forced to accelerate business changes which require the need for agility innovating new technology choices, implementation options, and delivery approaches. In this new pace of change the business demands more of IT to help deliver services which enable and support the age of the customer. Some Infrastructure & Operations teams have made the transformation to manage and support BT services which consist of technology, systems, and processes to win, serve and retain customers. Other organizations still manage and support components which range from operating systems, middleware, general purpose components, applications and custom components built all for specific purposes. I&O teams have become good at building components, but it often lacks the engineering discipline to assemble these components into services that meet specific business needs and are relevant in the age of the customer. To stay relevant and transform Infrastructure & Operations in the age of the customer, I&O needs a new role – service engineering. Service engineers mainly “do” three things:
1. Think and act from the outside-in – this means establishing, managing and continually improving services which are critical and essential for business enablement and business success.
2. Participate and support the DevOps journey – business agility in large parts depends on technology today. The DevOps team plays a large role in the quality and speed of technology delivery.
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?
DevOps is a movement for developers and operations professionals that encourages more collaboration and release automation. Why? To keep up with the faster application delivery pace of Agile. In fact, with Agile, as development teams deliver faster and in shorter cycles, IT operations finds itself unprepared to keep up with the new pace. For operations teams, managing a continuous stream of software delivery with traditional manual-based processes is Mission Impossible. Vendors have responded to DevOps requirements with more automation in their release management, delivery, and deployment tools. However, there is a key process that sits between development and operations that seems to have been given little attention: testing.
In fact, some key testing activities, like integration testing and end-to-end performance testing, are caught right in the middle of the handover process between development and operations. In the Agile and Lean playbook, I’ve dedicated my latest research precisely to Agile testing, because I’ve seen testing as the black beast in many transformations to Agile because it was initially ignored.
As many of you know, Forrester conducted a joint research study earlier this year, in conjunction with the US chapter of the IT Service Management Forum (itSMF-USA). The report is finally now available to the deserving. Forrester clients can download it using the normal access methods. Members of itSMF-USA will receive their copy from itSMF-USA. If you contributed, but do not fall into either category, Forrester will be sending you your copy.
You can read a few of the finding in my original post announcing the completion of the study. An example of the findings is the level of satisfaction with service desk solutions. While satisfaction in general is higher than one would think, a SaaS model has proven especially satisfactory:
Please let me know if you are having difficulty obtaining your report. Thank you again for all the participation that led us to these findings! We look forward to next year’s study!
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.