System Architecture

On walls, boards and other surfaces, you do not see squares and rectangles connected with each other by lines. Next to them is the information of what these “squares are doing with each other”. That is how architecture is created. In many cases, drawings are covered with other drawings and the idea of ​​architecture is lost. Today many organizations are thinking about processes (and very well) and systems architecture (or one application) is forgotten. Application architecture is for the application development team what the building design for builders is. Systems architecture is like a small estate. Before we design a housing estate, we consider what architecture is.

Architecture determines the division of software into components and defines the functions of these components and their relationships. The description of software architecture plays the role of a construction scheme in the project. Beyond the scope of the software architecture project, it remains to determine the way of implementing components, sometimes referred to as detailed design. The development of software architecture is a creative task, the content of which is defining the components whose interoperability will ensure the implementation of the required system behaviour.“- K.Sacha Software engineering.

The system architecture is important. Booch, Rumbaugh, Jacobson in “UML User Guide” impose a lot of responsibility on architecture. In their opinion:

 “Architecture is the set of significant decisions about:

  • The organisation of a software system
  • The selection of the structural elements and their interfaces by which the system is composed
  • Their behaviour, as specified in the collaborations among those elements
  • The composition of these structural and behavioural elements into progressively larger subsystems
  • The architectural style that guides this organisation: the static and dynamic elements and their interfaces, their collaborations, and their composition

Software architecture is not only concerned with structure and behaviour but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and trade-offs, and aesthetic concerns.

For me, the most important thing is that architecture is a small, possible for understand model, the structure of the system and the way in which its elements interact with others. UML component diagrams and sequence diagrams are technically very good. The first is responsible for the representation of the structure, the second describes the cooperation of components.

Architecture is a high-level description of the system. For this reason, it would be worth employ a single architect or a small team of architects with a fixed manager. When creating architectures, an architect (or team of architects) should have functional requirements for the system, as well as a clearly defined list of qualitative attributes (such as for example, security) expected from the system with assigned priorities.

Architecture after creation, like any artifact project, should be sent to all shareholders of the system, who should be actively involved in its reviewing – verification. It should be analysed in terms of relevant quality measures (such as, for example, performance) and formally assessed for quality attributes before it is too late to make changes.

In an ideal world, the system architecture should be divided into components so that the implementation of a few of them will obtain the minimum level of function. Well-defined interfaces and the scope of responsibility of individual components enable incremental development of the system. It also facilitates tests and retests.

The mentioned responsibility of individual components is such a division of applications that individual components could develop almost autonomously. For example, data-generating components should be separated from components that use data. Components responsible for communication with the environment should be separately defined for the user and separately for other systems.

Finally, it is also worth noting that the very creation of the system architecture is just the beginning. It is good to cultivate it by updating and making informed decisions. The architect who, with new features or changes, identifies the components and interfaces that should be modified.

More from my site

  • When is it worth modeling in UML? For some time, there has been a discussion about the value of modeling. Advocates of agile approach are not very happy to see models. Conservatives preferring the classic approach to the […]
  • Five Tips of Software Modeling My software modeling  is approach to software analysis based on reasonable diagrams. In this post I present my five tips of Software Modeling. Models evolve over time You can […]
  • Three Benefits of Use Cases I recommend each person to use the use cases particular in Agile projects. Below three are basic advantages that I think will convince you to use the use cases in Agile projects 1. […]
  • Implementation of the Methodology – Selection of a Modeling Tool In many companies there is a discussion about formalizing the software development process. Spontaneous creation of diagrams by broadly understood analysts and designers does not build […]
  • Architect in Agile Team In the last post I described what I think about the role of an analyst in agile team. The second role that I would like to mention is the role of the architect. This role is defined in […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top