Workshop: Evolving organisations using sociotechnical architecture
by João Rosa
To grow the software architecture community, focusing on essential practices, innovation, working software and practical solutions for current issues.
How to architects know the weight limits of a bridge?” asked Devon. “Well,” said Logan, “they continue to drive heavier and heavier trucks over the bridge until it collapses. Then they measure the weight of the last truck and post that weight on the rebuilt bridge”. “Oh, I guess that makes sense.” said Devon.
Software developers continuously test their source code using unit and functional tests to ensure the code works properly and contains no defects. But how does one test a software architecture? It turns out that testing a software architecture is just as important as testing your source code. In this session Mark Richards talks about what it means to test a software architecture. Mark starts out the session by discussing what things to test to ensure the architecture is structurally sound and that it’s meeting the designated goals of the business. He then shows how to construct various unit tests for software architecture using custom techniques as well as through common open source tools.
A question we have all heard is: “How do you measure success?” Those metrics can look different for different industries or professions, but they are rooted in hard measurable outcomes: larger revenue for a bank, bigger market share for an automaker, reduced readmission rate for a hospital chain. Those numbers are easy to put on a chart in an executive presentation. But what about software architecture? Measuring success of software architecture is difficult because software architecture is all about long-term effects, positive or negative. Software architecture metrics are hard to define and even harder to evaluate objectively. As soon as a metric becomes a goal, it ceases to be a good metric (think “number of lines of code”). And we know all too well that software architecture is subject to frequent changes - no other industry moves as fast. However, we still need to be able to set goal posts, measure outcomes and present them to executives - in a practical way.
As Eliyahu Goldratt famously said, “Tell me how you measure me, and I will tell you how I will behave”. Focusing on low-level metrics can do more harm than good. A metric’s value becomes the end goal, rather than achieving the desired business outcomes. To fix this, let’s reverse the process. We are going to start by defining the business outcomes we want to achieve. The outcomes we are going to focus on are the ability to run a cost-effective system and ability to evolve it quickly and easily. Foundational to those objectives is the capacity to manage the complexity of the system. In this talk, we are going to explore several simple and pragmatic approaches to architectural metrics that support the required business outcomes.
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. Alexander von Zitzewitz introduces some key metrics that every architect should know (e.g., average component dependency, propagation cost, structural debt index, and more). You will learn how to use these metrics effectively within a metric-based feedback loop, so that your code never end up as a big ball of mud.
We’re agile, we’re doing DevOps, we work in cross-functional teams, and we use the latest developer pipeline tooling. With all those methodologies and technologies we should be highly effective, right? Probably not. Most of us still struggle with balancing coding speed and quality, working on the stuff that really makes a difference, and feeling constantly stressed by all the things we should learn. Effective software architects don't just create clean, simple, and robust code. They also have a strong understanding of the entire development process and the problem that needs to be solved. They take time to learn, practice, and play. Learn how those software architects build effective coding habits, think about the outcome first, reserve time for deep work, and much more. You’ll walk away from this talk with lots of ideas on how to work smarter, not harder.
"Change is the only constant in life.". You might recognise it. The saying is from Heraclitus, a Greek philosopher. The organisation you work with is changing. You don't understand why, nor your manager can explain it. Our brains like routine, and it feels like we control our lives. But more than we would like, we are faced with change. Organisations constantly evolve, sometimes with intention, and other times grab an opportunity. Often, those changes have side effects: they can affect people practices, teams mission and organisations processes. Is there a way where we can be prepared for such changes? From my experience, yes, we can be prepared for those changes. And we can use one of the oldest human skills: visualisations. To be more specific, we can combine different visualisations to discuss, reason and communicate change. It doesn't matter your role in an organisation; it is possible to use visualisations to discuss other points of view and the different options and trade-offs. This hands-on will take you through evolving an organisation by using different visualisations such as Wardley Maps, Context Maps, and Team Topologies. We will start with a Wardley Map to create the context for everyone and have a series of exercises to evolve the organisation using other visualisations such as Context Map and Team Topologies. By doing it, you will be creating and evolving the sociotechnical architecture of the organisation. At the end of the session, you will have experienced the different visualisations and combined them. More importantly, how to visualise change and tame the brain.
Software companies want to be good at software design but the topic is complex and deadlines are pressing. Michael and George have had success at various companies and can show you how to replicate that success at yours. We will describe activities, formats, culture changes, and outrageous obstacles. We will prepare you for a difficult journey by showing you how to prepare and how to respond. The session is a mixture of small lectures, group exercises, story telling, and group discussions.
Rich Hickey once said programmers know the benefits of everything and the trade offs of nothing…an approach that can lead a project down a path of frustrated developers and unhappy customers. As architects though, we must consider the trade offs of every new library, language, pattern or approach and quickly make decisions often with incomplete information. How should we think about the inevitable technology choices we have to make on a project? How do we balance competing agendas? How do we keep our team happy and excited without chasing every new thing that someone finds on the inner webs? As architects it is our responsibility to effectively guide our teams on the technology journey. In this talk I will outline the importance of trade offs, how we can analyze new technologies and how we can effectively capture the inevitable architectural decisions we will make. I will also explore the value of fitness functions as a way of ensuring the decisions we make are actually reflected in the code base.
In large, established companies, an architect usually has a clearly defined role and clearly defined titles: application architect or system architect, solution architect, and enterprise architect. In smaller companies, the three roles are merged. But in this company, an architect must find a way to overcome the independence of individual development teams. It is their job to make their own architectural decisions to link overall solutions and business decisions to strategy. This should not slow down the delivery of new functionality, which is essential to drive growth (considering that delivery is managed by a different part of the IT organization). What is the role of the architects? How can we measure the architect's impact on the company's growth and strategy?
In large and complex software systems, the allocation of responsibilities to different parts of architecture is a key concern. Over time responsibilities can span across multiple parts inappropriately and the parts themselves can become overburdened with too many responsibilities. In this talk, Michael Feathers will describe a lightweight process for creating Responsibility Indices, models that index into information specific to each responsibility in a system: quality measures, refactoring plans, and strategy-based rules for change. By considering responsibilities more primary than physical location in code, teams are able to bring code and responsibility into alignment and track information needed for effective decision making that enhances cohesion over time.
In the last 20 years, a lot of time and money has gone into software systems that have been implemented in modern programming languages such as Java, C#, PHP etc. The focus in the development projects was often on the quick implementation of features and not on the quality of the software architecture. This practice has led to an increasing amount of technical debt – which is unnecessary complexity that cost extra money in maintenance – accumulating over time. Today these systems have to be called legacy systems, because their maintenance and expansion is expensive, tedious and unstable. This talk discusses how to measure the amount of technical debt aka unnecessary complexity with the modularity maturity index. The modularity maturity index (MMI) of a code base or the different applications in an IT landscape gives management and teams a guideline for deciding which software systems need to be refactored, which ones should be replaced, and which ones don't need to worry about. The goal is to find out which technical debt should be resolved so that the architecture becomes sustainable and maintenance less expensive.
Many people think of software architecture as a craft, but I understand it more as a science. Scientists tend to measure things as a basis for further reasoning. Even when you can’t get precise numbers, mathematical approaches to software architecture depend on measurable quantities, like metrics and indicators. Sometimes such approaches depend on which metrics make sense and which do not in a given situation. How can you make sure that your KPIs are providing the information your organization needs to make decisions about how to invest time and effort? Getting to great metrics requires a well-assembled system and a whole lot of work. But the truth is, you might not be working with a well-assembled system, or perhaps your organization has yet to put in the effort it takes to get all the way to fantastic metrics based on DevOps best practices. DevOps is a cultural shift; it’s easy to misunderstand the concept, and companies don’t always commit to adopting best practices fully. Even when that’s the goal, learning and implementing them is a process that takes time. Reality is not always a best-case scenario, and standard metrics do not always reflect the real problem.
Reusable communication design patterns. Communicating software architecture is a crucial aspect of being a successful software architect, however, this is a skill you don't get taught. Learning by trial and error is not ideal, so how do you create inclusive diagrams and visuals that successfully communicate to your audience? Apply communication design patterns and recognise antipatterns. The purpose of a diagram is to successfully communicate with the audience, which sounds deceptively simple. Communication design patterns can be applied to guide you towards this ultimate goal of successful communication, and towards maximum inclusion for your audience. In this session, learn from a hands-on solution architect - and thought leader in communication design and documentation - how to tailor your visuals to your audience, choose the most appropriate standards (or not) and level of detail, and apply patterns to improve accessibility for all audiences.
Building an architecture of the system is a tedious task, especially in large projects. The success of the system is dependent on the quality of the proposed architecture. Hence it is important to have quantitative measures to evaluate the quality of the proposed architecture. Traditionally metrics like availability, reliability, security, adaptability, and risk management are used to measure the quality of architecture. Most of these attributes are either qualitative or become quantitative only after the implementation of the given architecture. Finding the true value of the architecture without quantitative data is inefficient and makes it hard for organizations to plan effectively. In this session, I would like to talk about some simple methods we can apply to capture baseline quantitative data for certain architectural attributes and make effective decisions about the quality of the proposed architecture.
1/07/2022 - 30/07/2022
1/08/2022 - 31/08/2022
1/09/2022 - 28/09/2022
Attendees shared their GSAS experience. View Testimonials.
Get Software Architecture Metrics Book by Christian Ciceri, Dave Farley, Neal Ford, Andrew Harmel-Law, Michael Keeling, Carola Lilienthal, João Rosa, Alexander von Zitzewitz, Rene Weiß, Eoin Woods.
Get Book
Plaça de Willy Brandt, 11-14, 08019 Barcelona, Spain
The Barcelona International Convention Centre (CCIB) is easily accessible by public transport, just 7 minutes from bus and train stations.
Car/Taxi: 38 min. ride from the Airport
Tram: Fòrum (T4/T6)
Metro: El Maresme|Fòrum (L4)
Phone: +34934815085
Email: gsas@apiumhub.com