I will share a return of experience in designing and coding a zero trust based Web application on Azure (#cloud native, Web App, Serverless, API Management, Security & Compliance) using DevSecOps methodology, baked with infrastructure as code (Terraform).

For the Revolutionizing Application Development with Low Code : « In the next five years, 500 million more apps will be created. That’s more than all the apps built in the last 40 years, according to the IDC. There simply aren’t enough professional code-first developers to go around for the volume of work ahead to modernize businesses. However, the good news is low-code technology is here to empower more people, regardless of coding ability, to create apps. Let’s discover together how companies already transform their way of working with low-code ! »

You have an excellent concept, a brilliant idea that full of innovation and needs to be evaluated if it actually works. Once it does, you need to secure funding, best practice and make sure that all competencies are met, account structures are set up i.e Landing Zone, Organizations, Dev, QA and Prod. Best build is scalability and Automation.

I'm a Senior Android Engineer from PicsArt and I will tell you what kind of architectural problems we met and what kind of solutions we found. Why you need to start architecting from PRD , What kind of architectural problems we have in mobile development, How to correctly split architectural layers, how effective is clean architecture and how to implement it in mobile. What kind of problems we have with clean architecture, How to make scalable architecture, why you need modular and testable code. Also I will talk a little about code/design level , why you need to synchronize your code in different mobile platforms, and why you need to write code as simple as possible. And at the end why I called topic “ Software Architecture: It's Simple”

AWS modern application to provision devices and gateways in Manufacturing sites. The solution is based on Serverless technology with Event Driven architecture and Ansible for a Cost Optimized, Performant and Scalable platform.
This case study is demonstrating a well-architected aws solution and help discovering AWS serverless features for global and automatic Ansible operations.

Containers provide a standard way to package your application’s code, configurations, and dependencies into a single object. Containers share an operating system installed on the server and run as resource-isolated processes, ensuring quick, reliable, and consistent deployments, regardless of environment. The AWS Cloud offers infrastructure resources optimized for running containers, as well as a set of orchestration services that make it easy for you to build and run containerized applications in production.

A success story of how NASA used open source technology to stay flying and still used to impact astronomical science

With the move to cloud, hybrid architectures and advances in technology the importance of Non-Functional Requirements (NFR) have never been more critical to Solution Design.

Non-functional Requirements define system attributes such as security, reliability, performance, maintainability, scalability, usability….the list goes on and on.

By defining the types of NFR’s to be considered and levels needed of the NFR’s during design phase (and throughout) will ultimately help define the solution expectations and boundaries. It will also help identify any risk areas.

I will introduce methodologies and collated ideas for quantifying NFRs that we have used in real large hybrid cross solution, multi cloud solution architectures.

One of the most scary times for any new architect is when you walk onto your very first project as the architect – dealing with all the responsibility and eyes on you. It’s especially nerve-racking if that career change also involves working with an organisation or people you’re unfamiliar with. As a consulting architect, starting new projects is something I do regularly, so in this talk I’ll take you through a few key ideas to help you navigate the start of your first project and get its architecture - and your confidence - off to a good start.

There are various traps that solution architects can fall victim to, even experienced architects. In this talk we’ll look at four such traps: failing to gauge team maturity, not building consensus, putting the solution before the problem and failing to capture decisions. We'll look at why these traps are important to watch out for as well as how to deal with them, backed up with some real-world war stories.

At the beginning of this year we conducted an internal survey about our engineers’ skills development and career goals. One of its conclusions was that many would like to take more architect-type roles and focus on software design. This is how we came up with the Software Architecture Discussion Group. I’ll describe how we use Architectural Katas and Technology research meetings to create a platform where everyone can experiment. Especially architects!

How do we ensure the team starts creating the product with a shared understanding and an effective plan?, and how do we work out what should be in the MVP and start an agile project as quickly as possible?.
Lean Inception is the perfect methodology to start answering this questions.

My talk starts navigating practical examples (based on real projects), and presents three exercises to level up conversations between team members before building the product.

Architecture is a complex profession with a variable set of practices. From engineering excellence to business value creation the practicing architect has to deal with a complex set of problems in an average week. In this presentation Paul Preiss, founder of Iasa, will talk about 10 practices that will aid you immensely in not only dealing with this complexity but help you master it. From advanced stakeholder management techniques to understanding emergent architecture we will take a deep dive into the modern solution architect. Paul will uncover the traits, habits and principles which guide successful architects in their work. Here are a few:

1. Design emerges, but architecture is proven. The modern solution architect understands that designs emerge, but that an architect proves a strategy and path. Running design sessions and extracting information from multi-functional teams is just the beginning.
2. Decision management is the key to success. Understanding how decisions are made, how they are invested in and how to manage them over time can make or break a successful project or product.
3. Value is both subjective and objective. Clarifying value is one of the most critical functions of the architecture role.

After interviewing hundreds of architects over years as well as assessing and advising on the setup of dozens of architecture practices, Paul has distilled a few key principles that will help you and your team avoid countless pitfalls.

Building an agile and reactive architecture is the holy grail for any Enterprise or Solution Architect.
Microservices, were introduced in 2014 by Martin Fowler as a subset of Service Oriented Architectures promising to deliver that.
Cloud Native and the perspective of infrastructure as a commodity is one key enabler to understand the advent of this architectural approach.
What can we learn from historical evolution of integrations problems, and how is Cloud Native impacting Solution Design inside organizations ?
In this session, besides getting the answers to these questions, we’ll explore the timeline of this evolution, and assess the real nature of these impacts with real examples, both on a Solution and Enterprise Architecture perspective.

Every startup needs to be able to scale while keeping the initial invest as low as possible. This is where cloud providers like AWS and Google Cloud come into play. They offer a very generous free tier and are able to support nearly infinite growth of you user base. But you have to plan your architecture correctly from the beginning, otherwise it can quickly become very expensive. This is the story of how we designed a highly available architecture for one of our clients, whose app scaled to millions of downloads and hundreds of thousands of MAOs while using the free tier as long as possible and keeping the maximum cost of the scaled application under 350$ per month.

Empathy is a technical skill. Don’t worry. You read that correctly. While empathy is often cited as a critical “soft skill,” it doesn’t stop there. Empathy is also an incredibly technical topic that is more accessible to analytical engineers and more vital to building software than you might think. In this engaging keynote, Andrea Goulet, a noted expert on communication in the software industry, will debunk several myths around empathy. Empathy is a feeling? Nope? Technicians can’t access empathy? Nope. Empathy is just a high-level, touchy-feely fad? Nope. Andrea will demonstrate how empathy is a crucial skill for developing software and will focus on giving you practical and immediately actionable advice for making empathy a central focus of your daily development practice. You’ll walk away with a solid understanding of what empathy is, what it isn’t, how you can build your empathy skills, and a framework for using empathy while coding. If you’ve ever thought that you’re “good with machines” but have struggled to understand people, this is a talk you won’t want to miss.

The talk I would like to give is how a Developer can become an Architect. It is aimed at Developers who wish to transition into an Architecture role but need information on how an Architect performs their job. I have been an IBM Architect for over 12 years and mentor junior IBM employees in becoming Architects. My talk would cover topics such as the role of the Architect, developing the Architect mindset, the application of architectural thinking, technical leadership, managing technical risk, solution modelling, reference architectures, how to make the right Architecture Decisions for the solution.

The Solutions Architect position requires a really diverse set of skills and experiences. It is a much more generalist than specialist career which makes so difficult to track and hire great professionals for this role. To design your way to the Solutions Architect career is important to have development skills in order to understand the whole product lifecycle, and how to play with APIs and best advise the customer with integrations. It is also crucial to have infrastructure and architecture skills as you should be ready to advise the customers since the project planning, implementation, and expansion, regarding identity management, infrastructure architecture, integrations, automation and troubleshooting at complex environments. As if that were not enough, negotiation skills are crucial in order to handle customer, objections, frustrations and expectations. Lets wrap this up with empathy and a tech savvy profile and we have good reasons to believe we have a promising successful Solutions Architect ready to the best companies of the globe.

Deep dive into the architectural choices DAZN and the influence of high performance requirements on them.

In software development, we like to recognize good choices and identify them as patterns. This leads into implementing these patterns as best practices. But as we have good choices, we have bad choices as well. We identify them as antipatterns in order to avoid them in future projects. If you identify them in time, you can avoid them on your next project. Come and check what warning signs you need to look for!

We all hear title “Software Architect”. It consistently makes the list of the most highly paid technical jobs. But what does it mean to be a software architect? What does a software architect do? And how do you become one? Perhaps someone gave you the title, but you are not sure what’s expected of you. Or perhaps you suspect you might already be doing a job of a software architect, but can’t quite pinpoint how you made the leap or explain it to others.

In this talk, I will define what a software architect does, and what skills you need to go from a senior developer to an architect.

Resilient architecture is crucial for all cloud implementations. In this talk, we explore different design patterns to make a distributed application more resilient.

As part of this journey, for any process, we need to ask what if something goes wrong? Then, plan a course of action to the process auto-heal without any human intervention and how to lower risks by performing canary deployments. Design starts with at first understanding of requirements and performing empathy map and value chain analysis.

Thinking application as stateless for all the API calls makes the system available most of the time requires creating a cache for common distributed data. Next, we examine how to deal with cascading failures, and timeouts scenarios. Applications, as part of auto-healing, need to Detect, Prevent, Recover, Mitigate, Complement so that the service is resilient.

Key takeaways for the audience are as follows:

Resiliency is essential for any feature in cloud
Understanding the value chain is critical to identify failure points
Challenges come in determining if there is a failure and design the system for auto healing
The focus should be first to prevent a failure to occur.
Identifying key challenges in your company and tools and techniques to auto-heal and provide a sustainable solution

Our systems seldom fail all at once. Instead, an accumulation of failures adds up into a disaster, or a collection of latencies becomes an outage. What can we do to build systems that are more robust than our outage budgets? When do we need to decide to deliver less instead of nothing? And how can we possibly test our solutions under realistic conditions?

Perfectly optimized systems are extremely brittle -- we can see that now in a lot of our physical world. Systems operating near the limits of their capacity can be slow or intermittent. But systems with too much excess capacity are expensive. Finding the right balance of capacity needs and wiggle room means that organizations need to understand what they require and be able to change those requirements on the fly. How much and how fast can your system change to avoid breaking, or to take advantage of new opportunities?

Audiences will leave with new questions to ask about testing in production, automatic traffic management, application delivery, and modular designs.

At the beginning of this year we conducted an internal survey about our engineers’ skills development and career goals. One of its conclusions was that many would like to take more architect-type roles and focus on software design. This is how we came up with the Software Architecture Discussion Group. I’ll describe how we use Architectural Katas and Technology research meetings to create a platform where everyone can experiment. Especially architects!

How do we ensure the team starts creating the product with a shared understanding and an effective plan?, and how do we work out what should be in the MVP and start an agile project as quickly as possible?.
Lean Inception is the perfect methodology to start answering this questions.

My talk starts navigating practical examples (based on real projects), and presents three exercises to level up conversations between team members before building the product.

Most modern businesses depend on a portfolio of technology solutions to successfully operate every day. How do you know whether your team is following best practices or what the risks are in your architectures? In this session, we show how the AWS Well-Architected Framework provides prescriptive advice on best practices

The talk introduces a service implementation that provides services to support access control functionalities. In the cloud environment, access control is usually supported by Identity and Access Management (IAM) services provided by the cloud providers. These solutions are well established and well-integrated into the cloud. Still, they are rarely granular enough to support all the access control functionalities of business applications. A conventional business application implements the granular access control requirements into the business-specific code. The service introduced in the presentation shows that access control can be separated from the application logic. It can be implemented to provide a unified approach to access control for all enterprise applications, may they run in the house, in the cloud, even with multiple cloud providers. Utilizing such a structure may eventually enable the development of business agnostic services. Using those, in the long run, developers can develop business applications utilizing only client code.

Most APIs today are using the resource style of REST, but GraphQL still is a trending technology and increasingly considered as a way to design and build APIs. We take a structured look at the differences in style, the differences in use cases, and the differences it takes behind the scenes to make a good choice between REST and GraphQL. The goal of this presentation is not to claim that one approach is better than the other, but to clearly analyze how they differ, why that matters, and how that understanding can help you to make a good choice for your API.

Building the best suitable cloud architecture from scratch is hard. But migrating an existing application to the best suitable cloud architecture is even harder. It may take several steps in between. This is the story on how to plan those steps for our own application that we started to develop eight years ago.
TeamSports2 is a SaaS CMS which runs as a single tenant solution on self hosted web servers. This is the story of how to plan a migration of hundreds of instances of a single tenant solution to one multi tenant solution while migrating the self hosted web servers to the cloud at the same time.