Please let us not impune he rich culture of the noble bro.
Any CTO who prefers a packaged methodology over doing some homework andtailoring technology/process to the specifics of their business, is aCTO to be avoided. (And boy, if you hear your CTO talk about "totalquality management" or "six sigma" - that's the time to run for thedoor. c.f. Dilbert for references to "stink like a dead weasel").
obviously! not that all improvements are 'devops' issues. That would be stretching it too far indeed.
The reasoning was more that when we try to optimize your 'dev & ops' problem,
the bottleneck for improving it may well be outside dev & ops.
So you have to have a broad view, otherwise you're still trying to solve some problems with a narrow view.
While reasoning on the stories for the book , it made me think about the things happening in other parts of the company that have an influence on the dev and ops tension.
- hiring/HR policy can have it's effect on the devops tension , what kind of persons fit well in this problem
- financial incentive of each groups can have have an impact on the problem
I've seen the same thing happen with agile teams trying to solve 'devops problems' within the dev team only.
On 23/05/12 14:09, Ernest Mueller wrote:Well, but Agile hasn't dropped the ball - it's just that it's just now getting around to us. When you look at the actual big picture there's a lot to it. The Agile Austin group, for example, has SIGs on agile dev, agile QA, agile architecture, agile product development, agile UX, agile leadership... And now DevOps. Just because now we're down with the concepts that are new and shiny to us doesn't mean we now know how to fix all the other parts of an organization.Going and looking at the first diagram in Patrick's article - no, optimizing the relationship between HR and Sales is not "DevOps." That's ridiculous. It's overreaching IMO just like my security example. DevOps isn't just chef and puppet, or just about deployment, but I think its focus is realistically on the part where ops is actually embedding into the rest of the organization instead of being a segmented sideshow and optimizing the process of actually delivering services. Yes, dev and ops represent the "two sides of the technology house" - and I think Ops can properly be understood to rep Net and Sec and all that as we move forward - but the scope is not "everything in an organization all the way to HR and Finance." Ops is waking up and smelling the coffee here, not inventing coffee. The expansion dilutes the usefulness of the focus. DevOps isn't lean/agile/OM but better. It's an application of those principles to a product team creating and delivering software.The next DevOps Areas part I think is great. It's the initial "well DevOps is everything!" thing that sounds like consulting gig scope creep to me.ErnestAt 10:27 PM 5/22/2012, damone...@gmail.com wrote:I see your point about being careful of DevOps being heralded as a panacea for all ills. But DevOps isolated to just the point of contact between Dev and Ops isn't the answer either.
You could say the macro perspective is "Lean" in it's purest form, but DevOps has as much claim to it in the technology realm as Agile does. The only proof I need that "big picture" isn't properly represented by Agile is that the Agile movement has been around for a long time (in "tech years") yet completely missed the big picture that you needed the align and optimize the entire development to operations delivery cycle to properly implement Lean in a software as a service world. Sure you can reference a handful of sharp folks who have been saying this all along… but the vast majority of the thought, effort, dollars, and time that has gone into Agile has resulted in a prescriptive methodology for software development that starts with requirements and ends with "code complete". I'm sure the purists will cringe at this and the manifesto will roll over in it's grave… but that is where that movement has gone. It's become a local optimization that doesn't address the "global" concern of the development to operations delivery cycle (i.e. what the business actually cares about and pays for)Now on to DevOps… Are we not doomed to repeat the same mistake if we don't take the all inclusive holistic approach? The whole point of having a "dev" and an "ops" is to take business ideas and manifest them as running features for customers. What's the point of the "focus on the relationship between dev and ops at the product level" if it doesn't optimize the whole system to achieve it's purpose? In order to optimize that relationship for that purpose you have to include all the pieces that must come together to make that happen. That doesn't mean that everyone has to be a generalist in everything (your example of conflating security and availability), but it does mean that everyone has to understand the system they are a part of and how to work together to fulfill the purpose of the system.
When the original DevOps conversation started, it was taking a broad system-wide view. The two seminal events both talked about Dev and Ops as if they were the entire technology house split into two sides. Paul Hammond (Dev) and John Allspaw (Ops) represented the entire Flickr technology team (at least figuratively if not literally). The first DevOps Days in Ghent was framed as bringing together the two self-identifications that rarely gather at the same conference, Dev and Ops.Post DevOps Days Ghent the conversation definitely became deployment centric. Why? Because deployment is the canary in the coal mine for a broken development to operations lifecycle. It's the flash point where the pain is felt, but the root cause of that pain comes from somewhere else.
Now that I'm 5 paragraphs into a rant… :)
I've always thought DevOps extends into the business more broadly (than narrowly Dev+Ops) because neither Dev nor Ops are the app owner or the customer.
Dev may build the features and functionality of the app, and fundamentally manages the cadence of those changes delivered to Ops for controlled exposure to the world, but inside the business there’s an app owner who studies the customer and fundamentally drives the app’s existence from infancy to grave. And that’s where I think DevOps discussion expands well into the organization via that loop from App Owner / customer back around into Dev and Ops.
The next DevOps Areas part I think isgreat. It's the initial "well DevOps iseverything!" thing that sounds like consulting gig scope creep to me.
Taming Change https://www.tamingchange.com/
Team Topologies https://teamtopologies.com/
Customer Expectation Management Method http://tschurter.com/wp-content/uploads/2018/10/Customer-Expectation-Management-Revised-e1538575324591.png
Nicols WP https://www.nickols.us/difficult.pdf
Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation https://www.amazon.com/Value-Stream-Mapping-Organizational-Transformation/dp/0071828915/ref=sr_1_3?gclid=CjwKCAiAis3vBRBdEiwAHXB29G0behX5zj11Xl0xCxQvg8wAFZ3QigWAtjP14HEfyGcB72VM03jvqhoCNGIQAvD_BwE&hvadid=323590030477&hvdev=c&hvlocphy=9003712&hvnetw=g&hvpos=1t1&hvqmt=b&hvrand=12095849842679789977&hvtargid=aud-840076997981%3Akwd-746770535&hydadcr=24407_11048948&keywords=value+stream+mapping+book&qid=1576271981&sr=8-3
ISO/IEC 33020:2019 Information technology — Process assessment — Process measurement framework for assessment of process capability https://www.iso.org/standard/78526.html
THE OPEN GROUP IT4IT™ REFERENCE ARCHITECTURE, VERSION 2.1 https://publications.opengroup.org/standards/it4it/c171
Fugle Innovation Model https://www.researchgate.net/figure/The-Fugle-innovation-model_fig1_290440787
eG Innovations https://www.eginnovations.com/it-monitoring/whats-new
For your information :