�ݺ�ߣshows by User: SkeltonThatcher

�ݺ�ߣshows by User: SkeltonThatcher / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: SkeltonThatcher / Thu, 02 Nov 2017 17:57:08 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: SkeltonThatcher Practical operability techniques for teams - Matthew Skelton - Agile in the City Bristol 2017 /slideshow/practical-operability-techniques-for-teams-matthew-skelton-agile-in-the-city-bristol-2017/81522524 practical-operability-techniques-aitc-bristol-2017-171102175708
In this talk, Matthew Skelton (Skelton Thatcher Consulting) explores five practical, tried-and-tested, real-world techniques for improving operability with many kinds of software systems, including cloud, Serverless, on-premise, and IoT. Logging as a live diagnostics vector with sparse event IDs Operational checklists and 'run book dialogue sheets' as a discovery mechanism for teams Endpoint healthchecks as a way to assess runtime dependencies and complexity Correlation IDs beyond simple HTTP calls Lightweight 'User Personas' as drivers for operational dashboards These techniques work very differently with different technologies. For instance, an IoT device has limited storage, processing, and I/O, so generation and shipping of logs and metrics looks very different from the cloud or 'serverless' case. However, the principles - logging as a live diagnostics vector, event IDs for discovery, etc - work remarkably well across very different technologies. From a talk at Agile in the City Bristol 2017 http://agileinthecity.net/2017/bristol/sessions/index.php?session=44]]>
In this talk, Matthew Skelton (Skelton Thatcher Consulting) explores five practical, tried-and-tested, real-world techniques for improving operability with many kinds of software systems, including cloud, Serverless, on-premise, and IoT. Logging as a live diagnostics vector with sparse event IDs Operational checklists and 'run book dialogue sheets' as a discovery mechanism for teams Endpoint healthchecks as a way to assess runtime dependencies and complexity Correlation IDs beyond simple HTTP calls Lightweight 'User Personas' as drivers for operational dashboards These techniques work very differently with different technologies. For instance, an IoT device has limited storage, processing, and I/O, so generation and shipping of logs and metrics looks very different from the cloud or 'serverless' case. However, the principles - logging as a live diagnostics vector, event IDs for discovery, etc - work remarkably well across very different technologies. From a talk at Agile in the City Bristol 2017 http://agileinthecity.net/2017/bristol/sessions/index.php?session=44]]> Thu, 02 Nov 2017 17:57:08 GMT /slideshow/practical-operability-techniques-for-teams-matthew-skelton-agile-in-the-city-bristol-2017/81522524 SkeltonThatcher@slideshare.net(SkeltonThatcher) Practical operability techniques for teams - Matthew Skelton - Agile in the City Bristol 2017 SkeltonThatcher In this talk, Matthew Skelton (Skelton Thatcher Consulting) explores five practical, tried-and-tested, real-world techniques for improving operability with many kinds of software systems, including cloud, Serverless, on-premise, and IoT. Logging as a live diagnostics vector with sparse event IDs Operational checklists and 'run book dialogue sheets' as a discovery mechanism for teams Endpoint healthchecks as a way to assess runtime dependencies and complexity Correlation IDs beyond simple HTTP calls Lightweight 'User Personas' as drivers for operational dashboards These techniques work very differently with different technologies. For instance, an IoT device has limited storage, processing, and I/O, so generation and shipping of logs and metrics looks very different from the cloud or 'serverless' case. However, the principles - logging as a live diagnostics vector, event IDs for discovery, etc - work remarkably well across very different technologies. From a talk at Agile in the City Bristol 2017 http://agileinthecity.net/2017/bristol/sessions/index.php?session=44 <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/practical-operability-techniques-aitc-bristol-2017-171102175708-thumbnail.jpg?width=120&height=120&fit=bounds" /> In this talk, Matthew Skelton (Skelton Thatcher Consulting) explores five practical, tried-and-tested, real-world techniques for improving operability with many kinds of software systems, including cloud, Serverless, on-premise, and IoT. Logging as a live diagnostics vector with sparse event IDs Operational checklists and 'run book dialogue sheets' as a discovery mechanism for teams Endpoint healthchecks as a way to assess runtime dependencies and complexity Correlation IDs beyond simple HTTP calls Lightweight 'User Personas' as drivers for operational dashboards These techniques work very differently with different technologies. For instance, an IoT device has limited storage, processing, and I/O, so generation and shipping of logs and metrics looks very different from the cloud or 'serverless' case. However, the principles - logging as a live diagnostics vector, event IDs for discovery, etc - work remarkably well across very different technologies. From a talk at Agile in the City Bristol 2017 http://agileinthecity.net/2017/bristol/sessions/index.php?session=44

Practical operability techniques for teams - Matthew Skelton - Agile in the City Bristol 2017 from Skelton Thatcher Consulting Ltd

]]> 1142 6 https://cdn.slidesharecdn.com/ss_thumbnails/practical-operability-techniques-aitc-bristol-2017-171102175708-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Practical operability techniques for distributed systems - Velocity EU 2017 /slideshow/practical-operability-techniques-for-distributed-systems-velocity-eu-2017/80995266 practical-operability-techniques-velocity-eu-2017-171019194139
Modern software systems now increasingly span cloud and on-premises deployments and remote embedded devices and sensors. These distributed systems bring challenges with data, connectivity, performance, and systems management; to ensure success, you must design and build with operability as a first-class property. Matthew Skelton shares five practical, tried-and-tested techniques for improving operability with many kinds of software systems, including the cloud, serverless, on-premises, and the IoT: logging as a live diagnostics vector with sparse event IDs; operational checklists and runbook dialog sheets as a discovery mechanism for teams; endpoint health checks as a way to assess runtime dependencies and complexity; correlation IDs beyond simple HTTP calls; and lightweight user personas as drivers for operational dashboards. These techniques work very differently with different technologies. For instance, an IoT device has limited storage, processing, and I/O, so generating and shipping of logs and metrics looks very different from cloud or serverless cases. However, the principles—logging as a live diagnostics vector, event IDs for discovery, etc.—work remarkably well across very different technologies. Drawing from his experience helping teams improve the operability of their software systems, Matthew explains what works (and what doesn’t) and how teams can expand their understanding and awareness of operability through these straightforward, team-friendly techniques. From a talk given by Matthew Skelton at Velocity Conference EU 2017 - https://conferences.oreilly.com/velocity/vl-eu/public/schedule/detail/61954]]>
Modern software systems now increasingly span cloud and on-premises deployments and remote embedded devices and sensors. These distributed systems bring challenges with data, connectivity, performance, and systems management; to ensure success, you must design and build with operability as a first-class property. Matthew Skelton shares five practical, tried-and-tested techniques for improving operability with many kinds of software systems, including the cloud, serverless, on-premises, and the IoT: logging as a live diagnostics vector with sparse event IDs; operational checklists and runbook dialog sheets as a discovery mechanism for teams; endpoint health checks as a way to assess runtime dependencies and complexity; correlation IDs beyond simple HTTP calls; and lightweight user personas as drivers for operational dashboards. These techniques work very differently with different technologies. For instance, an IoT device has limited storage, processing, and I/O, so generating and shipping of logs and metrics looks very different from cloud or serverless cases. However, the principles—logging as a live diagnostics vector, event IDs for discovery, etc.—work remarkably well across very different technologies. Drawing from his experience helping teams improve the operability of their software systems, Matthew explains what works (and what doesn’t) and how teams can expand their understanding and awareness of operability through these straightforward, team-friendly techniques. From a talk given by Matthew Skelton at Velocity Conference EU 2017 - https://conferences.oreilly.com/velocity/vl-eu/public/schedule/detail/61954]]> Thu, 19 Oct 2017 19:41:39 GMT /slideshow/practical-operability-techniques-for-distributed-systems-velocity-eu-2017/80995266 SkeltonThatcher@slideshare.net(SkeltonThatcher) Practical operability techniques for distributed systems - Velocity EU 2017 SkeltonThatcher Modern software systems now increasingly span cloud and on-premises deployments and remote embedded devices and sensors. These distributed systems bring challenges with data, connectivity, performance, and systems management; to ensure success, you must design and build with operability as a first-class property. Matthew Skelton shares five practical, tried-and-tested techniques for improving operability with many kinds of software systems, including the cloud, serverless, on-premises, and the IoT: logging as a live diagnostics vector with sparse event IDs; operational checklists and runbook dialog sheets as a discovery mechanism for teams; endpoint health checks as a way to assess runtime dependencies and complexity; correlation IDs beyond simple HTTP calls; and lightweight user personas as drivers for operational dashboards. These techniques work very differently with different technologies. For instance, an IoT device has limited storage, processing, and I/O, so generating and shipping of logs and metrics looks very different from cloud or serverless cases. However, the principles—logging as a live diagnostics vector, event IDs for discovery, etc.—work remarkably well across very different technologies. Drawing from his experience helping teams improve the operability of their software systems, Matthew explains what works (and what doesn’t) and how teams can expand their understanding and awareness of operability through these straightforward, team-friendly techniques. From a talk given by Matthew Skelton at Velocity Conference EU 2017 - https://conferences.oreilly.com/velocity/vl-eu/public/schedule/detail/61954 <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/practical-operability-techniques-velocity-eu-2017-171019194139-thumbnail.jpg?width=120&height=120&fit=bounds" /> Modern software systems now increasingly span cloud and on-premises deployments and remote embedded devices and sensors. These distributed systems bring challenges with data, connectivity, performance, and systems management; to ensure success, you must design and build with operability as a first-class property. Matthew Skelton shares five practical, tried-and-tested techniques for improving operability with many kinds of software systems, including the cloud, serverless, on-premises, and the IoT: logging as a live diagnostics vector with sparse event IDs; operational checklists and runbook dialog sheets as a discovery mechanism for teams; endpoint health checks as a way to assess runtime dependencies and complexity; correlation IDs beyond simple HTTP calls; and lightweight user personas as drivers for operational dashboards. These techniques work very differently with different technologies. For instance, an IoT device has limited storage, processing, and I/O, so generating and shipping of logs and metrics looks very different from cloud or serverless cases. However, the principles—logging as a live diagnostics vector, event IDs for discovery, etc.—work remarkably well across very different technologies. Drawing from his experience helping teams improve the operability of their software systems, Matthew explains what works (and what doesn’t) and how teams can expand their understanding and awareness of operability through these straightforward, team-friendly techniques. From a talk given by Matthew Skelton at Velocity Conference EU 2017 - https://conferences.oreilly.com/velocity/vl-eu/public/schedule/detail/61954

Practical operability techniques for distributed systems - Velocity EU 2017 from Skelton Thatcher Consulting Ltd

]]> 1316 5 https://cdn.slidesharecdn.com/ss_thumbnails/practical-operability-techniques-velocity-eu-2017-171019194139-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Practical operability techniques for teams - IPEXPO 2017 /slideshow/practical-operability-techniques-for-teams-ipexpo-2017/80496156 practical-operability-techniques-ipexpo-2017-171005132252
Modern software systems now increasingly span cloud, on-premise, and remote embedded devices & sensors. These distributed systems bring challenges with data, connectivity, performance, and systems management, so for business success we need to design and build with operability as a first class property. In this talk, we explore five practical, tried-and-tested, real world techniques for improving operability with many kinds of software systems, including cloud, Serverless, on-premise, and IoT: - Logging as a live diagnostics vector with sparse Event IDs - Operational checklists and 'Run Book dialogue sheets' as a discovery mechanism for teams - Endpoint healthchecks as a way to assess runtime dependencies and complexity - Correlation IDs beyond simple HTTP calls - Lightweight 'User Personas' as drivers for operational dashboards These techniques work very differently with different technologies. For instance, an IoT device has limited storage, processing, and I/O, so generation and shipping of logs and metrics looks very different from the cloud or Serverless case. However, the principles - logging as a live diagnostics vector, Event IDs for discovery, etc. - work remarkably well across very different technologies.]]>
Modern software systems now increasingly span cloud, on-premise, and remote embedded devices & sensors. These distributed systems bring challenges with data, connectivity, performance, and systems management, so for business success we need to design and build with operability as a first class property. In this talk, we explore five practical, tried-and-tested, real world techniques for improving operability with many kinds of software systems, including cloud, Serverless, on-premise, and IoT: - Logging as a live diagnostics vector with sparse Event IDs - Operational checklists and 'Run Book dialogue sheets' as a discovery mechanism for teams - Endpoint healthchecks as a way to assess runtime dependencies and complexity - Correlation IDs beyond simple HTTP calls - Lightweight 'User Personas' as drivers for operational dashboards These techniques work very differently with different technologies. For instance, an IoT device has limited storage, processing, and I/O, so generation and shipping of logs and metrics looks very different from the cloud or Serverless case. However, the principles - logging as a live diagnostics vector, Event IDs for discovery, etc. - work remarkably well across very different technologies.]]> Thu, 05 Oct 2017 13:22:52 GMT /slideshow/practical-operability-techniques-for-teams-ipexpo-2017/80496156 SkeltonThatcher@slideshare.net(SkeltonThatcher) Practical operability techniques for teams - IPEXPO 2017 SkeltonThatcher Modern software systems now increasingly span cloud, on-premise, and remote embedded devices & sensors. These distributed systems bring challenges with data, connectivity, performance, and systems management, so for business success we need to design and build with operability as a first class property. In this talk, we explore five practical, tried-and-tested, real world techniques for improving operability with many kinds of software systems, including cloud, Serverless, on-premise, and IoT: - Logging as a live diagnostics vector with sparse Event IDs - Operational checklists and 'Run Book dialogue sheets' as a discovery mechanism for teams - Endpoint healthchecks as a way to assess runtime dependencies and complexity - Correlation IDs beyond simple HTTP calls - Lightweight 'User Personas' as drivers for operational dashboards These techniques work very differently with different technologies. For instance, an IoT device has limited storage, processing, and I/O, so generation and shipping of logs and metrics looks very different from the cloud or Serverless case. However, the principles - logging as a live diagnostics vector, Event IDs for discovery, etc. - work remarkably well across very different technologies. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/practical-operability-techniques-ipexpo-2017-171005132252-thumbnail.jpg?width=120&height=120&fit=bounds" /> Modern software systems now increasingly span cloud, on-premise, and remote embedded devices & sensors. These distributed systems bring challenges with data, connectivity, performance, and systems management, so for business success we need to design and build with operability as a first class property. In this talk, we explore five practical, tried-and-tested, real world techniques for improving operability with many kinds of software systems, including cloud, Serverless, on-premise, and IoT: - Logging as a live diagnostics vector with sparse Event IDs - Operational checklists and 'Run Book dialogue sheets' as a discovery mechanism for teams - Endpoint healthchecks as a way to assess runtime dependencies and complexity - Correlation IDs beyond simple HTTP calls - Lightweight 'User Personas' as drivers for operational dashboards These techniques work very differently with different technologies. For instance, an IoT device has limited storage, processing, and I/O, so generation and shipping of logs and metrics looks very different from the cloud or Serverless case. However, the principles - logging as a live diagnostics vector, Event IDs for discovery, etc. - work remarkably well across very different technologies.

Practical operability techniques for teams - IPEXPO 2017 from Skelton Thatcher Consulting Ltd

]]> 549 4 https://cdn.slidesharecdn.com/ss_thumbnails/practical-operability-techniques-ipexpo-2017-171005132252-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Practical operability techniques for teams - webinar - Skelton Thatcher & Unicom /slideshow/practical-operability-techniques-for-teams-webinar-skelton-thatcher-unicom/80255394 practical-operability-webinar-skelton-thatcher-170928131454
Presenters: Matthew Skelton and Rob Thatcher, Skelton Thatcher Consulting Webinar: Operability is all about making software work well in Production. In this webinar, we explore practical, tried-and-tested, real world techniques for improving operability with many kinds of software systems, including cloud, Serverless, on-premise, and IoT: logging with Event IDs, Run Book dialogue sheets, endpoint healthchecks, correlation IDs, and lightweight User Personas. Target audience: Software Developer, Tester, Software Architect, DevOps Engineer, Delivery Manager, Head of Delivery, Head of IT. Benefits: Attendees will gain insights into operability and why this is important for modern software systems, along with practical experience of techniques to enhance operability in almost any software system they encounter. ]]>
Presenters: Matthew Skelton and Rob Thatcher, Skelton Thatcher Consulting Webinar: Operability is all about making software work well in Production. In this webinar, we explore practical, tried-and-tested, real world techniques for improving operability with many kinds of software systems, including cloud, Serverless, on-premise, and IoT: logging with Event IDs, Run Book dialogue sheets, endpoint healthchecks, correlation IDs, and lightweight User Personas. Target audience: Software Developer, Tester, Software Architect, DevOps Engineer, Delivery Manager, Head of Delivery, Head of IT. Benefits: Attendees will gain insights into operability and why this is important for modern software systems, along with practical experience of techniques to enhance operability in almost any software system they encounter. ]]> Thu, 28 Sep 2017 13:14:53 GMT /slideshow/practical-operability-techniques-for-teams-webinar-skelton-thatcher-unicom/80255394 SkeltonThatcher@slideshare.net(SkeltonThatcher) Practical operability techniques for teams - webinar - Skelton Thatcher & Unicom SkeltonThatcher Presenters: Matthew Skelton and Rob Thatcher, Skelton Thatcher Consulting Webinar: Operability is all about making software work well in Production. In this webinar, we explore practical, tried-and-tested, real world techniques for improving operability with many kinds of software systems, including cloud, Serverless, on-premise, and IoT: logging with Event IDs, Run Book dialogue sheets, endpoint healthchecks, correlation IDs, and lightweight User Personas. Target audience: Software Developer, Tester, Software Architect, DevOps Engineer, Delivery Manager, Head of Delivery, Head of IT. Benefits: Attendees will gain insights into operability and why this is important for modern software systems, along with practical experience of techniques to enhance operability in almost any software system they encounter. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/practical-operability-webinar-skelton-thatcher-170928131454-thumbnail.jpg?width=120&height=120&fit=bounds" /> Presenters: Matthew Skelton and Rob Thatcher, Skelton Thatcher Consulting Webinar: Operability is all about making software work well in Production. In this webinar, we explore practical, tried-and-tested, real world techniques for improving operability with many kinds of software systems, including cloud, Serverless, on-premise, and IoT: logging with Event IDs, Run Book dialogue sheets, endpoint healthchecks, correlation IDs, and lightweight User Personas. Target audience: Software Developer, Tester, Software Architect, DevOps Engineer, Delivery Manager, Head of Delivery, Head of IT. Benefits: Attendees will gain insights into operability and why this is important for modern software systems, along with practical experience of techniques to enhance operability in almost any software system they encounter.

Practical operability techniques for teams - webinar - Skelton Thatcher & Unicom from Skelton Thatcher Consulting Ltd

]]> 2462 2 https://cdn.slidesharecdn.com/ss_thumbnails/practical-operability-webinar-skelton-thatcher-170928131454-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Teams and monoliths - Matthew Skelton - London DevOps June 2017 /SkeltonThatcher/teams-and-monoliths-matthew-skelton-london-devops-june-2017 teams-and-monoliths-matthew-skelton-londondevops-june-2017-170607101255
Moving from a monolith to microservices can be daunting. How do we choose the right bounded contexts? How small should services be? Which teams should get which services? And how do we keep things from falling apart? By starting with the needs of the team, we can infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services. Talk given at London DevOps meetup group - June 2017 - https://www.meetup.com/London-DevOps/events/238827763/]]>
Moving from a monolith to microservices can be daunting. How do we choose the right bounded contexts? How small should services be? Which teams should get which services? And how do we keep things from falling apart? By starting with the needs of the team, we can infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services. Talk given at London DevOps meetup group - June 2017 - https://www.meetup.com/London-DevOps/events/238827763/]]> Wed, 07 Jun 2017 10:12:55 GMT /SkeltonThatcher/teams-and-monoliths-matthew-skelton-london-devops-june-2017 SkeltonThatcher@slideshare.net(SkeltonThatcher) Teams and monoliths - Matthew Skelton - London DevOps June 2017 SkeltonThatcher Moving from a monolith to microservices can be daunting. How do we choose the right bounded contexts? How small should services be? Which teams should get which services? And how do we keep things from falling apart? By starting with the needs of the team, we can infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services. Talk given at London DevOps meetup group - June 2017 - https://www.meetup.com/London-DevOps/events/238827763/ <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/teams-and-monoliths-matthew-skelton-londondevops-june-2017-170607101255-thumbnail.jpg?width=120&height=120&fit=bounds" /> Moving from a monolith to microservices can be daunting. How do we choose the right bounded contexts? How small should services be? Which teams should get which services? And how do we keep things from falling apart? By starting with the needs of the team, we can infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services. Talk given at London DevOps meetup group - June 2017 - https://www.meetup.com/London-DevOps/events/238827763/

Teams and monoliths - Matthew Skelton - London DevOps June 2017 from Skelton Thatcher Consulting Ltd

]]> 1412 6 https://cdn.slidesharecdn.com/ss_thumbnails/teams-and-monoliths-matthew-skelton-londondevops-june-2017-170607101255-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 How and why to design your teams for modern software - JAX DevOps - April 2017 /slideshow/how-and-why-todesign-your-teams-for-modern-software-jax-devops-april-2017/74453314 how-and-why-to-design-your-teams-jax-devops-april-2017-170405142918
For effective, modern, Cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams. A talk given at JAX DevOps London - April 2017]]>
For effective, modern, Cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams. A talk given at JAX DevOps London - April 2017]]> Wed, 05 Apr 2017 14:29:18 GMT /slideshow/how-and-why-todesign-your-teams-for-modern-software-jax-devops-april-2017/74453314 SkeltonThatcher@slideshare.net(SkeltonThatcher) How and why to design your teams for modern software - JAX DevOps - April 2017 SkeltonThatcher For effective, modern, Cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams. A talk given at JAX DevOps London - April 2017 <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/how-and-why-to-design-your-teams-jax-devops-april-2017-170405142918-thumbnail.jpg?width=120&height=120&fit=bounds" /> For effective, modern, Cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams. A talk given at JAX DevOps London - April 2017

How and why to design your teams for modern software - JAX DevOps - April 2017 from Skelton Thatcher Consulting Ltd

]]> 542 3 https://cdn.slidesharecdn.com/ss_thumbnails/how-and-why-to-design-your-teams-jax-devops-april-2017-170405142918-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 How and why to design your teams for modern software systems - Agile in Leeds meetup - March 2017 /slideshow/how-and-why-to-design-your-teams-for-modern-software-systems-agile-in-leeds-meetup-march-2017/73803861 how-and-why-to-design-your-teams-agile-in-leeds-march-2017-170328171305
For effective, modern, cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams. In summary, this talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. Takeaways: • The implications of Conway’s Law for software teams • Cognitive Load for teams • Effective team topologies • Team evolution]]>
For effective, modern, cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams. In summary, this talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. Takeaways: • The implications of Conway’s Law for software teams • Cognitive Load for teams • Effective team topologies • Team evolution]]> Tue, 28 Mar 2017 17:13:05 GMT /slideshow/how-and-why-to-design-your-teams-for-modern-software-systems-agile-in-leeds-meetup-march-2017/73803861 SkeltonThatcher@slideshare.net(SkeltonThatcher) How and why to design your teams for modern software systems - Agile in Leeds meetup - March 2017 SkeltonThatcher For effective, modern, cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams. In summary, this talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. Takeaways: • The implications of Conway’s Law for software teams • Cognitive Load for teams • Effective team topologies • Team evolution <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/how-and-why-to-design-your-teams-agile-in-leeds-march-2017-170328171305-thumbnail.jpg?width=120&height=120&fit=bounds" /> For effective, modern, cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams. In summary, this talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. Takeaways: • The implications of Conway’s Law for software teams • Cognitive Load for teams • Effective team topologies • Team evolution

How and why to design your teams for modern software systems - Agile in Leeds meetup - March 2017 from Skelton Thatcher Consulting Ltd

]]> 697 3 https://cdn.slidesharecdn.com/ss_thumbnails/how-and-why-to-design-your-teams-agile-in-leeds-march-2017-170328171305-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Using Rancher for highly available deployment services with GoCD and TeamCity /slideshow/using-rancher-for-highly-available-deployment-services-with-gocd-and-teamcity/71935976 rancher-and-gocd-matthew-skelton-amsterdam-cd-meetup-170208231211
Tools like GoCD and TeamCity are excellent components of advanced Continuous Delivery deployment systems. They help us focus on deployment pipelines and the flow of changes, rather than "builds" or "environments". We can further enhance these tools by using frameworks like Rancher to manage GoCD and TeamCity as highly available, always-on deployment services. In this talk, we'll see how to use Rancher to run deployment pipeline tooling like GoCD and TeamCity, and how this lets us focus on the important parts of Continuous Delivery: getting changes to Production safely and rapidly.]]>
Tools like GoCD and TeamCity are excellent components of advanced Continuous Delivery deployment systems. They help us focus on deployment pipelines and the flow of changes, rather than "builds" or "environments". We can further enhance these tools by using frameworks like Rancher to manage GoCD and TeamCity as highly available, always-on deployment services. In this talk, we'll see how to use Rancher to run deployment pipeline tooling like GoCD and TeamCity, and how this lets us focus on the important parts of Continuous Delivery: getting changes to Production safely and rapidly.]]> Wed, 08 Feb 2017 23:12:11 GMT /slideshow/using-rancher-for-highly-available-deployment-services-with-gocd-and-teamcity/71935976 SkeltonThatcher@slideshare.net(SkeltonThatcher) Using Rancher for highly available deployment services with GoCD and TeamCity SkeltonThatcher Tools like GoCD and TeamCity are excellent components of advanced Continuous Delivery deployment systems. They help us focus on deployment pipelines and the flow of changes, rather than "builds" or "environments". We can further enhance these tools by using frameworks like Rancher to manage GoCD and TeamCity as highly available, always-on deployment services. In this talk, we'll see how to use Rancher to run deployment pipeline tooling like GoCD and TeamCity, and how this lets us focus on the important parts of Continuous Delivery: getting changes to Production safely and rapidly. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/rancher-and-gocd-matthew-skelton-amsterdam-cd-meetup-170208231211-thumbnail.jpg?width=120&height=120&fit=bounds" /> Tools like GoCD and TeamCity are excellent components of advanced Continuous Delivery deployment systems. They help us focus on deployment pipelines and the flow of changes, rather than "builds" or "environments". We can further enhance these tools by using frameworks like Rancher to manage GoCD and TeamCity as highly available, always-on deployment services. In this talk, we'll see how to use Rancher to run deployment pipeline tooling like GoCD and TeamCity, and how this lets us focus on the important parts of Continuous Delivery: getting changes to Production safely and rapidly.

Using Rancher for highly available deployment services with GoCD and TeamCity from Skelton Thatcher Consulting Ltd

]]> 6233 3 https://cdn.slidesharecdn.com/ss_thumbnails/rancher-and-gocd-matthew-skelton-amsterdam-cd-meetup-170208231211-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 How and why to design your Teams for modern Software Systems - Matthew Skelton- DevOpsCon Munich 2016 /slideshow/how-and-why-to-design-your-teams-for-modern-software-systems-matthew-skelton-devopscon-munich-2016/69871020 designing-teams-for-modern-software-matthew-skelton-devopscon-2016-161206121416
For effective, modern, Cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams. Talk given at DevOpsCon Munich 2016 - https://devopsconference.de/session/how-and-why-to-design-your-teams-for-modern-software-systems/]]>
For effective, modern, Cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams. Talk given at DevOpsCon Munich 2016 - https://devopsconference.de/session/how-and-why-to-design-your-teams-for-modern-software-systems/]]> Tue, 06 Dec 2016 12:14:16 GMT /slideshow/how-and-why-to-design-your-teams-for-modern-software-systems-matthew-skelton-devopscon-munich-2016/69871020 SkeltonThatcher@slideshare.net(SkeltonThatcher) How and why to design your Teams for modern Software Systems - Matthew Skelton- DevOpsCon Munich 2016 SkeltonThatcher For effective, modern, Cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams. Talk given at DevOpsCon Munich 2016 - https://devopsconference.de/session/how-and-why-to-design-your-teams-for-modern-software-systems/ <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/designing-teams-for-modern-software-matthew-skelton-devopscon-2016-161206121416-thumbnail.jpg?width=120&height=120&fit=bounds" /> For effective, modern, Cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design, exploring a selection of key team topologies and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on experience helping companies around the world with the design of their teams. Talk given at DevOpsCon Munich 2016 - https://devopsconference.de/session/how-and-why-to-design-your-teams-for-modern-software-systems/

How and why to design your Teams for modern Software Systems - Matthew Skelton- DevOpsCon Munich 2016 from Skelton Thatcher Consulting Ltd

]]> 7296 7 https://cdn.slidesharecdn.com/ss_thumbnails/designing-teams-for-modern-software-matthew-skelton-devopscon-2016-161206121416-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Teams and monoliths - Matthew Skelton - Velocity EU 2016 /slideshow/teams-and-monoliths-matthew-skelton-velocity-eu-2016/68322207 teams-and-monoliths-matthew-skelton-velocity-eu-2016-161107130107
How to break apart a monolithic system safely without destroying your team - talk at Velocity Eu Amsterdam on 7 Nov 2016 You'll learn some team-first heuristics to use when decomposing large or monolithic software into smaller pieces. http://conferences.oreilly.com/velocity/devops-web-performance-eu/public/schedule/detail/52879]]>
How to break apart a monolithic system safely without destroying your team - talk at Velocity Eu Amsterdam on 7 Nov 2016 You'll learn some team-first heuristics to use when decomposing large or monolithic software into smaller pieces. http://conferences.oreilly.com/velocity/devops-web-performance-eu/public/schedule/detail/52879]]> Mon, 07 Nov 2016 13:01:07 GMT /slideshow/teams-and-monoliths-matthew-skelton-velocity-eu-2016/68322207 SkeltonThatcher@slideshare.net(SkeltonThatcher) Teams and monoliths - Matthew Skelton - Velocity EU 2016 SkeltonThatcher How to break apart a monolithic system safely without destroying your team - talk at Velocity Eu Amsterdam on 7 Nov 2016 You'll learn some team-first heuristics to use when decomposing large or monolithic software into smaller pieces. http://conferences.oreilly.com/velocity/devops-web-performance-eu/public/schedule/detail/52879 <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/teams-and-monoliths-matthew-skelton-velocity-eu-2016-161107130107-thumbnail.jpg?width=120&height=120&fit=bounds" /> How to break apart a monolithic system safely without destroying your team - talk at Velocity Eu Amsterdam on 7 Nov 2016 You'll learn some team-first heuristics to use when decomposing large or monolithic software into smaller pieces. http://conferences.oreilly.com/velocity/devops-web-performance-eu/public/schedule/detail/52879

Teams and monoliths - Matthew Skelton - Velocity EU 2016 from Skelton Thatcher Consulting Ltd

]]> 8429 7 https://cdn.slidesharecdn.com/ss_thumbnails/teams-and-monoliths-matthew-skelton-velocity-eu-2016-161107130107-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Teams and monoliths - Matthew Skelton - Agile in the City Bristol 2016 /slideshow/teams-and-monoliths-matthew-skelton-agile-in-the-city-bristol-2016/68199543 teams-and-monoliths-matthew-skelton-aitc-bristol-2016-161104163310
Moving from a monolith to microservices can be daunting. How do we choose the right bounded contexts? How small should services be? Which teams should get which services? And how do we keep things from falling apart? By starting with the needs of the team, we can infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services. ]]>
Moving from a monolith to microservices can be daunting. How do we choose the right bounded contexts? How small should services be? Which teams should get which services? And how do we keep things from falling apart? By starting with the needs of the team, we can infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services. ]]> Fri, 04 Nov 2016 16:33:09 GMT /slideshow/teams-and-monoliths-matthew-skelton-agile-in-the-city-bristol-2016/68199543 SkeltonThatcher@slideshare.net(SkeltonThatcher) Teams and monoliths - Matthew Skelton - Agile in the City Bristol 2016 SkeltonThatcher Moving from a monolith to microservices can be daunting. How do we choose the right bounded contexts? How small should services be? Which teams should get which services? And how do we keep things from falling apart? By starting with the needs of the team, we can infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/teams-and-monoliths-matthew-skelton-aitc-bristol-2016-161104163310-thumbnail.jpg?width=120&height=120&fit=bounds" /> Moving from a monolith to microservices can be daunting. How do we choose the right bounded contexts? How small should services be? Which teams should get which services? And how do we keep things from falling apart? By starting with the needs of the team, we can infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services.

Teams and monoliths - Matthew Skelton - Agile in the City Bristol 2016 from Skelton Thatcher Consulting Ltd

]]> 796 7 https://cdn.slidesharecdn.com/ss_thumbnails/teams-and-monoliths-matthew-skelton-aitc-bristol-2016-161104163310-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Teams and monoliths - Matthew Skelton - LondonCD 2016 /slideshow/teams-and-monoliths-matthew-skelton-londoncd-2016/67032982 teams-and-monoliths-matthew-skelton-londoncd-2016-161011222820
How to break apart a monolithic system safely without destroying your team Moving from a monolith to microservices can be daunting. How do we choose the right bounded contexts? How small should services be? Which teams should get which services? And how do we keep things from falling apart? By starting with the needs of the team, we can infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services. Matthew Skelton is co-founder of Skelton Thatcher Consulting / @matthewpskelton ]]>
How to break apart a monolithic system safely without destroying your team Moving from a monolith to microservices can be daunting. How do we choose the right bounded contexts? How small should services be? Which teams should get which services? And how do we keep things from falling apart? By starting with the needs of the team, we can infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services. Matthew Skelton is co-founder of Skelton Thatcher Consulting / @matthewpskelton ]]> Tue, 11 Oct 2016 22:28:20 GMT /slideshow/teams-and-monoliths-matthew-skelton-londoncd-2016/67032982 SkeltonThatcher@slideshare.net(SkeltonThatcher) Teams and monoliths - Matthew Skelton - LondonCD 2016 SkeltonThatcher How to break apart a monolithic system safely without destroying your team Moving from a monolith to microservices can be daunting. How do we choose the right bounded contexts? How small should services be? Which teams should get which services? And how do we keep things from falling apart? By starting with the needs of the team, we can infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services. Matthew Skelton is co-founder of Skelton Thatcher Consulting / @matthewpskelton <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/teams-and-monoliths-matthew-skelton-londoncd-2016-161011222820-thumbnail.jpg?width=120&height=120&fit=bounds" /> How to break apart a monolithic system safely without destroying your team Moving from a monolith to microservices can be daunting. How do we choose the right bounded contexts? How small should services be? Which teams should get which services? And how do we keep things from falling apart? By starting with the needs of the team, we can infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services. Matthew Skelton is co-founder of Skelton Thatcher Consulting / @matthewpskelton

Teams and monoliths - Matthew Skelton - LondonCD 2016 from Skelton Thatcher Consulting Ltd

]]> 3571 8 https://cdn.slidesharecdn.com/ss_thumbnails/teams-and-monoliths-matthew-skelton-londoncd-2016-161011222820-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Continuous Delivery Anti-patterns from the wild - Matthew Skelton- IPEXPO Europe /slideshow/continuous-delivery-antipatterns-from-the-wild-matthew-skelton-ipexpo-europe/66823483 continuous-delivery-antipatterns-from-the-wild-matthew-skelton-ipexpo-europe-2016-161006192736
Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not measuring delays between value-add activities - Ignoring Cost-of-Delay and job size - Not funding the build/test/deployment capability properly By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts. Attendees will learn: 1. Why Continuous Delivery (CD) is useful for almost all modern software 2. How to approach CD for databases 3. How to make CD really 'fly' within the organisation 4. How to 'sell' CD to business stakeholders ]]>
Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not measuring delays between value-add activities - Ignoring Cost-of-Delay and job size - Not funding the build/test/deployment capability properly By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts. Attendees will learn: 1. Why Continuous Delivery (CD) is useful for almost all modern software 2. How to approach CD for databases 3. How to make CD really 'fly' within the organisation 4. How to 'sell' CD to business stakeholders ]]> Thu, 06 Oct 2016 19:27:36 GMT /slideshow/continuous-delivery-antipatterns-from-the-wild-matthew-skelton-ipexpo-europe/66823483 SkeltonThatcher@slideshare.net(SkeltonThatcher) Continuous Delivery Anti-patterns from the wild - Matthew Skelton- IPEXPO Europe SkeltonThatcher Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not measuring delays between value-add activities - Ignoring Cost-of-Delay and job size - Not funding the build/test/deployment capability properly By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts. Attendees will learn: 1. Why Continuous Delivery (CD) is useful for almost all modern software 2. How to approach CD for databases 3. How to make CD really 'fly' within the organisation 4. How to 'sell' CD to business stakeholders <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/continuous-delivery-antipatterns-from-the-wild-matthew-skelton-ipexpo-europe-2016-161006192736-thumbnail.jpg?width=120&height=120&fit=bounds" /> Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not measuring delays between value-add activities - Ignoring Cost-of-Delay and job size - Not funding the build/test/deployment capability properly By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts. Attendees will learn: 1. Why Continuous Delivery (CD) is useful for almost all modern software 2. How to approach CD for databases 3. How to make CD really 'fly' within the organisation 4. How to 'sell' CD to business stakeholders

Continuous Delivery Anti-patterns from the wild - Matthew Skelton- IPEXPO Europe from Skelton Thatcher Consulting Ltd

]]> 6354 7 https://cdn.slidesharecdn.com/ss_thumbnails/continuous-delivery-antipatterns-from-the-wild-matthew-skelton-ipexpo-europe-2016-161006192736-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016 /slideshow/continuous-delivery-antipatterns-from-the-wild-matthew-skelton-ipexpo-manchester-2016-62155284/62155284 continuous-delivery-antipatterns-from-the-wild-matthew-skelton-ipexpo-manchester-2016-160518182823
Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not measuring delays between value-add activities - Ignoring Cost-of-Delay and job size - Not funding the build/test/deployment capability properly By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts. ]]>
Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not measuring delays between value-add activities - Ignoring Cost-of-Delay and job size - Not funding the build/test/deployment capability properly By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts. ]]> Wed, 18 May 2016 18:28:23 GMT /slideshow/continuous-delivery-antipatterns-from-the-wild-matthew-skelton-ipexpo-manchester-2016-62155284/62155284 SkeltonThatcher@slideshare.net(SkeltonThatcher) Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016 SkeltonThatcher Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not measuring delays between value-add activities - Ignoring Cost-of-Delay and job size - Not funding the build/test/deployment capability properly By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/continuous-delivery-antipatterns-from-the-wild-matthew-skelton-ipexpo-manchester-2016-160518182823-thumbnail.jpg?width=120&height=120&fit=bounds" /> Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not measuring delays between value-add activities - Ignoring Cost-of-Delay and job size - Not funding the build/test/deployment capability properly By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts.

Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016 from Skelton Thatcher Consulting Ltd

]]> 4401 6 https://cdn.slidesharecdn.com/ss_thumbnails/continuous-delivery-antipatterns-from-the-wild-matthew-skelton-ipexpo-manchester-2016-160518182823-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Continuous Delivery antipatterns from the wild - Matthew Skelton - Continuous Lifecycle London 2016 /slideshow/continuous-delivery-antipatterns-from-the-wild-matthew-skelton-continuous-lifecycle-london-2016/61665192 continuous-delivery-antipatterns-from-the-wild-matthew-skelton-continuous-lifecycle-2016-160504113401
(Talk given at Continuous Lifecycle London 2016) Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not funding the build/test/deployment capability properly - No effective logging or application metrics By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts. ]]>
(Talk given at Continuous Lifecycle London 2016) Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not funding the build/test/deployment capability properly - No effective logging or application metrics By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts. ]]> Wed, 04 May 2016 11:34:01 GMT /slideshow/continuous-delivery-antipatterns-from-the-wild-matthew-skelton-continuous-lifecycle-london-2016/61665192 SkeltonThatcher@slideshare.net(SkeltonThatcher) Continuous Delivery antipatterns from the wild - Matthew Skelton - Continuous Lifecycle London 2016 SkeltonThatcher (Talk given at Continuous Lifecycle London 2016) Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not funding the build/test/deployment capability properly - No effective logging or application metrics By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/continuous-delivery-antipatterns-from-the-wild-matthew-skelton-continuous-lifecycle-2016-160504113401-thumbnail.jpg?width=120&height=120&fit=bounds" /> (Talk given at Continuous Lifecycle London 2016) Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not funding the build/test/deployment capability properly - No effective logging or application metrics By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts.

Continuous Delivery antipatterns from the wild - Matthew Skelton - Continuous Lifecycle London 2016 from Skelton Thatcher Consulting Ltd

]]> 8663 6 https://cdn.slidesharecdn.com/ss_thumbnails/continuous-delivery-antipatterns-from-the-wild-matthew-skelton-continuous-lifecycle-2016-160504113401-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Why and how to test logging - DevOps Showcase North - Feb 2016 - Matthew Skelton /slideshow/why-and-how-to-test-logging-devops-showcase-north-feb-2016-matthew-skelton/58153100 why-and-how-to-test-logging-devops-showcase-north-feb-2016-matthew-skelton-160211145848
Modern log aggregation & search tools provide significant new capabilities for teams building, testing, and running software systems. By treating logging as a core system component, and using techniques such as unique event IDs, transaction tracing, and structured log output, we gain rich insights into application behaviour and health. This talk explains why it is valuable to test aspects of logging and how to do this with modern log aggregation tooling. ]]>
Modern log aggregation & search tools provide significant new capabilities for teams building, testing, and running software systems. By treating logging as a core system component, and using techniques such as unique event IDs, transaction tracing, and structured log output, we gain rich insights into application behaviour and health. This talk explains why it is valuable to test aspects of logging and how to do this with modern log aggregation tooling. ]]> Thu, 11 Feb 2016 14:58:47 GMT /slideshow/why-and-how-to-test-logging-devops-showcase-north-feb-2016-matthew-skelton/58153100 SkeltonThatcher@slideshare.net(SkeltonThatcher) Why and how to test logging - DevOps Showcase North - Feb 2016 - Matthew Skelton SkeltonThatcher Modern log aggregation & search tools provide significant new capabilities for teams building, testing, and running software systems. By treating logging as a core system component, and using techniques such as unique event IDs, transaction tracing, and structured log output, we gain rich insights into application behaviour and health. This talk explains why it is valuable to test aspects of logging and how to do this with modern log aggregation tooling. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/why-and-how-to-test-logging-devops-showcase-north-feb-2016-matthew-skelton-160211145848-thumbnail.jpg?width=120&height=120&fit=bounds" /> Modern log aggregation & search tools provide significant new capabilities for teams building, testing, and running software systems. By treating logging as a core system component, and using techniques such as unique event IDs, transaction tracing, and structured log output, we gain rich insights into application behaviour and health. This talk explains why it is valuable to test aspects of logging and how to do this with modern log aggregation tooling.

Why and how to test logging - DevOps Showcase North - Feb 2016 - Matthew Skelton from Skelton Thatcher Consulting Ltd

]]> 5378 10 https://cdn.slidesharecdn.com/ss_thumbnails/why-and-how-to-test-logging-devops-showcase-north-feb-2016-matthew-skelton-160211145848-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 How to bridge the Dev-DBA chasm - AgileYorkshire - Matthew Skelton /slideshow/how-to-bridge-the-devdba-chasm-agileyorkshire-matthew-skelton-55968824/55968824 the-dev-dba-gap-is-a-chasm-agileyorkshire-matthew-skelton-151209102334-lva1-app6892
Forget the gap between Dev and Ops - the gap between Devs and DBAs is a chasm. Here are some observations from the field about the causes of the rift and some ideas about how to close the gap (and even whether the gap is worth closing). Oh, and I'm writing a book about it.]]>
Forget the gap between Dev and Ops - the gap between Devs and DBAs is a chasm. Here are some observations from the field about the causes of the rift and some ideas about how to close the gap (and even whether the gap is worth closing). Oh, and I'm writing a book about it.]]> Wed, 09 Dec 2015 10:23:34 GMT /slideshow/how-to-bridge-the-devdba-chasm-agileyorkshire-matthew-skelton-55968824/55968824 SkeltonThatcher@slideshare.net(SkeltonThatcher) How to bridge the Dev-DBA chasm - AgileYorkshire - Matthew Skelton SkeltonThatcher Forget the gap between Dev and Ops - the gap between Devs and DBAs is a chasm. Here are some observations from the field about the causes of the rift and some ideas about how to close the gap (and even whether the gap is worth closing). Oh, and I'm writing a book about it. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/the-dev-dba-gap-is-a-chasm-agileyorkshire-matthew-skelton-151209102334-lva1-app6892-thumbnail.jpg?width=120&height=120&fit=bounds" /> Forget the gap between Dev and Ops - the gap between Devs and DBAs is a chasm. Here are some observations from the field about the causes of the rift and some ideas about how to close the gap (and even whether the gap is worth closing). Oh, and I'm writing a book about it.

How to bridge the Dev-DBA chasm - AgileYorkshire - Matthew Skelton from Skelton Thatcher Consulting Ltd

]]> 1801 4 https://cdn.slidesharecdn.com/ss_thumbnails/the-dev-dba-gap-is-a-chasm-agileyorkshire-matthew-skelton-151209102334-lva1-app6892-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 How to address operational aspects effectively with Agile practices - Matthew Skelton - Agile In The City 2015 /slideshow/how-to-address-operational-aspects-effectively-with-agile-practices-matthew-skelton-agile-in-the-city-2015/55343720 addressing-operational-aspects-within-agile-agileinthecity-skeltonthatcher-151120165339-lva1-app6891
Treating operational aspects of software as 'non-functional requirements' and 'an Ops problem' rather than a core part of the software product leads to poor live service and unexplained errors in Production. Traceability, deployability, recoverability, diagnosability, monitorability, and high quality logging are key features of a software system, along with user-visible features surfaced via the UI, or a capability of an API endpoint. However, many Product Owners understandably feel uneasy about taking on the (necessary) responsibility for prioritising operational features alongside user-visible and API features. This session brings Scrum Masters and Product Owners up to speed on operational features and covers proven practices for improving operability in an Agile context, empowering Product Owners to make effective prioritisation choices about all kinds of product features, whether user-visible or operational. ]]>
Treating operational aspects of software as 'non-functional requirements' and 'an Ops problem' rather than a core part of the software product leads to poor live service and unexplained errors in Production. Traceability, deployability, recoverability, diagnosability, monitorability, and high quality logging are key features of a software system, along with user-visible features surfaced via the UI, or a capability of an API endpoint. However, many Product Owners understandably feel uneasy about taking on the (necessary) responsibility for prioritising operational features alongside user-visible and API features. This session brings Scrum Masters and Product Owners up to speed on operational features and covers proven practices for improving operability in an Agile context, empowering Product Owners to make effective prioritisation choices about all kinds of product features, whether user-visible or operational. ]]> Fri, 20 Nov 2015 16:53:39 GMT /slideshow/how-to-address-operational-aspects-effectively-with-agile-practices-matthew-skelton-agile-in-the-city-2015/55343720 SkeltonThatcher@slideshare.net(SkeltonThatcher) How to address operational aspects effectively with Agile practices - Matthew Skelton - Agile In The City 2015 SkeltonThatcher Treating operational aspects of software as 'non-functional requirements' and 'an Ops problem' rather than a core part of the software product leads to poor live service and unexplained errors in Production. Traceability, deployability, recoverability, diagnosability, monitorability, and high quality logging are key features of a software system, along with user-visible features surfaced via the UI, or a capability of an API endpoint. However, many Product Owners understandably feel uneasy about taking on the (necessary) responsibility for prioritising operational features alongside user-visible and API features. This session brings Scrum Masters and Product Owners up to speed on operational features and covers proven practices for improving operability in an Agile context, empowering Product Owners to make effective prioritisation choices about all kinds of product features, whether user-visible or operational. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/addressing-operational-aspects-within-agile-agileinthecity-skeltonthatcher-151120165339-lva1-app6891-thumbnail.jpg?width=120&height=120&fit=bounds" /> Treating operational aspects of software as 'non-functional requirements' and 'an Ops problem' rather than a core part of the software product leads to poor live service and unexplained errors in Production. Traceability, deployability, recoverability, diagnosability, monitorability, and high quality logging are key features of a software system, along with user-visible features surfaced via the UI, or a capability of an API endpoint. However, many Product Owners understandably feel uneasy about taking on the (necessary) responsibility for prioritising operational features alongside user-visible and API features. This session brings Scrum Masters and Product Owners up to speed on operational features and covers proven practices for improving operability in an Agile context, empowering Product Owners to make effective prioritisation choices about all kinds of product features, whether user-visible or operational.

How to address operational aspects effectively with Agile practices - Matthew Skelton - Agile In The City 2015 from Skelton Thatcher Consulting Ltd

]]> 2457 9 https://cdn.slidesharecdn.com/ss_thumbnails/addressing-operational-aspects-within-agile-agileinthecity-skeltonthatcher-151120165339-lva1-app6891-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Long live the DevOps team - LeedsDevOps - 2015-10-22 - Matthew Skelton /slideshow/long-live-the-devops-team-leedsdevops-20151022-matthew-skelton/54300461 long-live-the-devops-team-leedsdevops-2015-matthew-skelton-151023113607-lva1-app6892
How do team topologies influence a DevOps culture? In this talk, we explore different kinds of organisational structures - some good for DevOps, some bad - and see how they affect the kind of collaboration and interaction between teams. Warning: hats are also involved.]]>
How do team topologies influence a DevOps culture? In this talk, we explore different kinds of organisational structures - some good for DevOps, some bad - and see how they affect the kind of collaboration and interaction between teams. Warning: hats are also involved.]]> Fri, 23 Oct 2015 11:36:07 GMT /slideshow/long-live-the-devops-team-leedsdevops-20151022-matthew-skelton/54300461 SkeltonThatcher@slideshare.net(SkeltonThatcher) Long live the DevOps team - LeedsDevOps - 2015-10-22 - Matthew Skelton SkeltonThatcher How do team topologies influence a DevOps culture? In this talk, we explore different kinds of organisational structures - some good for DevOps, some bad - and see how they affect the kind of collaboration and interaction between teams. Warning: hats are also involved. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/long-live-the-devops-team-leedsdevops-2015-matthew-skelton-151023113607-lva1-app6892-thumbnail.jpg?width=120&height=120&fit=bounds" /> How do team topologies influence a DevOps culture? In this talk, we explore different kinds of organisational structures - some good for DevOps, some bad - and see how they affect the kind of collaboration and interaction between teams. Warning: hats are also involved.

Long live the DevOps team - LeedsDevOps - 2015-10-22 - Matthew Skelton from Skelton Thatcher Consulting Ltd

]]> 907 4 https://cdn.slidesharecdn.com/ss_thumbnails/long-live-the-devops-team-leedsdevops-2015-matthew-skelton-151023113607-lva1-app6892-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Un-broken Logging - TechnologyUG - Leeds - Matthew Skelton /slideshow/unbroken-logging-technologyug-leeds-matthew-skelton/54272447 un-broken-logging-technologyug-leeds-matthew-skelton-151022172156-lva1-app6891
Talk at TechUG day in Leeds on 22nd October 2015 The way in which many (most?) software teams use logging needs a re-think as we move into a world of microservices and remote sensors. Instead of using logging merely to dump out stack traces, our logs become a continuous trace of application state, with unique-enough identifiers for every interesting point of execution. We also use transaction identifiers to trace calls across components, services, and queues, so that we can reconstruct distributed calls after the fact. Logging becomes a rich source of insight for developers and operations people alike, as we 'listen to the logs' and tighten feedback cycles to improve our software systems.]]>
Talk at TechUG day in Leeds on 22nd October 2015 The way in which many (most?) software teams use logging needs a re-think as we move into a world of microservices and remote sensors. Instead of using logging merely to dump out stack traces, our logs become a continuous trace of application state, with unique-enough identifiers for every interesting point of execution. We also use transaction identifiers to trace calls across components, services, and queues, so that we can reconstruct distributed calls after the fact. Logging becomes a rich source of insight for developers and operations people alike, as we 'listen to the logs' and tighten feedback cycles to improve our software systems.]]> Thu, 22 Oct 2015 17:21:56 GMT /slideshow/unbroken-logging-technologyug-leeds-matthew-skelton/54272447 SkeltonThatcher@slideshare.net(SkeltonThatcher) Un-broken Logging - TechnologyUG - Leeds - Matthew Skelton SkeltonThatcher Talk at TechUG day in Leeds on 22nd October 2015 The way in which many (most?) software teams use logging needs a re-think as we move into a world of microservices and remote sensors. Instead of using logging merely to dump out stack traces, our logs become a continuous trace of application state, with unique-enough identifiers for every interesting point of execution. We also use transaction identifiers to trace calls across components, services, and queues, so that we can reconstruct distributed calls after the fact. Logging becomes a rich source of insight for developers and operations people alike, as we 'listen to the logs' and tighten feedback cycles to improve our software systems. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/un-broken-logging-technologyug-leeds-matthew-skelton-151022172156-lva1-app6891-thumbnail.jpg?width=120&height=120&fit=bounds" /> Talk at TechUG day in Leeds on 22nd October 2015 The way in which many (most?) software teams use logging needs a re-think as we move into a world of microservices and remote sensors. Instead of using logging merely to dump out stack traces, our logs become a continuous trace of application state, with unique-enough identifiers for every interesting point of execution. We also use transaction identifiers to trace calls across components, services, and queues, so that we can reconstruct distributed calls after the fact. Logging becomes a rich source of insight for developers and operations people alike, as we 'listen to the logs' and tighten feedback cycles to improve our software systems.

Un-broken Logging - TechnologyUG - Leeds - Matthew Skelton from Skelton Thatcher Consulting Ltd

]]> 1496 4 https://cdn.slidesharecdn.com/ss_thumbnails/un-broken-logging-technologyug-leeds-matthew-skelton-151022172156-lva1-app6891-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 https://cdn.slidesharecdn.com/profile-photo-SkeltonThatcher-48x48.jpg?cb=1585326954 At Skelton Thatcher, we help our clients to understand, adopt, and sustain good practices for building and operating software systems. Our focus is on DevOps, Continuous Delivery, aspects of ITIL®, and software operability. skeltonthatcher.com/ https://cdn.slidesharecdn.com/ss_thumbnails/practical-operability-techniques-aitc-bristol-2017-171102175708-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/practical-operability-techniques-for-teams-matthew-skelton-agile-in-the-city-bristol-2017/81522524 Practical operability ... https://cdn.slidesharecdn.com/ss_thumbnails/practical-operability-techniques-velocity-eu-2017-171019194139-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/practical-operability-techniques-for-distributed-systems-velocity-eu-2017/80995266 Practical operability ... https://cdn.slidesharecdn.com/ss_thumbnails/practical-operability-techniques-ipexpo-2017-171005132252-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/practical-operability-techniques-for-teams-ipexpo-2017/80496156 Practical operability ...