Menu
In anticipation of Uwe Friedrichsen's workshop "Architecture Kickstart – From Zero to Productive in (Almost) No Time" and session "Where Do We Go From Here? – Mastering the Changed Needs of Architectural Work", Lukas Zühl (WPS - Workplace Solutions) asked him some relevant questions.
You say designing good applications has become more demanding than ever, but at the same time many technology providers claim that their solutions make it easier than ever. How does that fit together?
I think, first of all we need to subtract the usual marketing exaggerations. Everyone claims their products are revolutionary at least and most definitely will change the world as we know it. However, the reality check almost always tells a much less exciting story. But to be fair: There are advances and some of the solutions offer interesting, novel approaches that did not exist before. Just think about the evolution of the public cloud since its beginnings 18 years ago. It is fascinating which additional options public cloud solutions offer and how it can speed up solution design and implementation.
However, all these evolutions also come at a price. We have many, many more options to consider than in the past. All these options have different tradeoffs. It is not enough to read the marketing brochure. We need to actually understand in detail what all these options deliver and where their limitations are. We have to figure out which combinations of this endless stream of options fit the problem we need to solve and which do not.
To make things even more demanding, besides rare exceptions every system is a distributed system these days which brings intricate and hard to understand failure modes that go way beyond simple crash failures. We need to ponder the effects of distribution, what the tool vendors' solutions can mitigate, what they cannot, how to combine different options, what to do ourselves and so on.
We also need to reason about topics like the multi-tiered cloud, mobile devices, IoT devices, maybe their digital twins, platforms, how to design good APIs, good availability in times of 24x7 (just think about applying a database schema change without any downtime), expected near-realtime information propagation through the whole system landscape, data having become at least as important as applications, how to keep things secure (huge topic these days), sustainability in all its dimensions ecological, economical, social/human and technical sustainability, how to keep the ever-growing complexity of the system landscape in check instead of multiplying it with our newest solution idea, and, and, and.
Then we need to design a solution with all this in our minds – a solution that fits the problem, a solution that fits into the existing system landscape as good as possible, a solution that fits the time and budget constraints, a solution that does not overstrain the people involved, a solution that is at least open for the most likely future change demands imposed by an ever-changing, highly dynamic and uncertain market. And we have not yet talked about the quirks, whims and idiosyncrasies of the people involved, about politics, convictions and all the things that inevitably are part of the game whenever humans are involved.
We need to take all this into account if we design a new system, and a lot more. This is a creative (and often also diplomatic) act where all the solutions of the technology providers cannot help us. Sometimes, we may be lucky and such a solution perfectly fits the task given and actually makes our job easier. But most of the times, it is simply hard work, combined with a lot of knowledge and experience.
BTW: AI also will not solve this challenge – at least not in the near future. It may be suitable to support us at a lower complexity level. However, this is a different game and I think, it will still need skilled and experienced humans for quite a long time to play it successfully.
The only constant is change. Have things really become more challenging or are we now simply facing similar challenges of an evolving technological landscape as the generations before us?
I think the answer to this question is twofold, depending on the perspective used. As I already touched in my previous answer, we have a lot of things to consider today that simply did not exist 20 years ago or at least nobody cared about. Just think about cloud, mobile devices, the whole IoT movement, big data, polyglot persistence, the rise of public APIs, and based on it platforms and market places, machine learning, artificial intelligence, and all their implications. Then think about the effects of the ongoing digital transformation – novel IT-fueled business models that were unthinkable 20 years ago which in turn change the way we need to think about IT. If you ponder all this for a moment, you will realize that things definitely have become more challenging.
On the other hand, many of the core challenges did not change. We still struggle with the foundational concepts of good software design: information hiding, separation of concerns, high cohesion and low coupling. We see it everywhere. Good APIs that implement good information hiding are hard to be found. The whole domain-driven design (DDD) movements struggles to find answers to the challenges we already had more than 50 years ago. Admittedly, it provides a lot of good ideas, approaches and heuristics. However, you find way more bad designs that claim to be "DDD" than good ones in the wild. Additionally, business-IT alignment still sucks in most companies and we struggle to establish good collaboration models that actually help to create the desired impact. And so on. If we look at IT from this angle, we come to the conclusion that our challenges are similar, just the technology has changed.
Overall, I think it boils down to: We face new challenges while not having solved the old ones.
Do we now have better tools or methods to address these challenges than we did 20 years ago?
Our tooling – including methods – definitely improved. However, the challenges grew at least at the same pace, if not faster. Additionally, challenges and the capabilities of the tooling grew differently in different places. E.g., if we look at writing code, the tooling continually improves. The support, a contemporary IDE provides developers is impressive. But if we look at software architecture and design, we see much less tooling improvement while the demands grew massively.
The biggest improvement, we see in the architectural domain is the domain-driven design (DDD) movement. However, most of the widespread DDD knowledge stems from the early 2000s. And if we look a bit closer, we see that does not end there, but that these concepts from the early 2000s are basically a rewrite and renaming of concepts that have their origins in the 1960s and 1970s. Hence, while I really appreciate that DDD saved all these essential concepts from falling into oblivion, at least I do not see any significant innovations in the architectural domain. We still struggle with the same problems, we struggled with half a century ago while our challenges multiplied.
Why do you think there is so little awareness for architecture work everywhere, from developers to management, and how could we improve this situation?
I am not sure if I can confirm this observation. 10 to 15 years ago, I definitely would have agreed. Back then, a lot of agile pied pipers preached the story that software development would not require architectural work. However, this was a combination of misunderstood agility, a counter-movement to exaggerated architecture centricity in the 1990s, a latent conflict between architects and developers in many companies and a blunt desire for popularity and fame of the pied pipers.
To briefly recap the story as I experienced it: Back in the 1990s, we faced excessive architecture centricity. Architects took months and years to create overly complex architectures that claimed to solve everything (but never did). Additionally, many architects acted very arrogantly towards all other stakeholders, especially towards developers. It is more than obvious that developers did not like this kind of treatment. Aggravating, many company career paths considered (and still consider) "architect" being superior to "developer" which does not make things better.
With the rise of agility, the hour of revenge had come: Architectural work was declared irrelevant. Architecture would emerge from the work of developers. Going through a continuous testing, implementation and refactoring cycle would be sufficient to come up with a minimal suitable architecture – without requiring any architects along the way. And the pied pipers fueled the long suppressed revenge desires of the developers. As a consequence, for quite a while architectural work was a topic of little interest.
However, based on my observations the perception changed over time. Sure, there are still a few die-hard camps of dogmatic "agilists" who still believe the slogans of the agile pied pipers. But most people realized that just testing, coding and a bit of refactoring is not enough to implement any non-trivial application that has the required runtime and development time quality properties.
Today, I would say that most people have understood we need explicit architectural work to create the desired solutions that implement the desired runtime and development time quality properties. People have understood that a good architecture does not emerge but needs to be laid out in terms of some guiding principles, structure and constraints that everyone adheres to.
Of course, the perception, *how much* architectural work is needed and when it should be done widely differs. The fact that there is not a simple rule how much architectural work is needed when does not make things easier. Sometimes, quite a lot of architectural work is needed, sometimes quite little work is needed. Sometimes we need to do quite a bit of architectural work upfront. Sometimes, we can get away with just a tiny bit of upfront work.
Thus, I am afraid this part will always remain a non-trivial discussion. The best advice I can offer is to think of architectural work in terms of the value (impact) it creates. What do we actually try to accomplish and what do we need to do when to accomplish the desired results? This protects us from knee-jerk architectural work based on habits and helps us to focus on the value-creating parts. If we do this, at least based on my experience the discussions about how much architectural work we need to do when become a lot easier because people immediately understand the value they get from architectural work.
Do you consider your "Architecture Kickstart" to be a workaround for situations where we lack the time and resources for "real" architecture work, or would you integrate it into all new projects?
The "Architecture Kickstart" attempts to mitigate a dilemma many architects face. In most IT projects, there is a pressure to deliver output early (delivering value would be better but that is a different story). This often leads to blind acting, to starting coding without thinking about design first, just to quickly check off some items from the implementation list.
On the other hand, we need to do some upfront architectural work to make sure we are on the right track regarding the required quality properties of the solution. We need to make sure, we have agreed upon the required guiding principles, constraints and structure that are needed to implement a solution that has the required quality attributes at runtime and development time. Without this upfront agreement, we have a high probability we create software that may be functionally correct but does not satisfy the required runtime and development time quality goals. In other words: Most likely, we create code that does not suit the needs and needs to be heavily reworked later or completely rewritten in the worst case.
Therefore, we need to do a bit of architectural work at least before we start coding – simply to reduce the risk of creating a solution that misses the task. We want to create the minimal common ground needed for our development activities to make sure the different code pieces fit together. We want to make sure we do not create excessive complexity because each part follows its own conventions and we end up with multiple solutions for the same problem. And we want to make sure, our code implements the required quality properties – especially the runtime quality properties that are way too often neglected at development time.
But we do not want to spend too much time on it. We know our knowledge is still incomplete and we will learn and refine our architecture along the way. We want to avoid the "analysis paralysis" trap trying to come up with a "perfect" solution upfront (which never is perfect). Instead, we want to quickly collect as much information as possible and create a first sensible architecture from it – just enough architecture to provide the needed common ground we can start our implementation from without the risk of missing the task.
This is what the "Architecture Kickstart" is about. It is a minimal set of activities I found very useful in my projects. These activities helped me to come up with some sensible initial guiding principles, constraints and structure in a very short period of time. Additionally, the activities support creating a high degree of alignment across the different stakeholder groups – which is at least as important as coming up with a useful initial architecture.
Therefore, I would neither call it a workaround nor a must-have. I think it is a useful tool, an architect can use if it fits the situation. It is "real" architectural work. It simply focuses the work on the minimal essentials to get started quickly. Personally, I think getting started quickly often is useful but there are also situations where other, more elaborate approaches than the "Architecture Kickstart" suit the needs better. Hence, let us simply call it a useful tool for an architect's toolbox.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
