I would like to welcome you to the "Modern Service Delivery" playbook. In this playbook, we are researching how you can take your tech operations team and transform it into a modern operations team. You know already that in the age of the customer, I&O must transform to support businesses by accelerating the speed of service delivery, enabling capacity when and where needed and improving customers and employee experience. You must buddy up with your application development team! Get used to a new way of working. That gets me to the point of this blog – CALMSS! Yes – you are reading this right. CALMSS is not just a scramble of words – it is a fine assessment of characteristics with the purpose of describing a methodology. The first acronym - CAMS (Culture, Automation, Measurement, Sharing) was coined by John Willis and Damon Edwards in 2010 in the first US based Devopsdays in Mountain View, California. Later on the “L” for lean was added by Jez Humble. We at Forrester have added an additional “S” for sourcing as we believe that DevOps must be supported with a solid sourcing strategy to extend the ecosystem. This then brings us to the arcronym of CALMSS.
After a great conversation with Patrick Debois – godfather of DevOps – we are working on a Forrester CALMSS research report (publishing April 2015) where we list what we think are the characteristics of each letter that supports measurement at individual, project, intra-company and inter-company levels. We will be focusing in our playbook on the project level so that you can measure and benchmark yourselves.
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 pace of change for App Dev leaders has always been rather hectic. In my 32+ years as an "apps guy" - I can't recall a time when supply of technology resources ever fully satisfied all demand for the work that business leaders would like to do. Satisfying that demand has always been a challenging and constant balancing act. The past few years have heralded the age of the customer, where the voice of customers is amplified by social media and enabled by mobile applications - accelerating the pace of change for app dev & delivery leaders to a relentless pace. If you're hoping for a brief respite in 2015, it's time for rethink.
I have a love/hate relationship with "technical debt". Having covered apps modernization, rationalization, and portfolio management at Forrester for more than a decade, I have a keen appreciation for the concept of technical debt - in all its permutations.
So I love the term for the sentiment it expresses about the need for change:
As we have modernized applications over the past 4 decades, we have "kicked the can" down the road far too many times - opting for expediant change over "refactoring to make it right"
Within any mature single app, technical debt spawned by years of compromise can accumulate to daunting levels
The debt eventually reaches the point of becoming a self-fulfilling prophecy - today's debt is too big to tackle, so we kick it down the road and watch it grow out of control
Across the entire apps portfolio, the accrued debt cripples firms by gobbling up huge percentages of the available business technology (BT) spend
As we rush to build out customer facing and mobile apps to address the age of the customer, the technical debt within the systems of record act like an anchor on change velocity - at both the app AND portfolio levels
And I hate the term because well-intentioned techies wield it like a bludgeon to pound business leaders with an urgency to act. But imagine for a moment how it sounds to business leaders, how they react to the term:
"If it's technical, then its your problem Mr App Dev leader, not mine - I'm a business leader"
"This debt you want to hand me ... YOU created it, YOU made technology decisions - it's your problem, don't try to hand me a bill to clean up YOUR mess"
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?
Agile software development practices have been transforming AD organizations for more than a decade. With more rapid development cycles has come a bottleneck at the deployment boundary - at the frontier between Development and Operations. The DevOps movement is working to remove this bottleneck, and in the process is transforming both Dev and Ops for the better. In many respects it is a logical evolution of the agile movement, but practices like continuous deployment are deeply transformative of the way that organizations think about customer engagement, business engagement, testing, development and requirements - in fact, nearly every aspect of agile development is subtly but powerfully affected. The implication of a check-in resulting in code being deployed to production gives a whole new emphasis to the word "commit"!