Managed Services has been an integral part of professional services vendor catalogues for well over a decade. However, the increasing awareness and adoption of DevOps in the software delivery sector has meant that professional services need to adapt quickly and recognise the importance of streamlining their costs or face irrelevance as more specialised and nimble companies take their place.
The role of Application Support as a separate, distinct specialisation within a company is coming to an end. Developers performing this function would be quite right to recognise the direction software development is taking and work towards positioning themselves as subject matter experts within core [project] development teams. There is a huge amount of valuable experience and insight project teams can benefit from by integrating support specialists into their workflows; the task is to recognise why amalgamating these teams makes better business sense from the point of view of both the client and the vendor.
The Way It's Always Been Done
Application Support has always been viewed as an end goal at the tail end of any project. The Waterfall software development methodology made sure of that, locking "maintenance" in the conclusion of the project lifecycle: consigning the long tail of software to a solitary, nondescript box at the end of a diagram. Agile was an improvement: it recognised the iterative nature of software development and - at least for companies whose software was a product in and of itself - rolled technical debt and on-going enhancements into regular cyclical processes that ensured new improvements were always being generated.
Except that this doesn't translate well into the world of professional services vendors. Software vendor companies will recognise the preference for agile delivery methodology but will more often cherry pick the easy parts to feel reassured that they're at least trying to deliver things in an efficient, planned way, but these often overlook or neglect the complexities inherent in true agile projects and - especially on larger projects - end up causing more conflict and cost write-downs than taking the old-school waterfall approach.
Building a solution for a client of a professional services organisation typically means
- The client has an approved budget that it wants to adhere to in achieving a specific outcome
- The vendor will divert people with enough availability to deliver the outcome as a team
- The outcome will be delivered and handed over to a support team for any incidental tasks
Once the client solution is complete (i.e. delivered with the agreed functionality), the project team assigned to that work is typically disbanded and moved onto the next client. The business reasons for this are fairly simple: ensuring its people are maximally-utilised ensures that chargeability (and therefore profitability) are also maximised. The downside is the lack of continuity and knowledge retention for the client.
In addition to the inevitable "handover" process, where a person is expected to gather enough information to support the solution in a fraction of the time invested in developing the outcome, any agile process is typically abandoned and if releases were scheduled frequently and reliably by the project team (itself a rarity), these would fall by the wayside. Technical debt allowances are usually desperately low or missing altogether and therefore passed on to the support developer, along with massively reduced budget because the project team has consumed the "transition to support" allotment as it tries to claw back costs from overruns or poor scope management.
More often than not, this means the client is paying twice for the same product. Skills and knowledge attained by the project team simply cannot be transferred to an application support crew (less still a lone developer) and time is either absorbed by the company or charged to the client when new issues arise.
To add insult to injury, the Application Support team may learn that, in a drive to ensure development teams are fully-utilised, a new major enhancement to the client's solution has been in progress for some time and the support developer's fast-tracked knowledge is already being rendered obsolete. The shaky familiarity with what they were led to believe was now their solution is being undermined without their consultation or consideration.
DevOps is the new hotness. It's the revolution that solves many of the broken aspects of agile and software delivery. It's also being placed on a pedestal as a panacea to every software company's ills without a full appreciation of the cultural change required to truly make it work.
Make no mistake - DevOps is a culture; a production ideology, not a methodology in the true sense. It's not a role or function held by one person or team (or rather, it shouldn't be). You can still run agile projects and apply a DevOps approach. The crucial difference here is understanding all the parts to delivering a successful product for a client and setting the delivery team up for success from the outset by implementing systems that provide for the required outcomes.
To borrow from Microsoft's graphic of how a DevOps lifecycle might look, the chart below looks at each major gate in a software delivery project that leverages a DevOps approach:
Nowhere on this diagram is there a step that says "Handover to Support" or even implies that this distinction should be made. And that's the crux of this post: it's time to re-think how projects are delivered.
Companies that build their own product have been on this idea for some time. Professional Services organisations have been largely slow to react. This is in part because the way in which they engage in work with clients has remained broadly unchanged for years. The client will approach a company for help with a business problem, a software solution is (typically) produced and the client goes away (hopefully) satisfied that their business is operating more effectively with this solution. This sounds just fine on the face of it but technology has changed. Business has changed.
All businesses are software businesses
The important distinction here is that almost no business today operates without some form of online or automated process underpinning it. The company in question might be in the business of making horse shoes, selling pots of honey or delivering meals, but the one common thread across all these businesses is that - to some degree or other - they all rely on information technology. And if their business is even partly reliant on information technology to succeed, then their product or service is inextricably linked to their software. That software - for all intents and purposes - is their product.
That means the way in which we communicate our messages and advice as software professionals needs to reinforce that idea so that the client fully understands the type of investment they need to make in order to truly succeed. It's no longer sufficient to pay for something, get it and then let it sit indefinitely. Total Cost of Ownership has been a concept well-understood by businesses for decades. Any production or operational plant machinery or inventory has a known, quantifiable cost associated with it for accounting purposes, yet software is still viewed as a capital expense budget item, not an operational one.
Once a client understands that software requires regular investment and improvement even after the main body of functionality has been delivered, then the professional services vendor needs to appreciate that organising its people into "development" and "support" functions is no longer viable. Teams should be oriented towards clients. Larger clients with more long-term, sustained pipelines of work require a larger, more singular team. Clients with lower maintenance needs or smaller scale systems can be grouped for smaller teams to deliver regular sets of enhancements and refinements. Those smaller teams can manage several clients at once, releasing updates and features at a regular cadence in rotation around each client's system.
Despite the title of this post, this approach doesn't mean a professional services vendor can no longer sell managed services: quite the opposite - that is still a valuable offering for both client and vendor alike. Rather, it requires a meaningful and significant paradigm shift so that the software and infrastructure specialists are working and communicating as an effective unit, with a clear shared goal in mind that puts the client's solution at the centre of every aspect. The client has a reliable, dedicated team of people to rely on over the life span of their product and can tune that product so that it continues to stay up-to-date, reliable and valuable.
Managed Services as a distinct and separate business unit is increasingly less relevant as software delivery processes and tools continue to turn their attention toward faster release cycles with more reliable performance and on-going telemetry enabling the client to realise value and make informed choices on how to invest. Ultimately, the business / team structures within professional services organisations will need to reflect that change. The alternative is clinging to defensive processes, repetition of work and significantly increased costs passed on to clients to compensate for "the way it's always been done".