Alexander von Zitzewitz

Many organizations have the urgent need to modernize applications that have grown over the years and are not in very good architectural shape anymore. Often those monoliths resemble more the dreaded big ball of mud than a well organized software system. Modernization might mean migration to micro services or to a cleaner architecture based on Domain Driven Design. But before you can start with the big modernization you should analyze what you have. That allows you to estimate if building from scratch might be cheaper after all.

The workshop will first introduce the foundations of good software architecture, important architectural styles and characteristics as well as the concept of fitness functions. We also will introduce the concept of architectural pattern languages and discuss architectural decay often caused by ever increasing cyclical dependencies and how to deal with that. From there on we will make a journey through the universe of relevant software metrics and introduce metrics like Average Component Dependency, Propagation Cost and Maintainability Level.

Then we will cover architectural governance that will allow the automatic enforcement of architectural models with tools like ArchUnit or Sonargraph. The remaining time will be used by doing a live analysis on some famous open source projects. The user can follow along on his own code base provided he/she previously installed Sonargraph-Explorer, a completely free tool for metrics gathering and dependency visualization. After that we will discuss how to breakup software modules into smaller more modular units. Time permitting we will end the workshop with a live software breakup demo using a commercial tool (no free tools are available for this particular task). The users will be provided with a 3 months free license of that tool, so that they can apply the new knowledge in their own work environment.

Itemized content:

• What is architecture
• Architectural patterns
• Architecture characteristics (-illities)
• Architecture pattern languages
• Architectural fitness functions
• Software metrics for architects
• Architectural smells
• Why cyclic dependencies are bad and how to break them
• Architectural models and architectural governance
• Monolith assessment checklist
• Live analysis (where you can follow along on your own code)
• Tracking metrics over time
• Tools and methods for architectural governance (open source and commercial tools)

If you'd like to follow along and get metrics for your own code I recommend to register on www.hello2morrow.com (mention ArchConf in the “where you found us” field) and download Sonargraph. The workshop comes with a 3 months free license for the tool. Here is the activation code: 2E59-91C5-6439-7688.

Analyzing architecture is all about finding structural decay in applications and systems to determine whether the architecture is still satisfying the business concerns (performance, scalability, fault tolerance, availability, and so on) and also whether the architecture supporting the application functionality is still viable. This is known as “architectural vitality”. While the functionality of a system may be sound, the architecture supporting that functionality may not be. For example, performance and scalability may have been the number one concern 5 years ago, but today agility, testability, and deployability is the number one concern to support high levels of competitive advantage and time-to-market. Does the architecture support these “-ilities”? If not, the company is likely to fail in today’s highly competitive market.

In this intense 1-day hands-on workshop you will learn what structural decay means and how to detect it. You will also learn what it means to “analyze an architecture”, and how to measure and quantify various “-ilities” such as performance, scalability, testability, maintainability, and so on. Leveraging source code metrics and open-source analysis tools, you will then see how to apply micro-level (source code) analysis techniques to identify decay in your architecture. You will also learn how to perform risk analysis against your architecture to help identify and prioritize architectural refactoring efforts, and also how to assess the level of modularity in your application in preparation for the move to microservices.

While the analysis techniques taught in this class are largely platform and technology-agnostic, most of the analysis tools we will be using will be in Java.

Requirements
A laptop is recommended for this workshop so you can follow along with the class exercises.

Prerequisites
The desire to find out whether you have a sound and viable architecture supporting your systems and applications. There are no technical or architectural prerequisites for the class.

A good software architecture is the foundation for any successful software system. Your architectural choices affect almost every aspect of the software you are building from maintainability to stability, scalability and cyber vulnerability. Matching software architecture patterns and styles with requirements is a difficult task that requires knowledge and experience as well as the willingness to pick the right trade-offs.
Way too often the originally intended architecture erodes during the development process making the software harder to understand, to maintain and to adapt to changing requirements. By losing architectural coherence you also lose all the other benefits coming from a good architectural foundation. This drives up cost, reduces the happiness of your development team and ultimately will also impact the users of your software negatively.

Join expert Alexander von Zitzewitz to learn the foundations of good architecture. You’ll explore the concept of architecture styles and architectural fitness functions and dive into software metrics with architectural relevance. You’ll also investigate architectural smells like cyclic dependencies and bottleneck classes along with ways to refactor to prevent quality issues.

After learning the fundamentals, you’ll do some real code analysis using a free tool called Sonargraph-Explorer. Get hands-on with basic assessment and analysis techniques as well as techniques and methods for breaking up or restructuring monolithic applications—and measure your progress every step of the way. Then we will talk about how you can enforce architectural models during development and therefore avoid the common problem of architectural erosion in the first place. At the end, we will look at techniques to break up monolithic applications into more manageable pieces.

Most nontrivial software systems suffer from significant levels of technical and architectural debt. This leads to exponentially increasing cost of change, which is not sustainable for a longer period of time. The single best thing you can do to counter this problem is to carefully manage and control the dependencies among the different elements and components of a software system.

This session will first look at the major reasons why so many systems end up in an unmaintainable state and then show how to address the problem by defining an enforceable architectural blue-print for a software system using an innovative domain-specific language for the description of software architecture. I the workshop part you will be able to create an architectural blueprint for a system of your choice. See workshop requirements for details.

Here are a couple things we will go over:

• Modules vs. Architecture - how do modules fit into architectural models.
• Micro services vs. smart monoliths.
• Describing architectural blueprints with a domain specific language for architecture.

Most nontrivial software systems suffer from significant levels of technical and architectural debt. This leads to exponentially increasing cost of change, which is not sustainable for a longer period of time. The single best thing you can do to counter this problem is to give some love to your architecture by carefully managing and controlling the dependencies among the different elements and components of a software system. For that purpose we will introduce a DSL (domain specific language) that can be used to describe and enforce architectural blueprints. Moreover we will make an excursion into the topic of legacy software modernization.

In this workshop part participants will use Sonargraph to assess and analyze a software system of their choice (Java, C/C++, C# or Python) and design an architectural model using the domain specific language introduced in the session. The tool and a free 60 day license will be provided during the workshop.

Most nontrivial software systems suffer from significant levels of technical and architectural debt. This leads to exponentially increasing cost of change, which is not sustainable for a longer period of time. The single best thing you can do to counter this problem is to give some love to your architecture by carefully managing and controlling the dependencies among the different elements and components of a software system. This session will first look at the major reasons why so many systems end up in an unmaintainable state and then show how to address the problem by using automated quality gates in combination with a domain-specific language that can be used to enforce an architectural blueprint over the lifetime of a software system.

In the workshop part participants will use Sonargraph to assess and analyze a software system of their choice (Java, C/C++ or C#) and design an architectural model using the domain specific language introduced in the session. The tool and a free 30 day license will be provided during the workshop.

Software metrics can be used effectively to judge the maintainability and architectural quality of a code base. Even more importantly, they can be used as canaries in a coal mine to warn early about dangerous accumulations of architectural and technical debt.

First we will introduce some key metrics that every architect should know (e.g., average component dependency, propagation cost, structural debt index, and more). Then we talks about the journey to create a metric to measure maintainability and introduces a new metric maintainability level. This metric is promising because its value usually matches quite well the gut feeling of developers about the maintainability of their software systems. Also covered is the use of free and commercial tools to gather metrics and follow their trends in an automated way.

Software metrics can be used effectively to judge the maintainability and architectural quality of a code base. Even more importantly they can be used as “canaries in a coal mine” to warn early about dangerous accumulations of architectural and technical debt.

This session will introduce some key metrics that every architect should know and also looks into the current research regarding software architecture metrics. Since we have 90 minutes there will be some time for hands-on software assessments. If you'd like to follow along bring your laptop and install Sonargraph-Explorer from our website www.hello2morrow.com. (It's free and covers most of the metrics we will introduce) Bring a Java, C#, C/C++ or project and run the metrics on your own code. Or just download an open source project and learn how to use metrics to assess software and detect issues.

Software metrics can be used effectively to judge the maintainability and architectural quality of a code base. Even more importantly they can be used as “canaries in a coal mine” to warn early about dangerous accumulations of architectural and technical debt. Therefore using the right metrics can improve project governance and outcomes.

The session will introduce some key metrics that every tech leader should understand.

Software architecture can be defined as the internal structure of a software system. As such it influences many critical aspects of software systems like maintainability, comprehensibility, changeability and security. One would think that given the importance of a good architecture most systems would be well structured and not suffer from large amounts of structural or architectural erosion. Just the opposite is true. Most non-trivial systems with more than 100,000 lines of code are in bad shape and require enormous efforts to keep them alive. Developers spend most of their time with figuring out complex interdependencies in the code base.

After analyzing the reasons why so many systems end up in bad shape we will focus on strategies to improve the situation.(Spoiler: Micro Services are usually NOT the solution for this problem)

One of my favored punch lines is “you get the big ball of mud for free”. It is funny because most of us have to deal with big balls of mud on a daily base and are not too happy about it. Working on a big ball of mud literally makes everything harder and more complicated.

• Modularization? Wouldn’t that be nice…
• Reuse? Not happening, too much coupling…
• Regression bugs? Plenty of them…
• Simplify or modernize code? Too risky…

Those are just a few of the many issues with big balls of mud.

I think it is fair to say that most of us would prefer to work on a clean and well architected piece of software. So why is that so hard to achieve? Why do more than 80% of non-trivial projects end up as big balls of mud? And what can we do to guarantee that this never happens again to us? Aren’t micro-services supposed to solve this problem?

In this presentation, I will address all those questions and then explain some simple but proven strategies to avoid that dreaded outcome.