When I was an ADC (Application Development Consultant) with Microsoft Premier Support for Developers, I wrote the following draft of a proposal merging the development aspects and support/operations aspects of my job.
This was around 2004. Notice the quote from Steve Balmer “almost every company is becoming a software company”. This was seven years before Andreessen’s famous post “Why Software is Eating the World” in The Wall Street Journal.
As I showed it around to my colleagues, at the time it was not well understood as most of the ADCs considered themselves as account managers for development support questions, and more recently this trend has crystalized by the position having been renamed as ADM (Application Development Manager) to align with TAM (Technical Account Manager), whose focus is on support for infrastructure such as Exchange, Active Directory and Windows.
I was on the right track as today DevOps has taken hold, and it has become mandatory to view development as inseparable from deployment and operations.
I want to thank a Microsoft Principal ADM who reviewed this post and mentioned the following:
“Nice article but already dated since we are in fy17 and too many changes to list :-) roles, titles, and org are all different under Satya”.
I agree, Satya is doing a great job in rejuvenating Microsoft. When reading this post you should look away from role names/definitions and other specifics, and focus on the core message of built-in supportability that current cloud software development requires. Enjoy.
(Note: a couple of charts came from Steve McConnell and other friends at Construx, and I have left its copyright notice. The same applies to ITIL.)
Proposal for ADC account strategy on dedicated accounts in the Enterprise space
This paper is an exploration of possible ways to better leverage ADCs in dedicated accounts. Some of its conclusions are also applicable to smaller contracts as well.
Based on some informal surveys, it is fair to say that most ADCs today spend most of their time providing “General Consulting Services” or in laymen terms, ad-hoc and unstructured break-fix advice to developers.
“Ad-hoc general consulting” is mostly characterized by its lack impact on the organization as whole. It is usually a “one-time-only” request, relegated to a small subset of the organization.
While this might the best option in a couple of situations, in most cases those requests are not really aligned with the business drivers for Enterprise IT organizations. Most of them would fall under the “staff augmentation” and “training needed” category if in depth case analysis was to be done.
Historically, Premier has recommended that in bigger accounts, ADCs should ideally spend their time (60% or more) in mostly Proactive activities. We propose that less than that is an anomaly, and a plan should be developed to bring the account to this state.
Implementation will clearly vary by ADC skills and account background. In the beginning of the contract, ADCs might have to go down to the "down to the metal" until all outstanding reactive issues are worked out. But later, the ADC should also start increase his value to the organization.
Driving business value to the customer
In his address of 1/30/2004, Steve Ballmer refers to Platform Competition and makes two key references that have the potential of driving the ADC work in the Enterprise on what really matters:
[…]While Longhorn client and server will be absolutely critical to our future, we must also continue to innovate around and re-energize the existing Windows platform today, and ensure that we’re addressing key customer concerns about security, reliability, manageability and cost of deployment and ownership.
[…] Software provides insight and oversight, defines intellectual property and business processes, and increasingly is the way we interact with other people, groups and organizations. The result is that almost every company is becoming a software company. While people may view Dell as a manufacturer, or Wal-Mart as a retailer, it is their software that makes their successful models work. Persuading these “new ISVs” to build on our platform is as important as winning the traditional ISV.”
So the challenge is, ADCs have to be more strategic as well, as they are today in the ISV space.
In typical Enterprise space, an ADC will be part of a CIO’s IT organization at some level. IT is a cost center, and so focus is on optimizing budgetary constraints, while in the ISV space the ADC is working for the COO at some level, software development deliverables are the company’s product, and so it is a profit center (see Strategic Alignment: Leveraging Information Technology for Transforming Organisations, J.C. Henderson, N. Venkatraman 1993).
So until companies in the Enterprise space realize they need to see themselves as “new ISVs”, the best way to provide value is to align with current IT shops business objectives. And those are usually related to Steve’s first paragraph mentioned above. Ultimately, security, reliability, manageability and cost of deployment are all summarized in Total Cost of Ownership (TCO), and a CIO’s job is to minimize it. That’s what is driving IT shops today to try and run their operations with less and less people, and more and more consolidated servers. Dell’s stated objective is to bring IT costs down to less than 0.8% of their revenue.
So anything that an ADC proactively does to improve in those areas, will be seen as supporting an Enterprise IT’s business objectives.
The need for a common theme
Opposed to ad-hoc work is, of course, work done with a predefined objective or what I would call “theme”. Taking into account the previous observations, and the fact that ADCs are primarily part of a Support organization, I would suggest that in the Enterprise world ADCs could use, as a business vision for their work, the following statement: "to decrease development support costs across the custom application lifecycle".
Two classic slides from Steve McConnell will better illustrate the point for proactive work and business value:
The slide is self explanatory. It may cost from 50 to 200 times more to fix an issue that was introduced in earlier project phases.
Now look at the next slide below. Where would ADCs provide more value: on the red zone or on the green zone in the next slide? It is pretty obvious when seen graphically.
Why would a customer be willing to pay premium for dedicated resources that only work on the red part of the curve, when they can have savings at least 50 times bigger when working on the green one?
ADCs as process improvement catalysts
Given that we clearly established above the need for Proactive work from a business perspective, how do we proceed to implement it?
The best way to decrease support costs is taking a proactive stance and act on the real root cause of issues. In ITIL terms, ADCs should proactively work with IT on the problems, not just ad-hoc incidents. This implies the need to understand the profile of an account, and classify their issues beyond the shallow root cause that we have been normally delivering our customers.
Despite the pioneering work by Lymbourner and others, the current case analysis deliverables suffer from basic misconceptions that blur the line between problems and incidents, cause and effect, and therefore do not allow us to provide convincing feedback to the customer so they can focus on the green curve (problems) as opposed to incidents (red curve).
When first interacting with the account, we should do a quick assessment of the most important reactive issues, take care of them, and then with this solid base, proceed to work on creating value through proactive work on the underlying problems. The ADC becomes then a process improvement catalyst.
Which Problems should an ADC concentrate on
Given that we should proactively concentrate on problem resolution in our time with the customer, which ones are those?
In the Enterprise space, problems that will eventually cause incidents on Production are related to application “aspects” that are frequently overlooked.
Whereas MCS consultants also work with customer business requirements, ADCs will primarily work with requirements that have direct impact on application supportability. I call them “aspects” because in fact they cross-cut all types of applications at all levels, be it requirements, architecture, design, coding, testing and implementation, as opposed to business requirements which are specific to the solution domain.
These problems are deficiencies on usually called “non-functional requirements”. You will recognize some of them from Steve Ballmer’s email, but here is a more complete list:
The ability of an application to be present and ready for use.
The ability of an application to be administered.
The measure of an application's operation under load.
The ability of an application to perform in a predictable manner.
The ability of an application to match increasing demand with an increase in resources.
The ability of an application to protect its resources.
Issues with any of those aspects hit the IT budget bottom-line, because they all impact TOC (Total Cost of Ownership). Work done to improve any of those aspects is therefore indicative of ADC alignment with IT business objectives.
ADC offering as aligned with support improvement
One area that has typically been neglected by ADCs in general in the “ad-hoc wandering round”, is the connection of IT business objectives mentioned before with ITSM (IT Service Management). From the documentation:
“IT Service Management is concerned with delivering and supporting IT services that are appropriate to the business requirements of the organization. ITIL provides a comprehensive, consistent and coherent set of best practices for IT Service Management processes, promoting a quality approach to achieving business effectiveness and efficiency in the use of information systems.”
Usually ITSM is associated with Service Delivery and Service Support, and such subjects are deemed as part of “TAM-land”. However, ITSM is much more than that, and one key topic unknown to most ADCs is Application Management:
Application Management is the superset, which describes the overall handling, or management, of the application as it goes through its entire lifecycle. This lifecycle encompasses both the application development phases and Service Management activities noted below. By bringing these two disciplines together, the goals of IT Service Management will be accomplished more easily through the delivery of applications that are more operable and manageable.
(From ITIL Service Management 2.0)
Application Management “combines the phases of application development and Service Management" In Microsoft parlance, Application Management translates to a combined MSF/MOF lifecycle:
This topic is the subject of an entire book, so I although there is a lot more to explore, I would like to emphasize that as part of Dynamic Systems Initiative (DSI), Microsoft has a clear path to satisfying most requirements from the ITIL Application Management topic "Aligning Application Development and Service Management". One such objective (I consider a niche for ADCs since it presupposes a long term persistent relationship with the customer) is:
Application designers who can design for functionality specifically aimed at Service Management; in fact, they could design applications that are ‘management ready’.
By supporting this objective with their customers, the ADC is in fact solving support problems from the architecture perspective, and aligned with support improvement.