Ask somebody in the building industry to visually communicate the architecture of a building and you'll be presented with site plans, floor plans, elevation views, cross-section views and detail drawings. In contrast, ask a software developer to communicate the software architecture of a software system using diagrams and you'll likely get a confused mess of boxes and lines. I've asked thousands of software developers to do just this over the past decade and continue to do so today. The results from these software architecture sketching workshops still surprise me, anecdotally suggesting that effective visual communication of software architecture is a skill that's sorely lacking in the software development industry.
Of course, as an industry, we do have the Unified Modeling Language (UML), but asking whether this provides an effective way to communicate software architecture is often irrelevant because many teams have already thrown out UML in favour of much simpler "boxes and lines" diagrams. Abandoning UML is one thing but, perhaps in the race for agility, many software development teams have lost the ability to communicate visually. This talk explores the visual communication of software architecture based upon my experience of working with software development teams across the globe. We'll look at what is commonplace today, the importance of creating a shared vocabulary, diagram notation, the value of creating a model plus how to use tooling and static analysis techniques to automate diagram generation.
I find a program much more valuable when I can read it and understand the abstractions that collectively explain a theory of the problem and solution. In contrast, I find programs with minimal abstractions and lots of conditional logic hard to understand because there is little or no theory to be inferred. The object-oriented programming community has long sought correspondence between models of the domain and the classes in a program, but other communities strive for this too. But the theory goes beyond just domain models, as solution models (design patterns, architecture patterns) and "critical thinking models" (eg design by contract and the functional thinking embodied in Z and VDM) are equally important. For several years I've been trying to relate the many models that I build on software projects and I believe it's a combination of models of the domain, the solution, and these critical thinking models. This leads to the question of what value a programming team is contributing, especially when "repeated delivery of stakeholder value" is the primary metric used today. I argue that (1) programs that embody the theories of their developers are more valuable, (2) how well developers can evolve a program is related to their ability to build and evolve theories, and (3) a key distinguishing characteristic of a company's most senior developers are their theory-building traits.
We live in physical spaces that are populated by digital entities. The physical and the cyber worlds are increasingly intertwined with one another: actions in the physical space can be cyber-enabled and vice-versa. How can we model and reason about these spaces? How can design tradeoffs be analyzed? How can reasoning about crucial properties, like space security and safety, be supported both at design time and during operation, when the occurrence of environmental events change its topology? These fundamental questions can hardly be answered with current state-of-the art approaches. The field is still in its infancy and much research is needed to develop sound engineering methods and tools. The talk will discuss the main challenges and will outline an initial attempt to model and analyze cyberphysical spaces.
We are living in the most exciting time in the history of mankind. The last century has seen unprecedented improvements in the quality of the human condition and technology is at the heart of this progress. Now we are experiencing an even bigger leap as we move towards a new level of digitisation and automation. Ranging from self-driving cars to factories without workers to societal infrastructure, every sensor and actuator is becoming connected and new applications that enable new opportunities are appearing daily. The fuel of this emerging Internet of Things reality is software. There are three areas where the companies seeking to survive and thrive in this new world need to be world leading: speed, data and ecosystems. Speed is concerned with converting new customer insights into deployed solutions in hours and days rather than months and years. Effective use of data coming from the field, both in development as in the applications themselves, is critical to ensure that we are building the right products that can successfully act autonomously where humans were involved earlier. Finally, successfully integrating ourselves in our business and technology ecosystems such that speed and data-driven development and execution expand beyond the boundaries of the company is crucial for success. The keynote first introduces the aforementioned development, then discusses the key areas of speed, data and ecosystems and finally presents the implications for organisations that seek to continue to be successful.
Download Jan Bosch's presentation here.