Blog

iSAQB Software Architecture Gathering

Author: Franziska Deutsch

Software Architecture is about the important things, where “important” means high-risk and hard-to-change decisions. DevOps tries to develop a culture where constant experimentation and learning takes place while the environment changes rapidly. How can this fit together?
We have been building software systems for over sixty years, and they continue to grow in size and complexity. Many of them have become large obscure tangles of legacy code that drives up development costs. Is this inevitable? What can we do to get our Legacy in good shape and keep it that way?
We see a lot of confusion regarding architectural work these days. When? How much? Who? Tons of heated debates and nobody asking the essential question: Why? But without asking Why, all the other questions are futile. Thus, we will start this session by asking: *Why* do we need architectural work? And which problem(s) does it address?
"For a DevOps team, one of the main goals is to provide continuous delivery of value for end users. As a result, you’re working as a team in small increments and try to deliver new features to production as soon and often as possible, and get as much feedback as you can along the way. When a team is moving at such a fast pace, continuously adding new features and refining existing ones, it can be difficult for a software architect to keep up."
In his upcoming session "Domain-Driven Design & Legacy: Evolution not Revolution" Eberhard Wolff, will look at how to improve your legacy systems using Domain-Driven Design. We sat down with him to ask him a little about the topic.
"I see tons of recommendations *how* to do architectural work better. But at least from what I have seen, none of them asks the *why* question. Architecture and architectural work are declared 'important' without any further justification or explanation, just for being what they are. For me, it feels like architectural work has become an end in itself in most places."
"Teaching a subject like software architecture only goes so far, then apprenticeship or something similar should kick in. Software architectures are too different, and we don't the formal rigor of other engineering disciplines to allow objective analysis to the degree of more established engineering disciplines. Software architecture still relies on experience to make good trade-off analysis decisions, which is hard to teach."
In this blog post, Dr Annegret Junker explains how integration architectures are the key to modern applications in hybrid cloud environments or even in mixed hybrid cloud and classic environments.
"I've been working in the software architecture field for a couple of decades now, and one of the consistent issues I've seen through that whole period of time is a lack of agreement on how architectures should be visualized. This is interesting to me, since — as a creative field — one would think that architecture's natural expression would be through visual models. The good news is there is lots of published thinking in this area, and the idea of having consistent visualizations as part of our discipline is now getting some attention."