Logo des Repositoriums

Auflistung nach Autor:in "Weitzel, Balthasar"

1 - 4 von 4
  • Konferenzbeitrag
    Agilität braucht Architektur!
    (Software Engineering 2014, 2014) Weitzel, Balthasar; Naab, Matthias; Scheffe, Mathias
  • Konferenzbeitrag
    Apps für den ländlichen Raum - Sicherstellung der Qualität bei stark heterogener Konfiguration
    (Softwaretechnik-Trends Band 40, Heft 2, 2020) Elberzhager, Frank; Weitzel, Balthasar
    Heutige Software-Systeme werden immer komplexer. Der Trend darüber hinaus hin zu Ökosystemen erhöht die Komplexität weiter und macht auch die Qualitätssicherung schwieriger. Oftmals erfordert das neue bzw. erweiterte Strategien für die Qualitätssicherung. Im Rahmen des Projektes Digitale Dörfer entwickeln wir seit vier Jahren unterschiedliche Dienste für den ländlichen Raum. In unterschiedlichen Kommunen sind in der Regel die Anforderungen an die Dienste verschieden, was zu angepassten App-Varianten und App-Features führt. Das Management dieser verschiedenen App-Varianten und Features für die Qualitätssicherung ist ebenso komplex. In diesem Beitrag wollen wir Mechanismen aufzeigen, mit denen wir die geschilderte Komplexität besser beherrschbar machen. Damit möchten wir Impulse setzen für solche, die mit ebensolchen Herausforderungen zu tun haben.
  • Zeitschriftenartikel
    Modularity – Often Desired, but Rarely Achieved
    (Softwaretechnik-Trends Band 35, Heft 2, 2015) Knodel, Jens; Naab, Matthias; Weitzel, Balthasar
    “Everything should be modular” is an exalted goal stated by almost every architect – but is it really possible to achieve this goal? In this experience paper, we share our lessons learned across a number of restructuring projects that went modular. We discuss typical business motivations, restructuring efforts starting with good intentions, and reconstruction reality striking back. In retrospective, we analyze typical pitfalls to be circumvented. Examples illustrate our findings and support a truism too often ignored by architects: everything has its price, and more often than not, the price for modularity is a lot higher than initially estimated.
  • Zeitschriftenartikel
    Towards Transparent Architectural Decisions for Software Deployment
    (Softwaretechnik-Trends: Vol. 32, No. 2, 2012) Weitzel, Balthasar
    The operation of large scale information systems requires investment into hardware infrastructure and causes running cost for keeping it in a productive state. This especially applies in an enterprise environment where also expenses for software licenses costs or penalties for downtime occur. The deployment of software influences these costs both in their amount and their composition. In order to optimize them a transparent view on these costs and the deployment is mandatory. In this paper, we present a conceptual model of deployment. The model is populated by reverse engineering of deployment descriptors but as well uses runtime traces and usage profiles. We envision ­ having both made explicit on an architectural level ­ a comprehensive decision making and optimization of software deployment. deployment view of the systems architecture to other views, such as structural or behavioral ones. When optimizing existing systems, deployment decisions already made have to be handled and balanced with potential migration effort. Historic data regarding operation characteristics and usage profile are available. We envision that having an integrated view on the relevant aspects of deployment facilitates conscious architectural decision making. The planning of migration or change effort is supposed to be more reliable. Our experiences in industry show a limited awareness of the influence of deployment on operation cost. Nevertheless, nearly all industry partners are able to tell a story where such a decision caused high cost (e.g., replacing a third party component to reduce license cost due to usage on multiple servers or enhancing network connections to locations to handle the traffic a new feature introduced). Decisions are typically made implicitly or have been deliberated once (at the time of the first release) and remained unchallenged since then (although the system evolved).