Software Architecture Software Development Trust Leadership
Seattle, Washington, United States
With over 25 years in software development (almost 15 of which is .NET), Dr. Bill brings a pragmatic (curmudgeonly?) approach to software development. With much of that time spent in consulting, he has worked on many different projects and used many different designs and approaches. He is currently consulting for Unify Consulting in Seattle, WA where he works with companies looking for innovation within their application portfolio. In other words, he helps them write better systems...
One of the most complex areas in designing microservices is the combination of microservices, messaging, and data responsibility. How does it work if more than one microservice is interested in the same data? In this session we will go over the most effective approaches and discuss the kinds of use cases that each support.
If you listen to the 3 biggest players in public cloud, they will all try and convince you that they are the "best choice" for moving to the cloud. However, they all have their idiosyncrasies and those may be the determining factor in deciding which provider makes the most sense for you and your systems.
In this session we will go over those idiosyncrasies, what they mean to potential customers, and how they may affect onboarding and operations - all using real-world examples of where some things went well, and others not-so-well. We will also briefly cover hybrid clouds and how you can avoid putting all of your eggs into a single basket.
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.
If you listen to Microsoft, the future of .NET is rosy! Let’s take a scientific approach and really evaluate the future of .NET. In this session we will take a deep dive into an independent study on the future of .NET that talked to colleges and universities and coding camps to understand the role .NET has in computer classes as well as discussions with .NET shops and consultancies about their plans for using .NET in the future. Get a real understanding of the future, not some plush marketing spiel. Is there a future for .NET? Really?
Consulting isn’t for everyone, but is it for you? In this session we will look at the life of a software consultant. We’ll look at the differences between the various types of consultancies and the types of clients and projects that typically need consultant help. Lastly, we’ll talk about what makes for a consultant that the clients would like to bring back – not one they would like to take into a dark alley.
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.
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.
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.