Day 1

Speaking remote

It is perhaps in the very nature of our humanity that we seek to build machines in our own image. The history of computing is filled with attempts to do so, and even today, fueled by a perfect storm of an abundance of data, access to extraordinary amounts of computational power, and advances in neural algorithms, we see such efforts renewed. In this presentation, I’ll look at AI through the lens of software architecture: how it has evolved, what has worked and what has not, and what remains to be done.

Data science has been booming! ChatGPT fills your feeds and there are self-proclaimed ’AI experts’ everywhere. But does data science actually add value for companies?

In this talk we’ll take a look at how we got to this point, share experiences of implementing data science projects at companies and discuss how software engineering will play a key role in its future.

”Big design up front is dumb. Doing no design up front is even dumber.” This quote epitomises what I’ve seen during our journey from ”big design up front” in the 20th century, to ”emergent design” and ”evolutionary architecture” in the 21st. In their desire to become ”agile”, many teams seem to have abandoned architectural thinking, up front design, documentation, diagramming, and modelling. In many cases this is a knee-jerk reaction to the heavy bloated processes of times past, and in others it’s a misinterpretation and misapplication of the agile manifesto.

As a result, many of the software design activities I witness these days are very high-level and superficial in nature. The resulting output, typically an ad hoc sketch on a whiteboard, is usually ambiguous and open to interpretation, leading to a situation where the underlying solution can’t be communicated, assessed, or reviewed. The same is true of long-lived documentation, which is typically a collection of disconnected diagrams that are out of sync, and out of date. Modelling can help resolve many of these problems, but that’s a tough thing to sell to mainstream developer audiences these days – teams are either not aware of modelling, or they associate it with bad experiences using complicated CASE tools from the past. Join me for a discussion about the lost art of software architecture modelling, and my experiences of how it can be reintroduced to the agile generation.

Most of the big size companies are becoming more globally distributed, decentralized and autonomous. The talk will focus on addressing challenges with current way of working with enterprise architecture and what adaptations are highly needed to work effectively with modern organization, and drive them to be more architecture driven.

Public cloud adoption has increased rapidly in recent years due to its convenience, scalability and agility. Despite many benefits, being in a rush to adopt cloud technologies, leads to architectural mistakes that may result in poor performance, security vulnerabilities, and increased costs. Cloud’s ease of use comes with a potential for mistakes that can have consequences. In this presentation, I will discuss common mistakes occurring during a cloud adoption.

I will highlight the mistakes in areas like costs, network, security, monitoring, roles and responsibilities. I will also provide some insights about organizational pitfalls that may occur along the way.

Through this presentation, you will gain a better understanding of the potential problems concerning the public cloud and learn what to consider for designing a cloud architecture. By taking a proactive approach, you can ensure a secure, efficient, and cost-effective cloud environment for your business needs.

Many developers evoke the mischievous spirit and day-to-day burden of technical debt to explain the misfortunes and troubles of their codebase and delivery. While unmanaged technical debt weighs down an architecture and exerts drag on its schedule, it is more often an effect than a cause. In this talk, we will look at what is and is not meant by technical debt — and other metaphors — with a view to properly attributing the root and recurring cause as technical neglect than technical debt. Without seeing technical neglect for what it is, we will continue to misattribute our problems to an effect rather than a cause.