Which organization types are targeted by DevOps transformation?

Question

Due to my lacking vocabulary in this context I am not sure how to designate the two types of organizations I would like to talk about before I can put my question. Anybody capable of better wording feel free to improve this. Probably there are mixed types but I suppose I have to polarize a little bit to make the point.

OrgType1: "digitalized product organizatons" either B2B or B2C, they have their products, as they become more and more digital, they have some own IT product teams and IT operations. They have found out that they need (more than before) product diversification quite recently.

OrgType2: "digital consulting service organizations" (not necesarily just IT consulting but they are typical example here) these guys are B2B only, if they have sustainable products and related operations then it is rather a side effect. Rather, their software product lifecycle is limited to just one or several projects, and that diversification has always been their core business. Actually, the real product is here much more every single member of this organization who depending on the role might, but by far not always does, develop software.

OK then, so OrgType1 is clearly what we already know that DevOps is of a great help, because there are established delivery processes, they get disrupted, need to be optimized, and so on and so forth. Well, bigger organizations consist of many parts, regional business units, business lines, departments, and every one has its combination between operations and their-own-breed-of Devops. Okay - anyway there can be some evolution.

OrgType2 can care about DevOps only so much as it is important for their customer (or they even sell DevOps consulting ;) but then if it comes to onsite software development, you somehow start from zero in almost every project, and this is magnified as with OrgType1 through all departments, business units and so on but it is worth because every "DevOps entity" starts just with 1-2 people who need to discover what they are up to. Seems like OrgType2 is "siloed by design" in a much more dense way which makes it also somehow scalable and persistent.

This all considered and taken into account, the question from my current perspective is: how do DevOps practices apply for the OrgType2, maybe there are resources where this has been explored?

Answer 1

DevOps applies to Organization Type 2, the Business to Business entity as much if not more than the first Organization type. There are two possible scenarios here:

Scenario 1

In the first they are selling a product or service to businesses. In terms of DevOps, this makes them virtually indistinguishable from Organization Type 1. Though their customer is a business/group of individuals, they are providing a product or service to a customer. This customer just happens to be a business instead of a private individual, this is is irrelevant to execution of DevOps. Contracted with specific software goals, clearly defined requirement or otherwise, the best value and customer service will be provided by a DevOps model for reasons that do not need to be restated here.

Scenario 2

This scenario happens to be a bit more exceptional as in this case, Organization Type 2 is providing consulting services to a business. Presumably and usually, a business hires a consultant for business assistance within the consultant's domain of expertise. Businesses have technical support for assistance with specific technologies and can contract en engineer for migrations, but when issues such as risk management, overall architectural design, process, flow and high-level questions arise, this is when a consultant is hired for their business advice.

This is why it is important to remember that DevOps is not a role. I would argue that DevOps represents a business or organizational management processes - or even a philosophy. It is more or less a specific way of implementing an agile methodology that has been extended well beyond just development to encompass many disciplines and departments. As such, DevOps is a package deal - in order to be successful at DevOps, you have to be committed to a specific business philosophy of organizational management.

In fact, in order to illustrate this point, In "The Phoenix Project", Board member Erik Reid repeatedly drags the Book's main character, Bill Palmer, to a parts manufacturing plant in order to illustrate and teach Bill things about technology and software development by drawing business lessons from the manufacturing sector.

This is authors Gene Kim, Kevin Behr and George Spafford's way of driving home the point that DevOps is more than just way of doing things, or specific technologies, but is a philosophy of business simply known by various nom de plumes.

So, in order to provide the best value to the company to which a consultant is consulting, it is incumbent upon the consultant to demonstrate and explain the value of DevOps and assist a company in successfully executing on this business philosophy and guide the company to specific technologies and ways of doing that. In short, it is the consulting companies job to act as an "Erik Reid" to whatever business has contracted their consulting services.

In short, DevOps should be very important to Organization Type 2 because it is their job as a consultant to explain to their customer why it is important - they should always be selling DevOps consulting. Consultants working with a company who refuses to consider DevOps should consider politely suggesting that perhaps they aren't the right fit. their customer can hire a generic code monkey from anywhere if they want to continue to (unsuccessfully) continue to do projects the way they have always done them.

Answer 2

I feel dev ops is involved more than just the product developed, but the process that is used to go from an idea to in the field. Org 2, I think, could use dev ops to set up a uniform way to gather requirements, incorporate/enforce branching strategy, setup/maintain CI. This is just the dev team.

Every organization isn't just dev. Org 2 could may very well have a sales team. Is there anything that can be done for the sales to gather requirements in a more effective manner, or organize them. Is there a common UI element that all the applications share that all customers complain about.

These are just some of my views on Dev Ops. I am very new to the role. I view the role as being responsible for all the transitions in the development process as well as the development process. Making it easy to go from idea to requirements, to user stories, to work tracking, to testing, to release, then gather feedback to use again as requirements gathering.

I think sometimes you have to create the data you want to mine. This year (2017) Microsoft's conference dedicated a whole day I believe to Dev ops. I was unable to go but the conferences can be found on you tube. One you may be interested in (and I have queued up to watch) is dev ops for every team. Another I just came accross in browsing Keynote with Donovan Brown: From 0 to DevOps (I haven't watched either of those but they seem applicable)