Jun 14, 2018

Impressions from SEACON 2018 - Part 2


by Harald Störrle


"Domain Driven Design" and "Taylorism"


Henning Schwentner (wps solutions GmbH) presented the concepts behind Domain Driven Design (DDD, see [2,6,8] for general references, and [7] for the slides of the talk). The general idea behind DDD is to structure applications vertically rather than horizontally into domains: Design small, self-contained portions of an application domain rather than attempt to get (only?) the big picture. It doesn’t stop there, though: The domain-structure ought to be established, says Schwentner, not just in the design (aka. models), but likewise in the architecture, code structure, organisation structure, and tooling (e.g. repositories). The “Design” in DDD refers to domain-level models (mostly conceptual, it appears) that constitute the ontology of a (sub-) domain and allow to define the boundaries ("Bounded Context") which are reflected in the interfaces at code level.

At first hearing, DDD reminds me a lot of the Role-Modeling approaches of the late 1990’s [1,3,4] (then absorbed into UML), or the Business Objects from the early 1990’s [5], or, even earlier, of the vision and promise of OO technology in general: closing the “semantic gap” between application and technology. Of course, DDD offers modern(ized) terminology, and there certainly is a lot of technical progress since the early days of OO, but the idea is not as new as it might seem… Still, it is a good idea, and it easily survives being renamed, rephrased, and repackaged (again). Maybe, this time around, we will finally see the convergence of application needs and technology opportunities.

Obviously, vertical structuring organisations is all the rage today. The main benefit is obviously the increased agility of small scale teams, hopefully not loosing the capability to tackle large scale problems, or maybe even upgrading organisational capabilities from solving complicated to solving complex problems, never mind wicked problems. Clearly, introducing proper modules into Java 9 is an important contribution towards this goal. And it makes perfect sense to me to bet on this one, even though “module” is not quite a brand new concept either…better late than never. I remain cautious, though, since vertical structures have downsides, too (ever heard the term “information silo”?). And I can’t see the reasons of having horizontal really going away for good (synergy, reuse, integration).

Having said that, I do like the idea of starting at an (elevated) level of abstraction. In my experience, this is difficult enough at the level of models, let alone code. What I find truly interesting, though, is the breadth and prominence that the social or organisational persepective has gained in IT conferences. A side topic in Schwentner's talk, it took center stage in a talk by Frank Düsterbeck. He spoke about leadership in learning organisations ("Taylor ist tot, es lebe der Mensch – Führung in der lernenden Organisation"; "Taylor is dead, long live the human - leadership in learning organisations"). He pointed out that there, in fact, are two types of problems:
  • Complicated problems can be tackled by applying diligence, systematic procedure and delegation. Such problems can be solved by mechanical steps in the end.
  • Complex problems, on the other hand, are by definition beyond what one person can grasp. Only self-organised teams can hope to conquer them.

Of course, in today's highly dynamic market places the latter abound. With the threat of disruption just around the corner, agility is key for thriving as an organisation. So, the call to take teams seriously, is perfectly plausible to me. Not many organisations have embraced this idea, and many more should. Düsterbeck's plea strikes me as somewhat shallow, though. As he points out himself, a tree has fewer edges than a (connected) graph. If every edge corresponds to a communication link, then the overhead for self-organised teams increases much stronger with increasing numbers than it does for hierarchical organisations (Brooks' Law: adding people to a late project makes it later). He observes that there are two types of communication:
  • Steering communication: This is unavoidable, but it is also the smaller part and is thus not the key factor contributiong to communication overhead.
  • Knowledge dissemination: This can, at least to some degree, be replaced by converting fluid and tacit knowledge into a more static form (aka. "documentation").

I am not sure, how much slack this distinction cuts a team. And what about those problems that are too big for one (small) team? DDD will answer: Create another subdomain and establish interfaces. However, the overall picture must be established, too, and "emergent interfaces" is boud to create friction, duplication and defects of every sort. Düsterbeck also highlights that the usual T-shaped profile in technology (broad coverage with deep, deep rooting in some place) is not enough. It must be complemented by the second dimension of domain-knowledge, again T-shaped. What is more, he wants a third dimension in this picture, the social dimension of individuals and teams (see figure below as taken from https://twitter.com/fduesterbeck). Indeed, the times of Taylorism are over.


   


References

[1]   Epstein, Pete, and Ravi Sandhu. "Towards a UML based approach to role engineering." Proc 4th ACM Ws. Role-based Access Control. ACM, 1999.
[2]   Evans, Eric: “Domain-driven design: tackling complexity in the heart of software” Addison-Wesley, 2004.
[3]   Halpin, Terry "Object-role modeling (ORM/NIAM)" Handbook on architectures of Information Systems. Springer, Berlin, Heidelberg, 1998. 81-103.
[4]   Halpin, Terry, and Anthony Bloesch "Data modeling in UML and ORM: a comparison" Journal of Database Management (JDM) 10.4 (1999): 4-13.
[5]   Sims, Oliver “Business objects: Delivering cooperative objects for client-server McGraw-Hill, Inc., 1994.
[6]   Schwentner, Henning: Domain Storytelling Website http://domainstorytelling.org/
[7]   Schwentner, Henning: Models, Modules, and Microservices” Speakerdeck.com/hschwentner
[8]   Vernon, Vaughn: “Domain-driven design distilled” Addison-Wesley, 2016.

Jun 12, 2018

Impressions from SEACON 2018 - Part 1


by Silke Tautorat


An extraordinary keynote

The first day’s keynote “Umgang mit Komplexität lernen” (learn how to deal with complexity) was held by two 13-year old pupils of the Evangelische Schule Berlin and has been a very interesting start for a Software Engineering & Architecture Conference.
Romy Randel and Rosalie Hermann presented in a very professional way the everyday life at their school, in which each student can decide on their own at what pace they want to learn and work on projects.
Of course, the students have a fixed time-table, but in certain units called "Lernbüro" (learning office) they can choose if they want to do Maths, German or English and on what topic they want to work on.
Every few months the students together with their tutor, usually a teacher, agree on goals for the upcoming month and check on the achievement of the past time.
One day of the week is reserved for a project that the whole class, which comprehends of students from 7th to 9th grade, is working on, for example improve the neighbourhood or work in an old people’s home.
Another difference to other schools is the yearly “Projekt Herausforderung” (project challenge). All students must plan and organize a three-week project with a budget of 150€. This can be done all alone or in a group of students and can be everything from a stay on a farm to work with animals, a canoeing trip to a journey to Italy.
Both girls seemed to be very happy with this type of school and, according to the way they presented the keynote and answered questions, this model encourages self-confidence and self-organisation.

Eleven Lessons Learned from a large agile project bei EOS

Maik Wurdel summarized the twelve lesssons learned (he spontaneously added the twelfth one) he and his team made in a large agile project. They have been developing a major core system, which is supposed to replace the existing system shortly. They set up the first agile teams within their company EOS. Here is the list in my own words:

  1. Try to establish start-up conditions: not a lot of processes, cross-functional teams, all in one place. And make sure to have an effective communication on what you are doing in this new agile team to the rest of the company, otherwise a lot of misunderstanding and irritation might happen.
  2. Never start without a customer. The correct understanding on what the customer really needs and wants is very important.
  3. Get an agile coach to support the teams and the transition. The coach should not be just another Scrum Master.
  4. Go live early, to learn as soon as possible.
  5. Conway is right: Organizations are constrained to produce designs which are copies of the communication structures of these organizations. Establish Feature Teams.
  6. Autonomous decisions need clear objectives, aim for high transparency.
  7. Define and measure your KPIs.
  8. Developers in agile teams do not develop faster, they learn faster.
  9. If you are using cutting-edge technology, check regularly if it is still the right choice or if you need to adjust. Start small.
  10. Agility is nothing you just do, agility is a state of mind and has its reasons. You don't do agile, you are agile - with good cause...
  11. Agility has its price: transparency and sprinting is strenuous.
  12. Agile transformation starts with the first team member. Everyone is different and has diverging experiences.

Jun 8, 2018

building IoT 2018 - shaping the Internet of Things


I visited the building IoT at Cologne, Germany in June 2018. The following is a list of the talks I attended and found interesting. The building IoT is a small conference (180 attendees, 39 talks, 2 days + 1 day of workshops) from heise Developer and the dpunkt publisher. Its target audience are developers and architects who develop hard- and software for the Internet of Things (IoT). Most of the talks were given in German. You can find some of the talks' videos on the building IoT homepage.

Keynote: Threat Modeling and Risk Assessments Against Connected Cars

Alissa Knight from Brier & Thorn gave an interesting talk about how threat modeling and risk assessment works. She presented multiple threat modeling frameworks and gave some anecdotes what she found in several years working as a penetration tester in the connected car industry. The talk was held in English.

Reaktives IoT with MQTT, Vert.x and Kubernetes

(original German title: Reaktives IoT mit MQTT, Vert.x und Kubernetes)
Jochen Mader from codecentric talked about the fallacies of distributed computing (you know that your network has latency, right?) and the reactive manifesto. He also talked, with funny self-painted slides, about the concept of back pressure and what can go wrong if you chose a framework without it. Jochen is a contributor to the Eclipse vert.x framework, which is a reactive, message driven framework for the JVM. It supports Java, but also every other JVM language, e.g. Scala, Kotlin or Groovy. In a live coding session, he created two small vert.x applications: a MQTT broker and a MQTT client. He then deployed those applications to a Kubernetes instance and demonstrated how vert.x, by magic, handles pod scaling.

MQTT 5: New Features

(original German title: MQTT 5: Alle Änderungen und neuen Features)
Dominik Obermaier, CEO of dc-square, the company behind the MQTT broker HiveMQ, talked about the new features in MQTT 5. It now supports headers, negative acknowledgments, bidirectional disconnect messages and much more. He also explained why MQTT 5, which follows after MQTT 3.1.1, has not been named MQTT 4. At the end of the talk he announced MQTTBee, a fully reactive MQTT client for the JVM which supports back pressure.

MQTT in the Enterprise - How we successfully run an MQTT Messaging Broker

Despite the English title, Arnold Brechtoldt from Inovex gave the talk in German. He is running a MQTT broker (HiveMQ) with ca. 1.700 messages per second and 40.000 open sessions for a German car maker. The lessons learned are that you absolutely need dashboards which show metrics of the broker (they used Grafana in combination with Prometheus) and also a powerful log analytics (for that they used the ELK stack). The biggest problem when dealing with connected cars isn’t the technology in the car or in the cloud, but the GSM / LTE network. Having dashboards which show the incoming and outgoing messages from the broker allow the on-call team diagnose such issues quickly.

IOTA – the Next Generation Blockchain?

(original German title: IOTA - die Next Generation Blockchain?)
That was my talk – the headline and the talk is in German, despite the English buzzwords. No need to die for blockchains :) I talked about the IOTA “blockchain”, which isn’t really a chain, but based on a DAG. I showed what problems blockchains solve (spoiler: few) and what problems they bring (spoiler: many). I talked about the basic building blocks for a blockchain, then proceeded to explain how the IOTA system works, what problem it solves and then some attacks on it. I spoke briefly about quantum computers and that they wreck traditional asymmetric crypto and what IOTA did to mitigate these risks. I summarized the pros and cons of the IOTA system and showed which future developments are in planning.
If you’re interested, you can find the slides here.

Want a bit more? Privacy by Design and Geolocation

(original German title: Darf es ein bisschen mehr sein? Privacy by Design und Geolokalisierung)
Torsten Jaeschke and Dominik Bial from Opitz Consulting talked about what happens if you don’t plan for privacy when designing a system and then GDPR happens. They had to refactor the whole data architecture to support anonymizing user data. Also, if you just delete user data, the analytics department is going to get angry because their statistics will be skewed. The punchline is: Talk to your customer at the start of the project about privacy, deletion concepts and also think about data warehouses, which store anonymized user data in aggregated format for analytics.

Security in the High Bay Warehouse

(original German title: Security im Hochregallager)
Stefan Strobel, CEO of cirosec, and his colleague Max Bauert demonstrated how broken the industry controllers S7-300 and S7-1200 from Siemens are. They built a small warehouse using fischertechnik (something like Lego, but with more motors, gears, sensors etc.) and then proceeded to hack the system using Metasploit and ICSsplot (Industrial Exploitation Framework). If you have a S7 running somewhere, please don‘t connect it on the internet. The protocol is seriously broken and inherent unsafe.

The Worst IoT Products - what we can learn to develop better Smart Products and Services

(original German title: Die schlechtesten IoT-Produkte - was wir lernen können, um bessere smarte Produkte und Services zu bauen)
Mirko Ross, CEO from digital worx, showed the top 10 of bad IoT products. From the Mirai botnet over hackable and breakable smart locks to connected pacemakers, from connected toys for children which spy on them to hacked Smart TVs. You won‘t believe which stupid mistakes have been made in those products. Sad thing is, you can still buy some of them.

An IoT Project on its Way out into the World

(original German title: Ein IoT-Projekt auf dem Weg vom Schreibtisch in die weite Welt)
Thomas Eichstädt-Engelen worked as a contractor for a start-up which aims to clean the polluted air in cities with the aid of smart trees. A smart tree is a connected device, which uses plants to filter the air. The plants are watered by an automatic system and the air is circulated through the plants with big ventilators. He talked about how they manufactured these smart trees, selected the hardware components and wrote the software. Turns out, hardware engineering is a lot different from software engineering. You have to think about rusting contacts, short circuits, strong electric currents, thin wires, customer grade LTE modems which just break and so much more. On the software side, when entering industry grade hardware, it gets proprietary very fast. Funny and enlightening talk.

Keynote: End of a Hype: The Internet of Things becomes Mainstream

(original German title: Keynote: Das Ende des Hypes: Das Internet der Dinge wird Mainstream)
Stefan Ferber, CEO of Bosch Software Innovations, talked about what it takes to transform a big mechanical engineering company to a company acting in the Internet of Things and having to deal with software. Now Bosch is a major contributor to various IoT frameworks, has a chair in the Eclipse Foundation and hosts one of the biggest IoT conferences and hackathons in Europe. Very impressive transformation.

Hardware-based Security for IoT Products: simply (and) secure

(original German title: Hardware-basierte Sicherheit für IoT-Geräte: einfach (und) sicher)
Christian Lesjak from Infineon spoke about Hardware Security Modules (HSM), how they are built, and what they can do for an application. His showcase was an integration in an IoT product to store the device certificates in a hardware module. He then showed how to integrate this Infineon HSM into OpenSSL to authenticate the client to the server in a TLS handshake.

Agile Software Development for Connected Cars

(original German title: Agile Softwareentwicklung für Connected Cars)
Dino Frese from thoughtworks talked about how difficult it is to develop frontend applications for connected cars. Latency is a big problem when the car is in China and the server is located in a data center in Germany. Cars also have different release cycles compared to a software, and hardware prototypes are only made available late in development. When the software is developed at the same time as the car hardware, they had to mock the complete car software. Also the middleware (backend in the data center of the car manufacture) has been developed from another department in the organization and the collaboration was suboptimal, to say the least. His punchline was: Mock everything, use consumer driven contracts to ensure the APIs are stable and, appealing to the car makers, please publish your car management APIs with a nice documentation.

UX-Testing and Prototyping for Voice User Interfaces and Chatbots

(original German title: UX-Testing und Prototyping für Voice User Interfaces und Chatbots)
Richard Bretschneider from eresult spoke about prototyping when developing a voice user interface (VUI). He showed three ways how to create such a prototype: The first one are linear stories simulating a fixed path through the voice dialog. You must use a text-to-speech-engine to read the responses and to get a feeling on how they work. The second way needs two rooms: The test subject sits in one room, the the operator in the other one. The operator simulates the voice system and uses a text-to-speech-engine to respond to the user. The third way is to use a real voice system, like Google's dialogflow. This system allows, without programming, to create a prototype which can then be tested with Google Home. After these three ways he explained what makes a voice UX test different from other UX tests: The testers can’t give spoken hints to the test subject when they are stuck, as this interferes with the voice system. The test subject also can’t think aloud, which is a common thing to do in UX tests. The testers also need to phrase the exercise in the right way to not give too many hints on how to solve it. This was a very good talk and I definitely will take that into my team.