The Evolving Threat Landscape of Web Applications and IT Systems

The threat landscape surrounding web applications and IT systems is becoming increasingly sophisticated. While traditional attacks such as SQL injections, cross-site scripting, and session hijacking remain active in 2025, they have been significantly mitigated through modern web frameworks, web application firewalls (WAF), and adherence to best practices.

However, have you ever heard of attacks that don’t aim to steal or manipulate confidential data? There are also attacks that solely focus on taking IT systems offline for as long as possible and maximizing the damage to those affected.

In this article, we will examine one such malicious attack method, which reached a new dimension in 2013 with the traffic spikes on spamhaus.org. Five years later, GitHub experienced a DDoS attack with an astonishing data rate of 1.35 Tbps. These kinds of attacks are not isolated incidents – any company or organization could be affected tomorrow.

Sources

1. Spamhaus History (accessed on 14.09.2024)
2. GitHub DDoS Incident Report (accessed on 03.09.2024)

„The power of artificial intelligence is so incredible that it will change society in profound ways.“

(Bill Gates, founder of Microsoft)

What Are Our Guidelines for the Use of AI?

It’s the year 2024. The hype surrounding LLMs and ChatGPT started a year ago and is now having an initial impact on software development. AI chatbots can not only generate texts, draw photorealistic images, create music or answer questions — they can now also generate functioning programs in a programming language that even work. And through continuous learning, they are getting better and better at what they do. This is a powerful technology and so far there are hardly any regulations or legal guidelines for the use of these tools. So it’s time to start thinking about guard rails for the creation and use of this extremely powerful technology. Because one thing is clear: AI will be integrated into all kinds of products in the future and will therefore have a major impact on all our lives.

To really show the scale that will be upon us with the dawn of the AI age, I would like to quote here from a TED talk by Mustafa Suleyman:

“With that in mind, I offer the following metaphor today to help us grapple with what this moment [the widespread adoption of AI] really is. I think AI is best understood as something like a new digital species. Please don’t take this too literally, but I predict that we will see them as digital companions, new partners in our life journeys. Whether you believe we are on a 10‑, 20- or 30-year journey, I think this is the most accurate and fundamentally honest way to describe what is actually coming.”

And an important insight from him is: “We can only control what we can understand”. So what do we need to do to understand this?

“Nothing is as constant as change.”
(Heraclitus of Ephesus, 535–475 BC)

„A good software architect is like a werewolf: Afraid of silver bullets.“

(loosely based on Jochen Mader (codepitbull))

Welcome to the final part of the blog series
After we covered the basics of software architecture, agile development in general, and agile architectural approaches in the previous posts, in the final post of the series, we will look at the requirements agile projects bring for architectures.

Architectural Requirements in Agile Projects

Architectural requirements in agile projects are specific requirements or criteria that must be considered when developing the software architecture. They ensure that the resulting systems meet the desired quality characteristics, functionalities, and performance attributes. These requirements serve as guidelines for designing the architecture and influence technical decisions in the development process. In agile projects, architectural requirements should be agile and adaptable to respond to changing needs.

Architectural requirements can cover various aspects:

– Performance includes requirements for the system’s performance, scalability, and responsiveness under certain load conditions.
– Security refers to requirements for data protection, secure data transmission, access control, and the overall security of the system.
– Scalability relates to the system’s ability to adapt to increasing demands, whether in terms of the number of users, data volume, or transaction volume.
– Maintainability involves requirements that define how easily the system can be maintained, updated, and extended without negatively affecting functionality.
– Extensibility refers to how easily and seamlessly the system can be extended with new features or modules without affecting existing code.
– Interoperability concerns the system’s ability to communicate and interact seamlessly with other systems or services.
– Architectural Patterns and Styles can be defined as requirements to ensure that the architecture follows the desired design principles.
– Technological Requirements include specific technologies, frameworks, or platforms used in the project.
– Non-functional Requirements: These can include non-functional requirements such as usability, accessibility, and more.

In agile projects, architectural requirements are often developed in close collaboration with stakeholders and may change throughout the project. They serve as a guide for the continuous adaptation and development of the architecture to ensure that the final product meets the requirements and expectations.

Agile Concepts for Architectural Requirements

Agile concepts for architectural requirements emphasize flexibility, collaboration, and continuous adaptation of requirements. These concepts aim to ensure that architectural requirements are agile and can evolve in a constantly changing environment.

Here are some examples:

– User Stories for Architecture: Similar to functional requirements, architectural requirements can be formulated as user stories. These user stories describe the requirements from the perspective of a user or stakeholder role. They focus on the value the architecture provides to these users.
– Agile Architecture Documentation: Agile concepts prefer lightweight documentation that can be quickly adapted. Diagrams, sketches, whiteboard sketches, and brief descriptions can be used to document architecture principles and decisions.
– Emergent Architecture: Agile architects prefer developing emergent architecture, which evolves gradually from the requirements and functionality. This allows for flexible responses to changing requirements and conditions without extensive upfront planning.
– Risk-oriented Architectural Requirements: Agile architects identify and prioritize risks associated with the architecture. Requirements are set based on these risks, and corresponding strategies are developed to mitigate them.
– Continuous Adaptation: Architectural requirements are continuously reviewed and adjusted to ensure they remain current and relevant. This is done in close collaboration with stakeholders to ensure the architecture meets current needs.
– Just-in-Time Decisions: Agile teams make decisions “just-in-time” as the requirements and understanding of the system grow. This allows them to base decisions on up-to-date information.
– Collaborative Work: Architectural requirements are developed through collaborative work with the development team, product owners, and other stakeholders. This fosters shared understanding and ensures better implementation of the requirements.

These agile concepts for architectural requirements help ensure that the architecture remains flexible, adaptable, and aligned with current needs, while also ensuring high quality and customer satisfaction.

Urgency as a Driver for Agile Architecture Work

Urgency as a driver for agile architecture work refers to the need to focus on specific aspects of the software architecture that must be prioritized due to their critical importance or potential impact on the project.

This approach is based on the idea that not all parts of the architecture are equally important, and it makes sense to focus first on those aspects that have an immediate and significant influence.

Urgency can have various reasons:

Risk Mitigation: If certain architectural aspects present a high risk to the project, they should be addressed early to minimize potential problems.
Critical Functionalities: If the architecture is directly related to critical system functions, it is urgent to prioritize these areas to ensure performance and reliability.
Performance and Scalability: If the system must perform well under expected load, it is essential to make architectural decisions that optimize performance and scalability.
Integration: If the system interacts with other external systems or services, it is urgent to carefully plan and implement the integration architecture.
Changes in Requirements: If the requirements change, it may be necessary to quickly adapt the architecture to ensure that the system meets current needs.

Agile architecture work, taking urgency into account, allows for a quick response to the most pressing concerns. This ensures that the project builds on a solid foundation. However, a balance is required to align urgency with the long-term goals of architecture and technical integrity.

Sources

• https://www.scrum.org/
• http://agilemanifesto.org/
• https://www.isaqb.org/
• https://de.wikipedia.org/wiki/Softwarearchitektur
• https://www.agile-academy.com/
• Mike Cohn: Agile Design: Intentional Yet Emergent.
• Stefan Toth: “Approach Patterns for Software Architecture: Combiniable Practices in Times of Agile and Lean”, 2nd edition, Hanser Verlag 2015