Alexandervon Zitzewitz
Alexander von Zitzewitz is founder, managing director of the company and CEO of the US subsidiary. He has more than 20 years of project and management experience. In 1993 he founded ootec - a company focused on project services around object oriented software technology. This company was sold to the French Valtech group in March 2000 and served customers like Siemens, BMW, Thyssen-Krupp-Stahl and other well known names in German industry. From 2003 to early 2005 he was working as Director of Central Europe for the French company Xcalia S.A. Since the summer of 2008 he is living in Massachusetts. His areas of expertise are object oriented system design and large scale system architecture. Alexander has a degree in Computer Science from the Technical University of Munich.
One of my favored punch lines is “you get the big ball of mud for free”. It is funny because most of us have to deal with big balls of mud on a daily base and are not too happy about it. Working on a big ball of mud literally makes everything harder and more complicated. - Modularization? Wouldn’t that be nice... - Reuse? Not happening, too much coupling... - Regression bugs? Plenty of them... - Simplify or modernize code? Too risky... Those are just a few of the many issues with big balls of mud. I think it is fair to say that most of us would prefer to work on a clean and well architected piece of software. So why is that so hard to achieve? Why do more than 80% of non-trivial projects end up as big balls of mud? And what can we do to guarantee that this never happens again to us? Aren’t micro-services supposed to solve this problem?
A good software architecture is the foundation for any successful software system. Your architectural choices affect almost every aspect of the software you are building from maintainability to stability, scalability and cyber vulnerability. Matching software architecture patterns and styles with requirements is a difficult task that requires knowledge and experience as well as the willingness to pick the right trade-offs. Way too often the originally intended architecture erodes during the development process making the software harder to understand, to maintain and to adapt to changing requirements. By losing architectural coherence you also lose all the other benefits coming from a good architectural foundation. This drives up cost, reduces the happiness of your development team and ultimately will also impact the users of your software negatively.
Zero fluff.