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?
Adobe Systems is a pioneer and fast mover in the public cloud and in so doing is showing that there is nothing for infrastructure & operations professionals (IT Ops) to fear about this move. Instead, as they put it, the cloud gives their systems administrators (sysadmins) super powers ala RoboCop.
This insight was provided by Fergus Hammond, a senior manager in Adobe Cloud Services, in an analyst webinar conducted by Amazon Web Services (AWS) last month. Hammond (no relation to Forrester VP and principal analyst Jeffrey Hammond) said that Adobe was live on AWS in October 2011, just 8 months after its formal internal decision to use the public cloud platform for its Adobe Creative Cloud. Prior to this there were pockets of AWS experience across various product teams but no coordinated, formal effort as large or strategic as this.
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"!
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.
Forrester’s survey and inquiry research shows that, when it comes to cloud computing choices, our enterprise customers are more interested in infrastructure-as-a-service (IaaS) than platform-as-a-service (PaaS) despite the fact that PaaS is simpler to use. Well, this line is beginning to blur thanks to new offerings from Amazon Web Services LLC and upstart Standing Cloud.
The concern about PaaS lies around lock-in, as developers and infrastructure and operations professionals fear that by writing to the PaaS layer’s services their application will lose portability (this concern has long been a middleware concern — PaaS or otherwise). As a result, IaaS platforms that let you control the deployment model down to middleware, OS and VM resource choice are more open and portable. The tradeoff though, is that developer autonomy comes with a degree of complexity. As the below figure shows, there is a direct correlation between the degree of abstraction a cloud service provides and the skill set required by the customer. If your development skills are limited to scripting, web page design and form creation, most SaaS platforms provide the right abstraction for you to be productive. If you are a true coder with skills around Java, C# or other languages, PaaS offerings let you build more complex applications and integrations without you having to manage middleware, OS or infrastructure configuration. The PaaS services take care of this. IaaS, however, requires you to know this stuff. As a result, cloud services have an inverse pyramid of potential customers. Despite the fact that IaaS is more appealing to enterprise customers, it is the hardest to use.