Tag Archives: value chain

5401494223_e339c6425a

DevOps and the “Product-centric” approach

When doing the research for our BrightTalk Webinar on DevOps I came across this quote from Jez Humble on “products not projects”, which really struck a chord with our thinking about what we call the “product-centric” approach to DevOps.

Products not Projects quotation

Figure 1 – DevOpsGuys BrightTalk Webinar

One of the key elements of DevOps is to ensure that IT strategy is directly linked with Business strategy.

One of the critical scenes in “The Phoenix Project” is where our hero Bill gets to meet with the CFO and they work through the list of “pet IT projects” in the organisation and find that many of them can’t really be tied back to any business strategy or organisational goal.

This is, we feel, one of the major problems with the “project-centric” view of IT and why we need to push for a “product-centric” view.

The “project-centric” view, whilst important for mobilising resources and organising activities, can easily get disconnected from the original business objectives. Any “Project”, just like the “Phoenix Project” in the novel, runs the risk of becoming its own “raison d’etre” as it becomes more about getting “the Project” over the line than whatever business benefits were originally proposed.

In contrast a “Product-centric” viewpoint is focussed on the Product (or Service) that you are taking to market. By keeping the focus on “the Product” you are constantly reminded that you are building a product, for customers, as part of an organisational objective that ties back to over-arching business strategy.

For example if you were in the travel sector you might be adding a new “Online Itinerary Manager” product to your website to enable your customers to view (and possibly update) their itinerary online as part of your business strategy to both empower customers online and reduce the number of “avoidable contacts” to your call centre (and hence reduce costs).

One of the other benefits of the “product-centric” view is also highlighted in Jez’s quote above – “From Inception to Retirement”.

The “product-centric” view reminds us to think about the “Product lifecycle” and not just the “software development lifecycle”.

The “product-centric” view reminds us to think about the “Product lifecycle”
and not just the “software development lifecycle”.

You need to understand how this product is going to be deployed, managed, patched, upgraded, enhanced and ultimately retired… and that means you need close cooperation between the business, the developers and operations (= DevOps!).

So how do you introduce the “Product-centric” view into an organisation that might already have existing website that offers products/services to customers?

Well, firstly, you need to stop referring to it as “the website”.

A “website” is a platform and a channel to market, it’s not a “product”.

A product is a good or service that you offer to the market in order to meet a perceived market need in the hope that you will in return received an economic reward.

For some “websites” there might be a single product e.g. Dominos sells pizza online (food products) and for other there might be multiple products e.g. theAA.com sells membership (breakdown services), Insurance, Financial Services, Driver Services (mostly training) and Travel Services. If you’re ever in doubt on the products your website sells your top navigation menu will probably give you a pretty good indication!

What Products does the AA Sell?

Figure 2 – what products does the AA sell?

It’s worth mentioning that the AA has another product too – the “RoutePlanner”. Although the route planner is “free” is has a value to the organisation both indirectly (by drawing traffic to the site that you might then cross-sell too) and intangibly (by offering a valuable service for “free” it enhances the brand).

Secondly, you need to identify the “product owners” for each of the core products that use your website as a channel to market, so in our AA example you’d probably have separate product owners for Membership, Insurance, Finance etc.

If you’re ever in doubt about who is, or isn’t, the right product owner then there is a simple test – “Do you have a significantly financial incentive (bonus) for Product “X” to succeed in the market?”.

The “Product Owner” Test:
“Do you have a significantly financial incentive (bonus) for Product “X” to succeed in the market?”

If the answer is “no” keep going up the hierarchy until you find someone who says “yes”. A product owner who doesn’t have any “skin in the game” regarding the success of their product line is a bad idea!

Thirdly, you need to work with the product owner to map out the product lifecycle of that product, and then identify the IT dependencies and deliverables at every stage along that product lifecycle. Within your product lifecycle you might also want to map out the “feature roadmap” if your product devolves into multiple features that will be released over time. Creating the “big picture” can be vital in motivating your teams and helping them to understand what you’re trying to achieve, and this in turn helps that to make better decisions.

Fourthly, you need to “sense check” your product lifecycle and feature roadmap against your business strategy and organisational goals. If they don’t align you either need to re-work the plan or you might decide to drop the product altogether and re-deploy those resources to a product that *IS* part of your core strategy.

Lastly you need to re-organise your DevOps teams around these products and align your delivery pipeline and processes with the product lifecycle (and feature roadmap). Your DevOps teams are responsible for the “inception to retirement” management of that product (*Top Tip – just like your “product owner” it might be a great idea to incentivise your DevOps teams with some “product success” (business) metrics in their bonus, not just technical metrics like “on-time delivery” or “system availability”. It never hurts for them to have some “skin in the game” to promote a sense of ownership in what they are delivering!).

So, to summarise, the key elements in a “product-centric approach” are:

(1)    Breakdown your “website” into the key “Products” (that generate business value)

(2)    Identify “Product Owners” with “skin in the game”

(3)    Map out the product lifecycle (and ideally feature roadmap) for each product with them

(4)    Sense check this product strategy with your organisational strategy

(5)    Align your DevOps teams with the core products (and incentivise them accordingly!)

So next time you’re in a meeting and someone proposes a new “Project” see if you can challenge them to create a new “Product” instead!

 

image source: - CC  - jeremybrooks via Flickr - http://www.flickr.com/photos/jeremybrooks/5401494223/sizes/s/
coase

The Economics of DevOps Part II – Ronald Coase and Transaction costs

In an earlier blog post we talked about the classical economic theories of Adam Smith and how they applied to DevOps (particularly the role of “generalists” and “specialists” with DevOps teams).

In this post we’re going to talk about the work of Ronald Coase on transactions costs and the “Nature of the Firm” and why this is relevant to how & why the DevOps approach works.

“In order to carry out a market transaction it is necessary to discover who it is that one wishes to deal with, to conduct negotiations leading up to a bargain, to draw up the contract, to undertake the inspection needed to make sure that the terms of the contract are being observed, and so on.” – Ronald Coase

One of the key tenets of DevOps is to try and remove the “silos” that exist in “traditional” IT departments but in order to remove these “silos” we need to understand how&why they exist in the first place.

In 1937 Coase published the “Nature of the Firm” which examined some of these issues in the context of why certain activities were taking place within the boundaries of an organisation as opposed to by external suppliers (and also why certain activities need to be undertaken by governments in order for the market to work effectively).

Where do we “draw the line” between what’s economically viable to do “in-house” as opposed to “subcontracting out”? In IT terms this can be seen as analogous to the “buy vs build” decision when it comes to COTS software.

Coase postulated 6 “transaction costs” that influenced this decision, and where you drew the “boundary of the firm” depended on the your desire to minimise these supply costs for that particular service or product (and hence to maximise YOUR profits for the output of your value –added activity that was built on top of these base costs).

  • Search and information costs are costs such as those incurred in determining that the required good is available on the market, which has the lowest price, etc.
  • Bargaining costs are the costs required to come to an acceptable agreement with the other party to the transaction, drawing up an appropriate contract and so on.
  • Policing and enforcement costs are the costs of making sure the other party sticks to the terms of the contract, and taking appropriate action (often through the legal system) if this turns out not to be the case.

Source – Wikipedia

If we examine many of the current trends in both business and IT it’s clear that these cost are (consciously or unconsciously) the target for many of the new products and services we see in the market.

  • Googles entire business model is based on LOWERING search and information costs (even more so with services like Google Shopper that enable you to very quickly find information on products and prices). Lowering the “information asymmetry” between buyer and seller generally optimises the price.
  • eBay and Etsy also directly attack these costs – they collect items into a market so that lowers search and information costs, they set very clear policies (“contracts”) regarding prices etc, offer policing and enforcement mechanism in the case of disputes and generally guarantee payment via the use of escrow systems etc.
  • virtual workforce websites like elance.com or 99designs.com do the same for services – they create an efficient market where you can find the skills you require within a framework that lowers your risk and minimises these transaction costs.

So how does this apply to silos within at IT organisation and DevOps transformation?

Well, if we shrink our definition of the “firm” down to the IT department we can see how silos can form.

For example, if you want some DBA expertise it lowers search costs if you can just say “go see the DBA team over there” (silo). You can define clear processes to request and interact with that silo (lowers bargaining costs) and all the DBA’s report to a common line manager so when it comes to “policing and enforcement” you have a clear route to complain. It also makes life easier for the DBA’s in that they lower their internal “search costs” when it comes to sharing knowledge, information, workload etc.

So what is DevOps trying to change?

Well, DevOps postulates that creating silos based on expertise is ultimately inefficient when seen from the perspective of a building a customer product. It might be efficient for the DBA’s but these silos don’t scale very well.

In order to build a “product” I need DBA’s, systems administrators, business analysts, developers (of various flavours), testers etc etc. If all of these exist in silos, surrounded by processes, my transaction costs increase to a point where my “boundary of the firm” from the perspective of the product team has grown so high that it makes sense for me to redraw my boundary to have those skills “in-house”.

This is the essence of DevOps – we re-draw the boundaries to create cross-functional teams to reduce transaction costs within that (product) team.

Search and Information costs trend to zero because it’s not some remote person in another silo… the expertise I need is across the desk from me, interacting with me every day via our Scrum or Kanban processes.

Bargaining costs become personal, not abstract – as a team we are committing to our shared goals without the need for reams of formal processes.

Policing and enforcement likewise become social and transparent – if someone isn’t contributing or delivering on their promises then this rapidly becomes apparent to the rest of the DevOps team and social pressures start to come to bear to align their behaviour with the groups agreed goals.

Similarly from the “external” perspective to our “DevOps firm” if we have a problem with Product X its clear where the responsibility lies – with the DevOps team that owns that product – and not diffused across multiple silos (Dev, Ops, etc) who can “point the finger” at the other team as the “root cause”. For many organisations the time wasted in defining & executing “problem management” processes to solve this “enforcement cost problem” to find out who is responsible for fixing a problem are immense.

Viewing DevOps from economics perspective starts to give us a framework to understand why the empirical benefits we see in organisations that have adopted DevOps principles are created, which ultimately gives us clearer insight into how & why to implement DevOps.

image source: - CC  - classicsintroian via Flickr -http://farm6.staticflickr.com/5003/5305503329_b3663df5bc_d.jpg

Are you really doing DevOps? 8 prerequisites you must consider

A recent “2013 State of DevOps” report from PuppetLabs indicated that “52% of [over 4,000] respondents said that they’ve been doing DevOps for > 12 months”. Our own, less formal, survey found very much the same – 60% of respondents indicated that they were currently doing DevOps”. Take part in our survey, by clicking here.

PuppetLabs Survey Results
PuppetLabs Survey Results

The question is Are you really doing DevOps?

As we pointed out in our earlier DevOpsDays wrap-up blog there are at least 7 different definitions of what DevOps is, judging by the presentations given on the day:

DevOps … is a movement, a philosophy, a way of thinking.
DevOps … is a person who can perform both Dev and Ops roles.
DevOps … means cross skilling people.
DevOps … is continuous delivery.
DevOps … is a team of developers and operation staff.
DevOps …is a culture movement.
DevOps … is monitoring.

So… what’s the “minimum viable product” (MVP) for DevOps? What core things should you be doing before you can truly say you are “doing DevOps”?

In the whitepaper “The Top 11 Things You Need To Know About DevOps” Gene Kim emphasizes the “3 Ways”:

(1) “ Emphasize the performance of the entire system” – a holistic viewpoint from requirements all the way through to Operations
(2) “Creating feedback loops” – to ensure that corrections can continually be made. A TQM philosophy, basically.
(3) “Creating a culture that fosters continual experimentation and understanding that repetition and practice are the pre-requisites to mastery”

These are excellent guidelines at a high level, but we’d like to see a more operational definition. So we’ve made up our own list!

As a starter – we propose that;

  1. You must have identified executive sponsors / stake holders who you are actively working with to promote the DevOps approach.
  2. You must have developed a clear understanding of your organisation’s “value chain” and how value is created (or destroyed) along that chain.
  3. You must have organizationally re-structured your development and operations teams to create an integrated team – otherwise you’re still in Silos.
  4. You must have changed your team incentives (e.g. bonus incentives) to reinforce that re-alignment – without shared Goals you’re still in Silos.
  5. You must be seeking repeatable standardized processes for all key activities along the value chain (the “pre-requisite to mastery”)
  6. You must be leveraging automation where possible – including continuous integration, automated deployments and “infrastructure as code”
  7. You must be adopting robust processes to measure key metrics – PuppetLab’s report focuses on improvement in 4 key metrics – Change Frequency, Change Lead Time, Change Failure Rate and MTTR. We suggest Availability, Performance and MTBF should be in there too.
  8. You must have identified well-defined feedback mechanisms to create continuous improvement.

As mentioned above, this is just a starter list – feel free to agree/disagree in the comments and suggest additions or alterations.

We’ll be writing more about “DevOps Incentives” in an upcoming post, and we’ll revisit the “Are you doing DevOps?” topic once we’ve consolidated your feedback.

-TheOpsMgr