AGILA – Agile Software Architecture | Part 2/3

AGILA – Agile Software Architecture | Part 2/3

AGILA - Agile software architecture

Part 2

Welcome to the next part of the blog series

After covering the basics of software architecture and agile development in general in the previous post, in this post, we will explore how both can be integrated.

Agile Architectural Approach

This approach integrates agile principles and methods into the process of designing and developing software architectures. It aims to overcome traditional rigid and upfront planning approaches to architecture definition and instead promotes a flexible, adaptable, and incremental approach.
Within the agile architectural approach, architects and developers are encouraged to collaborate, continuously learn, and adapt to changing requirements.

Some characteristics of the agile architectural approach include:

Continuous Adaptation: Instead of designing a complete architecture in advance, agile teams develop an initial architectural direction and adapt it over time as they learn more about the project and its requirements.

Incremental Development: The architecture is developed gradually, evolving with each iteration and adjusting to the changing needs of the project.

Close Collaboration: Architects work closely with the development team to ensure that architectural principles are integrated into the ongoing development process. In many agile approaches, architecture is considered from the start. This way, the architect can be assigned to a team and carry out their tasks within the team, ensuring that architectural principles are considered in the development process from day one.

Clear Communication: Instead of extensive documentation, the agile architectural approach favors clear and understandable communication to share architectural decisions within the team.

Fast Feedback: Through frequent deliveries of working software and prototypes, architects receive continuous feedback from stakeholders, users, and possibly customers during the review. During the sprint, individuals can be invited as needed. The Product Owner ensures that they provide feedback.

Evolutionary Architecture: The architecture continually evolves to meet changing requirements. This allows a focus on what is essential and helps avoid unnecessary complexity.

Risk Reduction: By identifying potential architectural problems early and being able to take countermeasures, risks are minimized.

 

Designing Architecture Iteratively and Agile – Risk-Driven Architectural Work

Risk-driven architectural work refers to an approach where the identification, assessment, and management of risks play a central role in the development and design of the software architecture. Rather than focusing solely on technical or functional aspects, this approach emphasizes evaluating and mitigating risks that could impact the success of the project.

The core idea behind risk-driven architectural work is to address critical risks first to ensure early on that the project is built on a solid foundation. This involves:

Risk Identification: Architects analyze and identify potential risks related to requirements, technology, scalability, performance, security, and other relevant factors.

Risk Assessment: Identified risks are assessed to determine which ones pose the greatest threat to the success of the project.

Risk Prioritization: Based on the assessment, risks are prioritized by urgency and impact. Those with higher priority are addressed first.

Development of Risk Mitigation Strategies: For the identified and prioritized risks, strategies are developed to mitigate or prevent them. This can be done through technical solutions, architectural adjustments, or alternative approaches.

Prototyping and Validation: In some cases, it may be necessary to create prototypes or proof-of-concepts to verify the effectiveness of the chosen risk mitigation strategies.

Iterative Adjustment: During the development process, risk assessments are continuously reviewed and updated to ensure new risks are identified and addressed.

By considering and addressing risks from the outset, architects can detect and mitigate potential problems early. This reduces the likelihood of errors and delays. This approach ensures that the software architecture is solid, stable, and meets the project’s requirements.

 

 

Roles of Architects in Agile Projects

In agile projects, different role models for architects can exist depending on the size of the team, the type of project, and the specific requirements.

Here are some common role models for architects in agile projects:

Agile Architect: This role is responsible for designing the software architecture with a focus on flexibility, collaboration, and adaptability. The agile architect works closely with development teams and product owners to ensure that the architecture reflects agile values and principles.

Architect as Part of the Development Team: In smaller agile teams, the architect may be part of the development team and actively participate in coding and implementing features. This allows for close collaboration and continuous alignment of the architecture with the development work.

Technology Advisor: An architect may serve as a technology advisor, helping the team select appropriate technologies, frameworks, and tools. They ensure that the chosen technologies meet the project’s requirements and integrate well into the architecture.

Architecture Coach: This role involves coaching the team on best practices, architectural patterns, and principles. The architecture coach promotes understanding of architecture practices and helps the team make better technical decisions.

Quality and Maintainability Evangelist: Architects can take responsibility for ensuring that the developed software is of high quality, maintainable, and scalable. They set standards for code quality and work with the team to ensure these standards are met.

Architecture Strategist: This role takes a long-term view of the architecture and helps define a vision for the technical development of the product. They consider technological trends, organizational goals, and future requirements to ensure the architecture remains successful in the long run.

It is important to note that role models for architects in agile projects can vary. In any case, collaboration between architects, the development team, product owners, and other relevant stakeholders is crucial. This ensures that the architecture meets the needs of customers, users, and stakeholders, and is implemented in an agile manner.

 

Ways to Involve Stakeholders in Agile Architecture Work

Involving stakeholders in agile architecture work is crucial to ensure that the developed software meets the needs and expectations of all relevant parties. Here are three ways to engage stakeholders in agile architecture work:

Regular Feedback and Reviews: By holding regular meetings or reviews, stakeholders have the opportunity to view the results of the sprint and provide feedback. This can take the form of demos, presentations, or discussions. The team can experiment with how the review should be structured, and stakeholders can communicate their requirements, expectations, and concerns, leading to continuous adaptation and improvement of the architecture.

Involvement in Planning and Prioritization: By inviting stakeholders to participate in planning sessions where upcoming tasks and priorities are discussed, they have the chance to share their perspectives and ensure that the architecture work considers the aspects most important to them. In a Scrum framework, the entire stakeholder group typically does not participate in planning sessions. The Product Owner (PO) represents the voice of the customer and user, and they must prioritize which backlog stories are to be planned together with the development team.

User Stories and Requirements: Collaborate with stakeholders to create or revise user stories and requirements that will inform the development of the architecture. These user stories can serve as a foundation for the architectural work, ensuring that the architecture meets the desired features and characteristics.

The key element in all of these approaches is open communication and close collaboration with stakeholders. This helps avoid misunderstandings, respond early to feedback, and ensure that the architecture meets the needs and expectations of everyone involved.

AGILA – Agile Software Architecture | Part 1/3

AGILA – Agile Software Architecture | Part 1/3

AGILA - Agile software architecture

Part 1

What is it actually?

In February 2001, 17 software developers met. From their perspective, the prevailing methods lacked flexibility and customer proximity. The Agile Manifesto was created and revolutionized the working methods in software development in a similar way that ChatGPT is doing today. The core of agile methods is customer proximity, rapid feedback loops, and continuous changes based on the received feedback. Agile approaches place people at the center of work, not only on the customer side but also within the team.

 

Mythbusting: In relation to documentation, the Agile Manifesto is often misunderstood. Agile work does not forgo documentation, but uses it differently. For example, requirement specifications are omitted and replaced with smaller work packages.

How does it work?

Agile software architecture prioritizes working software over comprehensive documentation and emphasizes close collaboration between architects, developers, and customers. Architects work closely with stakeholders to understand requirements and receive continuous feedback. The architecture is incrementally developed and adjusted to respond to changing requirements and insights.

What’s the purpose of all this?

This approach reflects the values of the Agile Manifesto, focusing on individuals and interactions, working software, collaboration with customers, and the willingness to adapt to change. Agile software architecture promotes the creation of an evolutionary architecture that relies on clear communication, fast feedback, and continuous adjustment. This enables development teams to respond flexibly to challenges and deliver high-quality software solutions that meet customer requirements.

We are excited to offer you an engaging blog series in three parts, exploring the fundamentals and challenges of software architecture in an agile environment.

Part 1: Fundamentals of Software Architecture and Agility

Join us as we explore the basics to understand the essential concepts of software architecture and agile methods.

Part 2: Agile Architectural Approach

In the second part, we dive deeper and show you how to successfully integrate agile principles into your architectural approaches.

Part 3: Architectural Requirements in Agile Projects

Finally, we explore the specific requirements that are placed on architecture in agile projects and how you can meet them.

Be part of it and expand your knowledge on the intersection of software architecture and agility.

Part 1)

Fundamentals of Software Architecture

Software architecture refers to the organized structure and design of software systems, consisting of various components, modules, and interactions. It defines the fundamental decisions and principles that influence the entire software development process, ensuring that systems meet the desired requirements, are scalable, maintainable, and extensible.

Software architecture deals with the following topics and questions:

  • Components and Modules: How is the software divided into components and modules? What are the functions of these units, and how do they interact with each other?
  • Communication and Interfaces: How do the various components communicate with each other? What interfaces define their interaction?
  • Data Flow and Storage: How are data processed, stored, and transmitted within the system?
  • Scalability: How can the software architecture be extended to meet growing demands?
  • Maintainability: How easy is it to find and fix bugs, as well as add new features without impacting the entire system?
  • Security: How are security aspects considered in the system to protect data and functions from unauthorized access?
  • Performance: How is it ensured that the software operates efficiently under the expected load?
  • Technology Selection: Which technologies, programming languages, frameworks, or platforms are used to implement the desired architecture?
  • Patterns and Styles: What proven patterns and architectural styles (e.g., layered architecture, microservices, monolithic, …) are applied to achieve the system’s goals?
  • Documentation: How is the architecture documented to ensure that developers understand the system and can work on it?

The choice of an appropriate software architecture is critical to the success of a software project, as it lays the foundation for the entire development process. A well-thought-out architecture enables efficient development, better collaboration within the team, and facilitates future adjustments and extensions.

Fundamentals of Agility

Agile principles are a set of guidelines and values that are applied to foster a flexible, customer-oriented, and efficient way of working. The “Agile Manifesto” emphasizes the importance of individuals and interactions, working software, customer collaboration, and the willingness to respond to change.

The agile principles are:

  • Individuals and interactions over processes and tools

Collaboration between team members and clear communication are prioritized. Effective collaboration leads to better understanding and ultimately to successful implementation.

 

  • Working software over comprehensive documentation

The priority is to develop working software that meets user needs. Documentation is important, but it should not distract from actual development.

 

  • Customer collaboration over contract negotiation

Close collaboration with the user enables the team to better understand their requirements and needs. User feedback is crucial for continuously improving the software.

 

  • Responding to change over following a plan

Rather than strictly following a rigid plan, agile teams should be ready to respond flexibly to changes and new insights. Change is seen as an opportunity for adaptation and improvement.

Building on the 4 values, the Agile Manifesto derives twelve principles for collaboration between the development team and customers:

  1. The highest priority is to ensure early and continuous delivery. This approach is intended to ensure that development does not proceed without considering the users’ needs.
  2. Changes are welcomed. Continuous feedback can turn this approach into a competitive advantage.
  3. Functional software that can be delivered in short time spans.
  4. Work closely with customers and users to define requirements and receive ongoing feedback.
  5. Build motivated individuals and provide them with the environment and support they need. Trust that they will get the job done.
  6. The most efficient and effective method for conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. Developers, sponsors, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity – the art of maximizing the amount of work not done – is essential.
  11. The best architectures, requirements, and designs emerge in self-organizing teams.
  12. At regular intervals, the team and its members reflect on how they can become more effective and adjust their behavior accordingly.

These agile principles form the foundation for agile development methods like Scrum, Kanban, Extreme Programming, and others, helping teams develop high-quality software with high flexibility and user satisfaction.

In agile software development projects, evolutionary software architecture and emergent design are increasingly being used, as opposed to predefined architecture (often referred to as “Big Design Up Front”). Techniques such as Behavior Driven Development, Test-Driven Development, and especially Refactoring ensure that the technical design and architecture are constantly adjusted to the requirements throughout the software development project.

In the second part of our blog series “Agile Software Architecture,” we will look at how agile principles can be implemented in software architecture design under the topic “Agile Architecture Approach.”

Software Architecture Gathering 2024

Software Architecture Gathering 2024

Software Architecture Gathering 2024

We will be there!

Essential for Software Architects!
Get ready! We are proud to announce that we will once again be a sponsor and active participant at the Software Architecture Gathering (SAG) 2024 in Berlin – from November 11-14!

With nearly 40 captivating expert presentations and a host of exciting workshops, you will gain invaluable insights into the secrets of successful software architecture.

ITech Progress won’t just be present at an information stand (Tuesday, November 12 to Wednesday, November 13, 2024); we will also host a workshop on the first day and deliver two engaging expert presentations on the first and second conference days.

Additionally, our Chief Architect Mahbouba Gharbi has once again taken an active role in shaping the event program as a member of the program committee.

Our team will be on-site, ready to connect with like-minded professionals and share the latest trends, challenges, and innovations in the field of software architecture. Whether you’re looking to discuss groundbreaking solutions, network with industry leaders, or simply stop by to say hello – we can’t wait to meet you!

We’re offering an exclusive 20% discount on your SAG 2024 tickets.

Use the promo code ITECHPROGRESS20 when registering for the event. Don’t miss this opportunity to be part of the future of software architecture and profit from a reduced rate!

Web security module from iSAQB – We are accredited!

Web security module from iSAQB – We are accredited!

Web security module from iSAQB - We are accredited!

“We are proud to have received the accreditation for the web security module. This certification is a testament to the quality of our training programs and our continuous efforts to strengthen the skills of our participants in the field of web security.”

Mahbouba Gharbi, Managing Director of ITech Progress GmbH

 

ITech Progress is pleased to announce official accreditation for the Web Security module from iSAQB® – International Software Architecture Qualification Board. This significant recognition underscores our commitment to excellence in educational standards and our expertise in web security.</p

In today’s digital world, web security is a critical factor for business continuity and data protection. The Internet, as an open system, offers hackers numerous opportunities to attack and steal sensitive information. Companies and organizations must therefore design their web applications and services securely and regularly check for vulnerabilities.
The iSAQB’s Web Security module is aimed at software architects and provides a comprehensive introduction to the basics of web security. Participants will learn about important security measures such as implementing firewalls, using encryption techniques and identifying and fixing vulnerabilities. The right combination of these measures can significantly reduce the risk of attacks and data loss.
The module also covers the implementation of security measures such as authentication and authorization to control access rights to web applications and services. Participants will learn how to effectively integrate these measures into their systems to further enhance security.
In summary, the web security module provides a comprehensive introduction to web security and enables participants to make their web applications and services more secure and regularly check for vulnerabilities.

ITech-Academy-Logo

For more information about our new web security training courses, please register here.

The first dates will be published shortly and will of course also be announced here.</p

OOP 2024 – we are part of it!

OOP 2024 – we are part of it!

OOP digital 2024 - we are part of it!

H. Tiemeyer präsentiert die Kernkompetenzen der ITech Progress GmbH

It is good to rub and polish our minds against those of others.

Michel Eyquem de Montaigne

We can look back on a week full of interesting and enriching discussions at the OOP in Munich!

Holger Tiemeyer steht während seinem Vortrag auf der Bühne. Hinter ihm ist die Präsentation auf einer Leinwand zu sehen.
H. Tiemeyer präsentiert die Kernkompetenzen der ITech Progress GmbH

What is OOP? SOFTWARE MEETS BUSINESS – a leading specialist conference for software architects with an adjoining exhibition area that takes place every January in Munich. Always? This was the first year after the pandemic that the trade fair was held again at the usual time. It’s the ideal place to keep up to date, gather inspiration and make valuable contacts. As well as making new contacts, we were particularly pleased to meet up with old acquaintances – it’s simply a great event for exchanging ideas! A special highlight at the stand was of course the competition for an iSAQB-licensed training course!

Holger Tiemeyer steht während seinem Vortrag auf der Bühne. Hinter ihm ist die Präsentation auf einer Leinwand zu sehen.

We are already looking forward to next year!

How to Identify a Good Certificate?

How to Identify a Good Certificate?

An article by: Mahbouba Gharbi and Dr. Carola Lilienthal

Introduction

A new trend has been apparent in IT for about fifteen years now: Not only may we learn throughout life, but we can acquire certificates for having expanded our knowledge. Two words in this last sentence should make the interested reader sit up and take notice: “acquire” and “knowledge”.

A certificate must be paid for! Therefore, the first question we want to ask ourselves is whether you can buy a certificate without having substantially increased your knowledge. How are certification procedures organized to prevent such malpractice?

Secondly, we turn to the question of what certificates can or do verify: theoretical knowledge – i.e., everything that can be learned from books, or real practical experience that grows and changes over the years. Should certificates perhaps even have an expiration date? Are there certificates that check whether I maintain or expand my knowledge and experience once certified? Which promises are used to advertise certificates and what can you make of these promises?

Certification procedure

There is a wide range of certificates on offer, yet most certificates and certification procedures are based on a similar process with some comparable variants. Figure 1 shows the basic pattern for certification procedures.

If a training provider wants to offer a training course for a certificate, they first have to consider whether they are able to teach the topics contained in the syllabus (step 1 in figure 1). If this is the case, the training provider must be licensed by the board responsible for this certificate (step 2). With the corresponding license agreement, the board ensures that the training provider implements the board’s syllabus and, if necessary, has the quality of its training materials assured by the board. If you are a prospective examinee looking for a training provider for a certificate, you should always check if the training provider actually holds the required license.

Once the examinee has found a training provider that suits them, they register for the respective training course and pay the training course fee (step 3+4). If the examinee wants to take the exam right after the training course, the training provider registers the examinee for the exam with a certification body shortly before or during the training course (step 5). Certification bodies are authorized for the examination by the board responsible for the certificate. The question pool from which the certification body compiles the examination questionnaires is developed by the same independent board that defined the syllabus for the training course.

Most training courses are organized in such a way that the examination can be taken directly after a training course that lasts several days (step 6). For this purpose, the certification body appoints an independent non-specialist examiner to conduct the exam on site. The exam is administered by a non-specialist examiner in order to prevent them from helping the examinees with the exam in any case.

The certification body receives an examination fee from the examinee for this service (step 7). The examiner has the examinee complete a multiple-choice test (step 9) – either digitally or on paper. They received the tests in paper form from the responsible certification body (step 8). Following the examination, the digital tests are evaluated directly by the certification body (step 11) and the result is announced (step 12). If exam sheets in paper form are used, the examiner sends the completed exam sheets back to the certification body (step 10). There, the answers are evaluated, and the number of correct answers is determined (step 11). The examinee is then informed about their result by email. If the examinee has given enough correct answers, they receive their certificate (step 13).

Figure 1: Certification procedure from the perspective of the examinee [DST]

This process, which at first glance seems relatively complicated for the examinee, was created to counteract the danger presented in the introduction that certificates can simply be bought.

A good certificate is characterized by the fact that the definition of the contents, the training course, and the examination are the responsibility of different institutions that are independent of each other (see figure 2).

Figure 2: Division of tasks [DST]

There are different variants to this comprehensive certification procedure for individual sub-processes:

  1. Preparation without training course (see figure 3)
  2. Remote examination (see figure 4)
  3. Public examination
  4. Examination at a test center

If an examinee wants to take the exam for a certificate without preparation by a training provider, the examination fee is somewhat higher for most certificates (step 5 in figure 3). Books are offered for most certificates to facilitate self-study (step 6 in figure 3).

Figure 3: Preparation without training course [DST]

For the exam, the examinee has the three alternatives listed above.

Since the coronavirus pandemic, many training courses are offered remotely, and therefore location-independently, so a remote examination is the logical step. For this reason, a remote exam is now offered with many certificates. The exam is taken remotely by the examinee and is monitored by an examiner who connects to the examinee’s computer and watches the examinee with a camera. Thus, the need to travel is eliminated for all parties involved. Procedures that allow for online exams to be taken without supervision, on the other hand, invite malpractice.

Figure 4: Remote examination [DST]

In addition, some certification procedures offer examinees the possibility of attending a public examination or a test center where they take their exam under personal supervision.

So, to summarize the answer to our first question: In procedures that follow the process presented here with a separation of responsibilities and where the exam is taken under supervision, it is ensured that you cannot buy the certificate.

Knowledge or experience?

But what about the second issue? What do certificates verify? Theoretical knowledge or practical experience? Well, this question actually depends on the type of certificate!

Any certificate that only consists of a multiple-choice test merely requests theoretical knowledge. The boards, of course, try to create exam questions that can be answered with practical experience only, but that is very difficult with the multiple-choice pattern.

Certificates that fall into this category usually carry the label “Foundation Level”. The Foundation Level is explicitly advertised by the providers as a basic certificate [FGG10]. The examinee masters a field’s basic concepts afterwards. These basic terms can be learned, their meaning can be explained to the examinee. After the exam or training course, the examinee speaks the language of this domain.

Certificates that build on the “Foundation Level” usually go beyond a pure multiple-choice test. These certificates often carry the addition “Advanced Level”, and sometimes “Professional” or “Master”. For these advanced certificates you have to demonstrate practical experience in some way.

For some certificates you must provide testimonials from your employers for projects that fit the topic of the certificate: e.g., 18 months of testing tasks in projects, or 18 months of project management or subproject management.

Some other advanced certificates include an oral examination in addition to the multiple-choice test. In some cases, there is no training course in the traditional sense, but an attempt is made to simulate a kind of project situation in which the participants work together in the respective field.

Then there are some certificates that come with the unpleasant feature of having to be renewed regularly every three or five years. Either the exam must be taken again, or the examinees have to collect credit points that prove certain activities in the certified domain: Conference attendance, presentations, lectures, article publications. This ensures that the examinees’ experience does not become obsolete.

As far as the question of knowledge and experience is concerned, we note that the basic certificate, the Foundation Level, resembles a theoretical driving test. The theory, i.e., the conceptualization and the rules, are mastered, but there is no practical experience. In this respect, the basic certificates should always be taken for what they are: Theoretical knowledge that must be acquired in order to complete advanced certificates.

Conclusion

If you are looking for further training with a certificate, plan for a basic certificate and corresponding advanced certificates, depending on your current level of knowledge. Only advanced certificates can really testify your practical experience.

Furthermore, you should insist on a proctored examination and only choose certificates with a clear separation of responsibility for content, training course, and examination.

While researching the right training provider, don’t let yourself be fooled by pretty brochures and appearances. Try to get an idea of whether the training managers you are being offered spend most of their time on projects in the field – which means they only earn money with training courses occasionally. If you have found such a training provider, it is much more likely that you will come out of the training course not only with a certificate, but with actual practical advice.

We hope that equipped with this knowledge, you will be able to assess the quality of certificates offered on the market and to identify the most suitable further training for yourself.

[FGG10] Fahl, W.; Ghadir, P.; Gharbi, M.: Vom Sinn und Unsinn einer Zertifizierung für Softwarearchitekten – CPSA‑F: Ein gemeinsamer Nenner für Softwarearchitekten (EN: On the Sense and Nonsense of a Certification for Software Architects – CPSA‑F: Common Ground for Software Architects); Sonderdruck OBJEKTspektrum 11/2010

[DST] The process models are domain stories: www.domainstorytelling.org