The new digital operating model
•Download as PPTX, PDF•
15 likes•2,834 views
The document discusses the digital operating model at different scales from a startup to an enterprise. It covers: 1) The operating model elements of people, process, and technology needed at different scales from a founder to teams to a team of teams to an enterprise. 2) How the needs change with scale from a minimum viable product focus to infrastructure as code to continuous delivery of applications. 3) The cultural and organizational shifts required to scale from control to self-organization and from hierarchy to networks of cross-functional teams.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to The new digital operating model
Similar to The new digital operating model (20)
Recently uploaded
Recently uploaded (20)
The new digital operating model
- 1. THE NEW DIGITAL OPERATING MODEL
- 3. What I will talk about Understanding the current digital and IT landscape Scale and the digital operating model An “emergence” approach to the operating model Founder Team Team of Teams Enterprise
- 4. What is an operating model? People Process Technology
- 6. Scale There is not a “one size fits all” for digital operating models
- 7. From startup to enterprise Enterprise Team of teams Team Founder THE SCALING PROBLEM What do we need? Why? When do we need it? How is it changing?
- 9. Digital Value From goods to services to experiences Minimum viable product Testing, learning, pivoting
- 10. Infrastructure Minimum viable platform Infrastructure as code From snowflakes to cattle to ants to serverless Opinionated platforms… full circle?
- 11. Applications Fast feedback: NOT OPTIONAL Test-driven, continuously integrated & delivered From batch handoffs to automated pipeline flow (release engineering)
- 12. Service Portfolio Component Portfolio Demand Component Proposal Component Policy Component Defect Component Requirement Component Project Component Test Component Build Component Source Control Component Change Control Comp. Problem Component Incident Component Event Component Diagnostics & Remediation Component Usage Component Chargeback / Showback Comp. Strategy to Portfolio Requirement to Deploy Request to Fulfill Detect to Correct Offer Mgmt. Component Offer Consumption Component Service Archite- cture Policy Require- ment Scope Agree- ment IT Initiative Portfolio Backlog Item Source Conceptual Service Blueprint Concep- tual Service Logical Service Blueprint Test Case Defect Offer Service Release Build Service Catalog Entry Desired Service Model Usage Record Fulfill- ment Request Sub- scription Charge- back Contract Request Problem/ Known Error Incident Event Service Monitor Run Book RFC Service Monitoring Comp. Catalog Composition Component Shopping Cart Enterprise Architecture Component Service Design Component Fulfillment Execution Comp. Request Rationalization Component Configuration Management Component Release Composition Component Service Level Component Service Contract Actual Service CIs Build Package Build Package Component Service Release Blueprint September 9, 2015 This diagram was developed/published by the IT4IT™ Forum, a Forum of The Open Group®
- 14. Product Management Story, outcome, experience High-bandwidth collaboration across specialties Bring the work to the team Not the team to the work
- 15. University of Minnesota What could possibly go wrong? Carlson School of Management Computer Science and Software Engineering
- 16. Work Management Keep it light – formal process not needed yet From control to self-organization LIMIT WORK IN PROCESS
- 17. Operations Interrupt-driven work From “accountability” to blameless Site reliability engineering & Web-scale
- 18. Service Portfolio Component Portfolio Demand Component Proposal Component Policy Component Defect Component Requirement Component Project Component Test Component Build Component Source Control Component Change Control Comp. Problem Component Incident Component Event Component Diagnostics & Remediation Component Usage Component Chargeback / Showback Comp. Strategy to Portfolio Requirement to Deploy Request to Fulfill Detect to Correct Offer Mgmt. Component Offer Consumption Component Service Archite- cture Policy Require- ment Scope Agree- ment IT Initiative Portfolio Backlog Item Source Conceptual Service Blueprint Concep- tual Service Logical Service Blueprint Test Case Defect Offer Service Release Build Service Catalog Entry Desired Service Model Usage Record Fulfill- ment Request Sub- scription Charge- back Contract Request Problem/ Known Error Incident Event Service Monitor Run Book RFC Service Monitoring Comp. Catalog Composition Component Shopping Cart Enterprise Architecture Component Service Design Component Fulfillment Execution Comp. Request Rationalization Component Configuration Management Component Release Composition Component Service Level Component Service Contract Actual Service CIs Build Package Build Package Component Service Release Blueprint September 9, 2015 This diagram was developed/published by the IT4IT™ Forum, a Forum of The Open Group®
- 19. Team of teams Culture & Organization Investment Execution PROTECT TEAM LEVEL DELIVERY!
- 20. Culture and Organization Functional vs product – Spotify model From pathological to generative Learning, inquiring organization –“go and see”
- 21. Investment From HIPPO to DIBB (Highest Paid Person’s Opinion vs Data, Insight, Belief, Bet) Project vs product portfolios From cost of inputs to cost of delay
- 22. Execution From hierarchy to network From defined to adaptive processes (e.g. Case Management) From efficiency to effectiveness
- 23. Service Portfolio Component Portfolio Demand Component Proposal Component Policy Component Defect Component Requirement Component Project Component Test Component Build Component Source Control Component Change Control Comp. Problem Component Incident Component Event Component Diagnostics & Remediation Component Usage Component Chargeback / Showback Comp. Strategy to Portfolio Requirement to Deploy Request to Fulfill Detect to Correct Offer Mgmt. Component Offer Consumption Component Service Archite- cture Policy Require- ment Scope Agree- ment IT Initiative Portfolio Backlog Item Source Conceptual Service Blueprint Concep- tual Service Logical Service Blueprint Test Case Defect Offer Service Release Build Service Catalog Entry Desired Service Model Usage Record Fulfill- ment Request Sub- scription Charge- back Contract Request Problem/ Known Error Incident Event Service Monitor Run Book RFC Service Monitoring Comp. Catalog Composition Component Shopping Cart Enterprise Architecture Component Service Design Component Fulfillment Execution Comp. Request Rationalization Component Configuration Management Component Release Composition Component Service Level Component Service Contract Actual Service CIs Build Package Build Package Component Service Release Blueprint September 9, 2015 This diagram was developed/published by the IT4IT™ Forum, a Forum of The Open Group®
- 25. Governance & Security From theater to antifragility Automation is more auditable! Heavyweight approaches can INCREASE risk of value loss
- 26. Information Meaning Records From enterprise data model to domain-driven design From binary to continuous
- 27. Architecture From mandate to hypothesis-testing Technical debt, it’s a thing Architecture as code
- 28. Service Portfolio Component Portfolio Demand Component Proposal Component Policy Component Defect Component Requirement Component Project Component Test Component Build Component Source Control Component Change Control Comp. Problem Component Incident Component Event Component Diagnostics & Remediation Component Usage Component Chargeback / Showback Comp. Strategy to Portfolio Requirement to Deploy Request to Fulfill Detect to Correct Offer Mgmt. Component Offer Consumption Component Service Archite- cture Policy Require- ment Scope Agree- ment IT Initiative Portfolio Backlog Item Source Conceptual Service Blueprint Concep- tual Service Logical Service Blueprint Test Case Defect Offer Service Release Build Service Catalog Entry Desired Service Model Usage Record Fulfill- ment Request Sub- scription Charge- back Contract Request Problem/ Known Error Incident Event Service Monitor Run Book RFC Service Monitoring Comp. Catalog Composition Component Shopping Cart Enterprise Architecture Component Service Design Component Fulfillment Execution Comp. Request Rationalization Component Configuration Management Component Release Composition Component Service Level Component Service Contract Actual Service CIs Build Package Build Package Component Service Release Blueprint September 9, 2015 This diagram was developed/published by the IT4IT™ Forum, a Forum of The Open Group®
- 29. © 2016, Charles T Betz Teaching Digital The Stack The Lifecycle
- 30. The 3 Dimensions of Digital Learning Lifecycle Stack Scale
- 31. Enterprise Team of teams Team Founder THE SCALING PROBLEM What do we need? Why? When do we need it? How is it changing? Conclusion
- 32. Current work
- 33. Q & A
- 34. Thank you for attending
Editor's Notes
- bio
- Essentially a business architecture for digital delivery, using a form of maturity model
- The idea of an operating model is often defined as “people, process, and technology.” We’ll stick with that definition. Operating models are specific to companies, so what do I mean by the digital operating model? I believe there is a core set of challenges that many companies are seeing as they digitally transform: challenges like “how do I manage my infrastructure,” “how do I build and sustain compelling digital products,” “how do I increase my release tempo for fast feedback,” and “what does culture have to do with digital success.” I think these challenges have to be met at an operating model level by any company seeking to compete in the digitally transforming economy.
- 1-3, 8-12, 40-70, 350-500, 2500-3500
- The fundamental point I want to make is that there is not a “one size fits all” digital operating model a company can implement. The operating model must scale as the company grows, and there are different concerns at different sizes. “What got you here, won’t get you there.” And in fact, the transition from one scale to the next is where things get interesting and some of the most heated industry arguments are happening. But the interesting thing is that we don’t talk about the scaling issues in IT and digital. We view startups as “unicorns” and enterprises as “horses,” and if you are comparing Facebook with Bank of America maybe that’s so. But perhaps we should be thinking more in terms of colts and foals vs. horses – a continuum, not two different species.
- This is the “emergence model” from my current book. I’ve used the idea, “from startup to enterprise” as it is effective with students. But it also applies to any existing enterprise – you don’t have to go through the process for forming a startup to benefit by using it as a thinking tool. As I’ll discuss further, some of the problems we’re seeing in IT operating model discussions come from the state transitions that happen as we move our concern from bottom to top. In particular, the transition from team-centric to team of teams is very challenging and currently driving a lot of industry debate… such as “ITIL vs DevOps” or “product vs. project management.”
- As a founder, you have a very simple operating model. You need some sense of the digital value you are going to offer, what your reason for being is. But once you have that, your concerns are very practical. You don’t have time for advanced operating model concepts like process frameworks or formal risk management. What tools/platforms are you going to use to deliver value? And once you decide on your tools, what is your overall flow of digital value? You don’t have time to formalize much more than that. An important point to this discussion: the operating model, by definition, is formalized. It’s documented and what you expect your teams to follow. It’s explicit, not tacit.
- You can find founders anywhere, not just in garages. The idea of having an entrepreneurial culture in larger enterprises has been around for years, and is increasing with digital transformation. General Electric CIO Jim Fowler says, “[W]e’ve moved to a flatter organizational model with "teams of teams" who are focused on outcomes. These are colocated groups of people who own a small, minimal viable product deliverable that they can produce in 90 days. The team focuses on one piece of work that they will own through its complete lifecycle.” It’s all about the value and every member of your team needs to be focused on that.
- Before you can write code, you have to decide on your platform. In many cases this will be decided for you, but in other cases it’s greenfield. There’s always a lot of churn here, we’ve had so many generations of infrastructure approaches, from mainframes to serverless. Looking at a new “opinionated” platform like Pivotal CloudFoundry, I’m struck by how we’ve come full circle – as far as I’m concerned, the mainframe was the original “opinionated” serverless platform. But one thing has emerged lately that I think will stick, and that is infrastructure as code. Whether we’re talking policy-driven server configuration management with Puppet, or software-defined networking, infrastructure is now defined in code. No more GUI or command line interaction with production systems!
- Now that we have a platform on which to realize our minimum viable product, we need to optimize it for fast feedback from the customer. It’s not about “celebrating failure,” it’s about accelerating learning. Enter DevOps, or at least the continuous delivery part of it. This starts at the very beginning of your journey: you need automated source control, build management, package management, and deployment management (of both your infrastructure and application). This is day 1 of a startup, not something to defer until “we have time.” And if you don’t have this stuff figured out in your larger digital organization, it’s priority #1. I’m quite comfortable stating that categorically.
- Hey, you made it. You’re thinking at the team level. Either your startup succeeded, or you got promoted in your larger organization. Now you have a whole new set of operating model concerns: product, work, and operations. The team level is the value level, it is where humans come together in close contact and creativity can be maximized … sometimes. A focus on teamwork is central to the Agile movement, you’ll see it all over the place at an Agile Alliance event or in their online materials. But what do we mean by this? Let’s break it down in operating model terms.
- As the founder, you are now out talking to customers and investors. The good old days of cutting code in the garage are behind you; now you have a team doing that. They’re good at building the thing right. But how do you know they are building the right thing? First up, you have to formalize product management. You need a product owner and some ability to start tracking system intent beyond random scribblings in your personal journal. Features, stories, requirements – whatever you call them, they represent your intent for the system, and that intent is now someone else’s job to try to build. So product management is now part of your operating model, building on your initial vision for a minimum viable product.
- Where do we get these product-oriented programmers? This is the University of MN. My wife and I have 5 degrees from here (she’s the smart one with the Ph.D. in geology). Notice the Carlson school, where we might find Product Marketing, about as far away as we can get from the CS department, with this big river thing in the middle. Consider Conway’s Law: organizations which design systems ... [tend to produce] copies of their communication structures... The U of MN is, in a sense, designing our workforce. What could possibly go wrong? We’ll return to this question of how disciplinary boundaries are set
- Product management is the “what.” You also need to spend some time formalizing “how.” Do you want a timeboxed cadence, like Scrum, a continuous flow like Kanban, or something in between? How does your team track its work? How do you define “done”? (There’s a big one.) What steps do you need to insist on, and where can the team self-organize to achieve outcomes? And most importantly, you must be attentive to the work in process you let into the system. More than one entrepreneur has said, “the secret of success isn’t what I do, it’s what I choose not to.” Get that into your organizational DNA as soon as possible, and if you’re in a larger context where multiple channels are forcing too much work into the system, fix it. Or leave. A chronically overloaded organization isn’t going to go anywhere.
- Operations isn’t going away. Complex systems don’t run themselves and it’s a miracle they work at all. In high-touch digital services you’ll always have interrupt-driven work, starting with your customer’s journey of inquiry as to how your product adds value to them. Complex systems fail. Top tier digital firms like Google and Netflix get this. Their operating model is to design for reliability in the face of severe component failures. And when things do fail, they engage in blameless post-mortems focused on solving the problem, not holding some poor individual “accountable” for being a flawed human being. How is it the human being was in a position to take the system down? That’s the proper attitude.
- Now we hit the big ugly. The transition from “team” to “team of teams.” Some people don’t want to make this transition; they’ll leave startups when they get to this point. That’s fine for them, but someone is going to stay behind. The challenge here is protecting team level delivery, while dealing with multiple teams that have some form of dependency. It’s a Wicked Problem and you should be very wary of anyone selling magic beans here, whether project management, process management, scrum of scrums, or Scaled Agile Framework. The best I can see is that there are a variety of tools and practices that, depending on your situation, might help. All of them have pros and cons.
- What’s your fundamental organization approach? No matter how you define operating model, this one is key. How are you matrixed? Are you putting people in silos, and then bringing the team to the work? Or are you organizing along product lines and bringing the work to the team? Culture isn’t just New Age “woo woo” anymore. Companies like Google are quantifying it. They’ve found for example that a sense of psychological safety is correlated with higher team performance. The annual State of DevOps report analyzes culture in terms of something called the Westrum typology, which is a well-grounded breakdown of companies into categories of “pathological,” “bureaucratic,” and “generative.” Pathological firms don’t do well, business-results-wise. The toxic environments shut down creativity and collaboration and the result is business failure.
- Notice the chopped up dollar bill. This is a fundamental operating model difference at the team of teams level. You’re now making a diverse set of bets, like taking out stock options if you will. How do you do this? Highest Paid Person’s Opinion, or something more rational such as Spotify’s Data, Insight, Belief, Bet model? Are you using a project portfolio, a product portfolio, or both? As a single product-focused team, it was “all for one and one for all.” Now you have multiple products and an inevitable sense of internal competition. “What has that other team done for us lately?” Accountability for timelines and results becomes an increasing conversation, now that communication is fragmented across multiple teams who are all starting to develop micro-cultures.
- Execution means the combination of supply with demand. How do you manage for flow, in a multi-team delivery environment? The idea of loosely coupled microservices is great, but sometimes everyone needs to get on the same release train. Do all your teams have the same sense of overall mission? And what about process? ITIL? It can help with coordination (I think the Change process is key, if it’s managed correctly). But processes can proliferate like rabbits. Every time the slightest thing goes wrong, “put in a new process” and pretty soon all you are doing is following processes, not delivering value. I’m very concerned about any frameworks or best practice guidance that might lead people to putting in more processes than their organization can handle, in terms of execution management. This is probably the most poorly understood area of the new Digital Operating Model. We need to look to disciplines like Industrial Operations Research for help here.
- Finally, you’ve hit the Enterprise level. I’m going to reiterate that this discussion of operating models is based on what you formalize as a capability. You’ve been thinking about security, governance, information, and architecture all along. But now you need to formalize them. Again, just as many drop out of organizations when they reach the “Team of Teams” level (“too much bureaucracy!”) some drop out of the conversation here. But enterprise concerns are real and unforgiving. You’re now highly conscious of the external forces acting on you, from hackers to regulators to auditors, and you can no longer afford tactical, fire-fighting responses. You need things like Enterprise Risk Management, policies, and so forth – they are not optional for enterprises. However, there are promising approaches for handling such requirements in new ways, in the digital operating model of the future.
- Governance is inevitable whenever an investor is distinct from a company. It’s called the “Other People’s Money” problem and is as old as money. Governance is not management; they are two different things and I recommend reading COBIT on that specific topic. The problem with digital governance is that it has been very focused around efficiency and too often tries to reduce variability in inherently uncertain activities, like software development. (This issue has been at the heart of the Agile movement). But there’s growing awareness of a huge paradox. Trouble is, when you put in a bunch of control processes (like project change stage gates, or required deliverables) as risk reducers, you wind up increasing the risk of losing your investment, because you slow down fast feedback. There’s irony for you! On the goodness side, auditors are already learning to love infrastructure as code and continuous delivery/DevOps, because they see that these approaches are more consistent and leave better audit trails. We’re in the middle of a big shift here, very exciting.
- “What do you mean by that?” It’s a simple 5 word question that can lead to years of debate. And at scale, across multiple product and business lines, it needs ongoing attention. When you’ve got 5 microservices managing various data, the teams can work it out themselves. But when you are up to 1500 microservices, how do you know that #1501 isn’t duplicating some data that some other service is handling perfectly well? The idea of the single enterprise data model hasn’t worked out well, but we still need some sense-making method here, if only because regulators are interested in data that constitute official “records.” Such records may or may not have to stay within one country, or may need to be sequestered if subpoenaed. You need to keep data as long as required and no longer, and the industry is starting to see a major convergence of classic records management with IT-related data management.
- Ah, architecture. My old home. At best, a rewarding and creative position full of value adding potential. At worst, you’re the one everyone loves to hate. But again, at scale, you need a cadre of folks who have a certain skill with abstractions. If you are successful company, you have these people, whether they call themselves architects or not. Technical debt – it’s a real thing. Getting out of it requires careful strategy and analysis, usually across complex product portfolios with a lot of contending interests at stake. But architects have GOT to understand that their job is to test hypotheses, not issue mandates, and in general, the more they can stay plugged into real hands-on technology the longer their career will last.
- Pivoting… Education requires you to have a clear theory of sequence, what order you introduce topics in and their dependencies. This is called a “learning progression.” We use a couple different learning progressions for teaching digital: the Stack and the Lifecycle. In the stack (CS & IS approach), we learn abstractions, either bottom-up (CS) or top down (IS). In the lifecycle (SE), we learn the pipeline, but right now it’s heavily waterfall: requirements courses, architecture courses, implementation courses, testing/QA courses, all separate
- This is an important conceptual point, you may need to think about. Whichever of these dimensions you choose as the main dimension for your learning progression, you have to collapse or subordinate the other two, because time, it’s a linear thing. If we teach using emergence, scale, as the main learning progression, we need full stack, full lifecycle from day 1: a DevOps walking skeleton! I call it Minimum Viable Pedagogy – it’s full stack & full lifecycle
- The emergence model provides a new narrative, a new learning progression, and a new way of understanding organizational maturity. Using it we can improve our discussions of the various areas and concerns we see in digital management, and perhaps pave the way to a new, integrated view of our profession.
- Thank you and open it up to questions