Menu
Freelance Software Architecture
Trainer and Consultant
Software architect, coach and DDD enthusiast @ WPS
Global Practice Head – Automotive Electronics, Tech Mahindra
Architecture documentation is very often treated stepmotherly. Yet documentation supports the design work and creates transparency and guard rails for the implementation and maintenance of the software architecture. On the one hand, it is not simple however to hold the important information from the draft of the software architecture structured and easily understandable. On the other hand, most attempts in search of practicable handling for creation and maintenance end in the WYSIWYG hell of a word processor or the deep maw of a wiki. Building on lightweight tools and text formats, this workshop shows how to create documentation that is as redundancy-free as possible and can be delivered in appealing formats optimized for different target groups. With the help of many practical exercises, the seminar deals with concepts such as Continuous Documentation and Documentation as Code. The goal is modern, effective, and pragmatic documentation of software architecture. We build on proven methods, formats, and tools like AsciiDoc/Markdown, PlantUML, docToolchain, Maven/Gradle, jqAssistant, and many more. In detail, we take care of the automation of the documentation build process, the generation of content from the model, database schema or source code, the structured storage including versioning and historicization, and the use or creation of meaningful and easily maintainable graphics. Agile development teams can thus integrate documentation work into their daily tasks and deliver up-to-date, comprehensive, and well-structured results at any time. In addition, the creation of documentation can be integrated into the review process and thus constantly improved and further developed.
In Domain Driven Design it is important to focus on commonalities. The ubiquitous language was also developed for this purpose.The exclusive focus on commonalities, however, often leads to the separation and categorization of stakeholders – a good ground for stereotyping processes and conflicts. Focusing on differences and similarities at the same time promotes constructive relationships and trust. In Domain Driven Design, it is therefore helpful to work with a diversity understanding of differences and commonalities. This is because looking at the similarities and differences very often makes it easier to deal with differences in the expectations of the IT system. In this workshop, we will use a practical example to illustrate the extent to which an understanding of diversity is a success factor for DDD.
The microservice architecture functionally decomposes an application into a set of services. Each service has its own private database that’s only accessible indirectly through the services API. Consequently, implementing queries and transactions that span multiple services is challenging. In this tutorial, you will learn how to solve these distributed data management challenges. I will share with you how to implement transactions using sagas, which are sequences of local transactions. You will learn how to coordinate sagas using either events or command messages. I will also explore how to implement queries using the API Composition and Command Query Responsibility Segregation (CQRS) patterns.
We have been building software systems for over sixty years, and they continue to grow in size and complexity. Not only do we have legacy mainframe systems, but systems in object-oriented programming languages have grown so rapidly and uncontrollably over the last twenty years that many of them have become large obscure tangles as well. All this legacy code drives up development costs and makes us reluctant to touch these old software systems. Is this inevitable? Or is there also good legacy? And what can we do to get our Legacy in good shape and keep it that way?
We see a lot of confusion regarding architectural work these days. When? How much? Who? Tons of heated debates and nobody asking the essential question: Why? But without asking Why, all the other questions are futile. Thus, we will start this session by asking: *Why* do we need architectural work? Which problem(s) does it address? After finding some surprising answers, we will move on and ask ourselves: *How* can we do it best? What are the key activities of architectural work? Finally, we will ask ourselves: *When* should we do *what* and *how much*, depending on the given context? After this session, we will have created a lot clearer picture what architectural work actually is about – without the usual fuzz, stripped down to its pure essence.
Naming is hard. Teams who write software often give rather technological names to the components they write. This is a problem because it makes the system less understandable and more difficult to extend. I propose to show more respect to the language that the users and other domain experts speak because it will allow us to think as they think which will make our software more compatible with the users’ mental models. Let’s call the modules, components, interfaces, services and entities as business-friendly and technology-neutral as possible and use some patterns from Domain-Driven Design to achieve an architecture that is well-structured, easy to explain and maintain over the years. It’s a matter of attitude and attention, folks!
What is the internal structure of your cloud-native Java microservice? How do you organize your SPA / PWA frontend? Is there a relation between the frontend and backend design? This session will introduce a consistent, feature-driven, standards-based structure called BCE and apply it to microservices and SPAs. I will create and review a lot of code and present the ideas on a few slides. Your questions are highly appreciated.
Cloud storage footprint is in exabytes and exponentially growing and companies pay billions of dollars to store and retrieve data. In this talk, we will cover some of the space and time optimizations, which have historically been applied to on-premise file storage, and how they would be applied to objects stored in Cloud. Deduplication and compression are techniques that have been traditionally used to reduce the amount of storage used by applications. Data encryption is table stakes for any remote storage offering and today, we have client-side and server-side encryption support by Cloudproviders. Combining compression, encryption, and deduplication for object stores in Cloud is challenging due to the nature of overwrites and versioning, but the right strategy can save millions for an organization. We will cover some strategies for employing these techniques depending on whether an organization prefers client side or server side encryption, and discuss online and offline deduplication of objects. Companies such as Box, and Netflix, employ a subset of these techniques to reduce their cloud footprint and provide agility in their cloud operations.
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. I will introduces some key metrics that every architect should know (e.g., average component dependency, propagation cost, structural debt index, and more). Then I will talk 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. Therefore, it can be used to monitor code maintainability and as an early warning indicator if things move in the wrong direction.
To seasoned software architects, it sometimes seems as if our discipline is more alike to the fashion industry than we’d like, and the hype cycle might be the best-known (pseudo-)mathematical graph in our community. Is everything new really only old stuff in new disguise, or is that just old folks yelling at the cloud? How do we distinguish genuine innovation from lipstick on a pig? And will we be able to get through this keynote without even more cliché-ridden puns? Find out and join me for a look at some examples and an attempt to draw useful conclusions.
Compared to some of the IT industry’s more imaginative job descriptions, “software architect” appears to be a clear-cut role with a generally accepted set of duties and responsibilities. Upon closer inspection, however, this seems to be one of those things that everyone agrees on until one starts looking for a common consensus on the delineation of the role, tasks, and responsibilities of software architects.
For one thing, the day-to-day work of software architects is often characterized by having to fill other roles as well, such as project manager, requirements engineer, or lead programmer. On the other hand, there are organizations that actually strive for a clear differentiation between persons responsible for different architectural levels or domains. Lack of clarity about the role and responsibilities of software architects not only leads to risks in projects and reduced job satisfaction, it also implies different expectations about the training and skill set required for architects. This presentation will explore and analyze the various perceptions of the role of software architects, based on current literature as well as feedback from practitioners and training participants. Its objective is to make an informed contribution to the ongoing debate on relevant issues, such as: What is the actual core set of tasks and responsibilities? What are typical deviations from this and what are the reasons behind them? Which consequences does this have for the work of architects, their integration into the organizational context and their training?
In various communities, several methods for the collaborative modeling of business requirements have been established in recent years. Well-known examples are EventStorming or Domain Storytelling. These approaches are based on achieving a better shared understanding of the business requirements in an interdisciplinary way. But what about the requirements for the quality of the software being developed?
This is where Quality Storming comes in, trying to bring together a heterogeneous set of stakeholders of a product or project to collect quality requirements. The goal is to gain a shared understanding of the real needs for the quality characteristics of a product. To achieve this goal, Quality Storming uses some techniques from various already existing collaborative modelling approaches.
It is not the claim to produce perfectly formulated quality scenarios with the help of Quality Storming. Instead, the method aims to create a well-founded, prioritized basis for later formalization, which is understood across different stakeholder groups. The more often teams work with the technique, the better the quality of this basis becomes over time. Advanced teams are quite capable of creating very well-formulated scenarios within the framework of such a workshop.
In this talks I will introduce the workshop and the ideas behind it. You will also learn many hints for facilitating such workshops and how to proceed with the learnings generated in Quality Storming workshops.
In this presentation, I will talk about my experiences, successes and failures with the arc42 architecture template in a DevOps team in a corporate environment with a product development focus.
Product development is often characterized by short iteration cycles and is therefore often operated in an agile manner, as in the speaker’s team. There the existing unstructured documentation was transferred to the arc42 template and stored in a wiki. In the course of time, it turned out that tooling plays a decisive role for the quality of the documentation and therefore switched to Docs-as-Code.
In the course of the presentation, the most important decision points for the current iteration of the technical software architecture will be discussed. These include the handling of “developer prose”, outdated documentation and the architecture decisions that are particularly important for a DevOps team. The integration into the methodical procedure Kanban was made possible with arc42 and a microsite based on AsciiDoc.
Not left out are the mistakes made, such as missing quality assurance of created documentation or the mixing of business and technical topics.
Many software-developing organisations adopt DDD and apply strategic design to map out bounded contexts based on domain understanding to build services and applications within those contexts.
Teams have come to appreciate hexagonal architecture as a great approach to isolating the domain within a microservice or an application.
But that cannot be the end of the story – successful applications grow, people learn and the world changes. Bounded contexts will require adjustment, be split or abandoned – and that requires modularity within their domain cores.
I want to show an example of how hexagonal architecture and domain-driven modules go together and how such an architecture can be visualized and organized.
Most modern software teams strive for Continuous Delivery of business impact with a DevOps mindset: you build it, you run it. With short iterations and continuous feedback loops, teams deploy new software to production daily.
But how about the role of a software architect in such a fast-paced world? With daily deployments, is there even time for software architecture? As an architect, how do you prevent being a delaying factor to the pace and success of a team? And how do you keep up?
In this session, I’ll share my experiences as a software architect in the DevOps world. I’ll talk about “just enough” architecture and moving from up front design to evolving architecture.
After this session, you’ll have practical insights and tips in how to work as an architect with a DevOps team.
The package structure you choose has a great influence on the architecture and maintainability of your software system. It lays the foundation for whether your application remains manageable in the long term or becomes a big ball of mud. In this talk, we will show what matters.
The package structure is the basic structure of object-oriented software systems. It is not only the way of grouping classes, but also relevant for every developer in the course of their daily work. Package structures help to quickly grasp and understand structures within the application. Is it possible to derive the functionality based upon the package name and to talk about the system on the functional level? A meaningful structuring of the application helps in the daily work, in the implementation of new requirements and in maintenance. This is due the fact, that a higher implementation speed can be achieved. In many projects, the package structure is based on the stereotypes of classes such as controllers, services or factories. This technical structuring is an intuitive procedure in smaller software systems, which leads to considerable disadvantages in larger software systems like an increase of technical depts. Reasons for that are the resulting lack of system understanding which leads to unclear responsibilities, undesired dependencies, cycles and high complexity. Finally, this causes applications to erode unnoticed resulting in a reduction of productivity.
An alternative way of system decomposition helps to avoid the listed negative effects. Focusing on the mental model of the user and the developer, leads to a functional system decomposition. This will be discussed looking at use cases, which everyone can understand, and which illustrate real business transactions.
Leading indicators are the metrics providing us hint on the product quality during development cycle. Question is can we get them more accurate? we try to answer this question with Orthogonal Defect Classification (ODC) which is an important data set, that can provide insights into weak process areas of SW development, design areas requiring attention. The talk will focus on how ODC parameters can help in improving leading metrics of SW quality.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
