Selling CDK to an Old-School DevOps org

Hey - we're fans, so the concept of Infrastructure as Code (IaC) to help manage infrastructure makes sense to us. But it is not an easy sell to everyone. This talk is about the effort I had to go through to get an "old-school" DevOps organization to come around and use IaC to manage their infrastructure.

Managing the complexities of multi-party integrations

Modern technology and SAAS systems easily support piecing together multiple "best-of-breed" applications, each specializing in a part of the business process. You can impower those systems even more by exchanging bits of pieces of information. However, doing so can lead to a series of unfortunate events as these data points either slowly drift apart or lead to more and more complex integrations. In this session we will go over an approach to manage this and help control the complexities of multi-party integrations,

Are we done yet?

The definition of “done” is a historic problem in software development. Developers and their product stakeholders tend to look at this problem as “how well the delivered product matches the requirements.” However, there is another problem with “done”, and that is the evaluation as to when a release is ready to be set free to run amok in the wild. This becomes even more complicated when we look at things like working in the cloud where your release may include new system resources – are those “done” at a different time? In a period of continuous release cycles - are things ever done?

This session is based on stories around determining done-ness. We will look at test-cases and test-paths as an evaluation criteria. We will talk about how UI interactions affect the ability to determine “done.” We will also look at risk enhancers, such as configurable business logic, CI/CD, and Infrastructure as Code, and how those enhancers affect our ability to be understand “done.” Lastly, we will discuss some real-world stories about the QA of complicated systems.

Software and Database Refactor Patterns

Many of us are working on enhancing and maintaining systems that have some longevity. Changing these systems in any meaningful manner is dangerous. I learned during my years as a consultant that one of the most common problems that companies have when trying to revitalize applications is understanding where to start. In this session we will talk about various software and database refactor patterns that are designed to limit that danger, ensure forethought and planning around any major refactoring efforts, and give confidence around the likelihood of success for a refactoring.

We will talk about various reasons for refactoring an application and discuss those patterns commonly used to support that refactor. As part of this discussion we will also talk about external factors, such as team size and experience, can affect the success around various pattern implementations.

Modernizing an existing system to take a more domain-driven approach

Domain-driven design seems “straight-forward” when looking at green field development. Implementing that in an existing enterprise system, however, is daunting. In this workshop we will demonstrate the steps necessary in refactoring a non-DDD SOA-based system using DDD approaches, especially Command-Query Responsibility Segregation (CQRS) and Event Sourcing patterns.

The use of a service-oriented architecture is not new. There are thousands of existing enterprise systems that are built using SOA. This would typically look like a set of “client applications” that talk to a set of “back-end services” that were designed using a one-size-fits-all approach, where the representation of a persisted object is a union of all the business needs. The growth in domain-driven design shows how that may not be the best approach.

This session will be a dive into the process of modernizing a SOA-based enterprise system to support a DDD approach. We will talk about what this looks like at a high level and then demonstrate how this is supported by using Command-Query Responsibility Segregation (CQRS) and Event Sourcing.

Simply put, CQRS is an approach where different models are used when reading information than is used when updating that information. This approach becomes especially important as designs start being domain-driven, because each participant in the enterprise may have a different representation of that information. These different representations would be best managed with separate models. As part of this session, we will demonstrate (sometimes in code):

- What a non-CQRS approach looks like (current state)
- What a CQRS approach looks like (new state)
- How you manage data conversion
- Why we would take this approach
- How to tell when you have gone wrong

Event sourcing is an approach where all of the changes to application state are stored as a list, or sequence, of events. As part of this session we will walk through (sometimes in code):

- How event sourcing fits into DDD
- How this need is managed now (current state)
- What the implementation looks like
- How you manage the conversion
- How you can evaluate the effectiveness

Lastly, we will walk through how these changes fit into the overall modernization strategy.

Building Trust as a Development Organization

There are countless anecdotes about trust and development organizations; many of which are negative. This is well recognized and most organizations have taken steps to try and remedy that problem. However, many of those approaches either fail or are not as successful as hoped. In this session, we will go through the different aspects of trust and how to take advantage of these aspects to enhance trust in inter-departmental relationships.

To do this, we will cover:

- What is trust, really?
- Why do we care about trust?
- What builds trust?
- What hurts trust?
- How do you repair trust?

My doctoral dissertation had a very strong focus on trust, and the more I learned about trust the more I realized that it was how I was able to successfully build effective development teams. This presentation has theory, real-world application of that theory, and an interactive component to help that participants understand their own feelings on trust.