Notes on SATURN 2016

SATURN is a small industry-focused software architecture conference run by the Software Engineering Institute. SATURN 2016 was held on May 2-5, 2016 in San Diego, and there were about 200 attendees, mostly from the US, but with small but significant delegations from countries like UK, Norway, France, Ukraine, and Brazil.

SEI has posted a number of videos of conference talks on YouTube. Here is a link to the directory of videos:

• SATURN 2016 videos.

I think that several of these presentations are worth viewing... certainly the Booch keynote, as well as some of the regular technical sessions. More information on the SATURN 2016 program can be found on the SATURN website: http://www.sei.cmu.edu/saturn/2016.

A big theme at SATURN this year was Internet of Things. IBM and GE had a big presence, and I also talked to some folks from Bloomberg, Google, Boeing, Statoil Norway, and RedHat.

The conference includes a number of the SEI standard architecture tutorials (which I did not attend), plus a standard conference program of invited talks and industry experience reports.

The invited talks were:

• Grady Booch keynote on "Abstracting the Unknown" -- the challenges of creating software architectures for new and novel systems
  • YouTube video of this talk.
  • See my writeup on the talk below...
• Daniel Jackson keynote on "Rethinking Software Design" -- a repeat of his talk for the SPLASH 2015 conference
  • YouTube video of this talk
  • slides from the SPLASH 2015 talk: http://people.csail.mit.edu/dnj/talks/onward15/onward15-talk.pdf
  • The main topic of this talk is "why do some designs cause confusion and fail their users". Jackson has a theory of "design concepts" within the design of a system -- and he makes the case that there should be a one-to-one mapping between design concepts and the "purpose" -- the task that the user is trying to do.
• Joseph Salvo keynote on "Architecture and Evolution of Complex Systems" -- an introduction to the "vision" of the Industrial Internet Consortium http://www.iiconsortium.org
  • Salvo is Director of GE Global Research, and this was mostly an "inspirational talk" -- drawing the parallels between the innovations in the electric power industry of the 1890s and the expansion of Industrial Internet applications today.
  • GE has recognized that software is an important business -- and they are spending a lot of effort on it.
  • One idea from GE -- they are creating a collaborative digital marketplace called "GE Forge" so that industries can work together in a cloud environment, but with protection for intellectual property.

I also attended an interesting collection of the regular conference talks:

• John McGregor on experiences using AADL (an architecture description language) and associated tools -- creating a formal architecture that can be used in combination with code generation tools.
  • McGregor has been working on a Architecture-centric Virtual Integration Process (ACVIP), which combines formal architecture modeling and software testing.
  • You can execute some "end-to-end tests" early -- because the tools can generate simulations of the parts of the system that haven’t been coded yet.
  • YouTube video of this talk
• A session on refactoring and legacy software -- Dave Adsit on Architectural Refactoring, Jennifer Manning on Recycling Parts of Legacy, and Colin Dean on the value of Code Review.
  • It is possible to rearchitect a big monolithic server-based system -- in small steps. Some examples: incorporate a Content Delivery Network to externalize the data, rework the APIs and services to facilitate moving them to a cloud environment, reduce delivery complexity by adding "feature toggles", "shard" the database for better performance.
  • When reusing existing software modules, it is valuable to take a step back -- consider the "quality attributes" that are most important for the success of your product. This will help you make a more rational decision about which existing pieces can be reused effectively.
  • The code review process helps to share knowledge across the team. It is better to call it "code review" rather than "peer review", because it isn’t the code author who is being evaluated.
  • YouTube videos: Adsit | Manning | Dean
• A session on IoT and related frameworks -- a GE talk about their "Industrial IoT" framework (the Predix platform - http://predix.io), a talk by Cory Henson about using data modeling in IoT environments (the Bezirk platform - http://bezirk.com), and an IoT reference model talk from SoftServe (http://www.softserveinc.com/en-us/services/software-architecture)
  • We’re going to see a lot of IoT architecture work in the next few years -- toolkits, reference architectures, and so on.
  • One issue for IoT "platform software" -- it needs to be lean (small memory footprint). The Predix platform is a Java-based framework that claims to be as small as 10MB.
  • The Bezirk talk focused on data models / message formats -- and the reuse of industry standard schema, such as data formats defined in schema.org.
  • YouTube video of this talk
• Frances Paulisch on how Siemens has been managing and training their network of architects
  • Siemens invests in internal training for senior architects, and they set up regular interactions across the architect community.
  • YouTube video of this talk
• Michael Keeling and George Fairbanks presented the debate between centralized versus decentralized governance for microservices architectures
  • YouTube video of this presentation
  • It will be worthwhile watching the video of this session. Michael and George used a good historical analogy -- the US founding fathers Alexander Hamilton and Thomas Jefferson -- to contrast the two views on governance.
• Rick Kazman and Jungwoo Ryoo presented a set of techniques for analyzing security design
  • They call their technique AAFS (Architectural Analysis for Security).
  • Although there are many "security patterns" in the design literature, it can be very difficult to navigate to find the right patterns to use.
  • To make things simpler, they have identified a smaller set of "security tactics" -- and each tactic is linked to a number of related security patterns.
• Stefan Toth presented a fascinating "partial architecture evaluation" of Netflix and their microservices environment, based on their public APIs and open source tools
  • This architecture evaluation is based on a subset of the SEI’s ATAM process.
  • Netflix has a cloud-based system based on microservices -- tens of thousands of Amazon EC2 instances: "it’s a login service that accidentally plays videos".
  • The evaluation is really inside-out, because they couldn’t do interviews with development teams and stakeholders -- but they could infer a lot about the architecture plans, architecture approaches, and architecture decisions from public information.
  • The architecture doesn’t use layers -- there are "slices" or "verticals" of services... each slice owns its data. Netflix also has developed a good set of tools to help developers use the services.
  • The most interesting question: What kinds of problems are good for the Netflix open source plus microservices approach? They had four conclusions: a long-lived product, a product that is big enough to require multiple teams, a corporate culture that will accept the idea of "self-organizing teams", and a cloud execution environment.
• A short talk by Bett Bollhoefer on Zen-related career advice (see her book "The Zen of Software Development" by Beth Correa). She had two messages:
  • If you want to change things, you have to accept them first (write down what bugs you, take a deep breath, and accept it)
  • You should "always do your best" (when you are in a stressful work position, don’t do a bad job just to punish your company)
  • YouTube video of this talk
• Experience report from Statoil Norway on their use of IoT for managing sensors.
  • YouTube video of this talk
• Kids and IoT -- this was a two hour demo session by a group of middle school students (ages 11-15). They showed a set of small IoT-based projects that they built using Lego Mindstorms robots and a small collection of IoT software and hardware.
  • The students have been working under the direction of a parent-volunteer, Kent Meyer. He has set up a number of small projects that they could build in a series of seven 2-hour weekend sessions.
  • Their system used an MQTT (Mosquitto) message broker, Node-RED development tool, Mindstorm EV3, Debian Linux (running on Chromebooks), the Cylon.JS framework for robot applications, some Arduino ESP8266 controllers (with built-in WiFi) and some simple sensors.
  • Note that they are not using the "standard" Lego Mindstorms language -- the parent-volunteer felt that it was too limiting, and that the kids were sophisticated enough that they could learn enough Javascript in small steps.
  • "Failure" is an important part of the process... the students learn about hardware problems, debugging, and working together.
  • Many of the students have been in computer games clubs -- Minecraft on local servers. Some of the projects have used the Lua language to build interfaces between the Minecraft world and the robotics projects.

Finally, I attended a one-day workshop on Container technology:

• This workshop was a small brainstorming meeting -- an opportunity for a small group to come up with good questions about how containers will have an impact on future software architectures.
• The workshop was mostly about Docker, but we did discuss alternative container approaches from years past, as well as the tools and environments to manage collections of Docker containers.
• The main conclusions of the workshop:
  • Docker (http://www.docker.com) will be the dominant container approach for now.
  • Docker containers have a different kind of "isolation" than previous container technologies.
  • Docker supports a much more lightweight model of components than a "virtual machines plus Vagrant" model.
  • One reason Docker is useful for building microservices: the isolation of file system and network connections in Docker containers.
  • The most common type of interface to a Docker container is REST over HTTP, but other communications methods are possible.
  • In order to do anything useful -- multi-container systems -- you need to choose a "distributed container management system" (Kubernetes, Yarn, Swarm, MESOS). These systems are designed to allow developers to specify the set of containers that need to be spawned from "container images" and they help set up the connections between the containers and the outside world.
  • Some folks think of a container management system as a "cloud operating system" -- and this is a pretty good metaphor. The container management system is scheduling and managing a set of resources.
  • There are other tools to consider: for example, Fabric8 (a development environment that supports Kubernetes)
  • Side note: There are some current "format wars" in the container world -- Docker versus Rocket (http://coreos.com/blog/rocket). This split in the container community will probably be resolved soon, because Docker is addressing the questions that caused the split.
• The full report on the workshop can be found on GitHub: SATURN Containers Workshop report

Grady Booch keynote

The main conference keynote speaker was Grady Booch -- he still works for IBM (Chief Architext), and he currently lives in Maui, Hawaii. Booch is working with others on a PBS television documentary about how computing is fundamental to modern science. (Information on the documentary: http://computingthehumanexperience.com).

Booch’s keynote talk was "Abstracting the Unknown", and it focused on the hardest part of doing software architecture and design -- working on new and novel systems:

• He says that it is a "hill climbing" activity -- inherently iterative and incremental, using feedback from the iterations to decide on the next direction to proceed in evolving the partial system
• The design/development increments are "periods of punctuated equilibrium"
• You need to have plateaus - where you consider the many forces that affect your system solution: cost/schedule, functionality, compatibility, and others

Booch points out that you may use different "processes" for different problems:

• There is often a link between the degree of formality of the development process and the level of criticality/risk in the problem area (less structure for developing Facebook apps, more formality for designing heart pacemakers)
• Size matters -- but although big systems and big development teams add more complexity, you can also benefit from a lot duplication in parts of the problem space
• There is a kind of "physics" in large complex systems - the "weight" of a system’s software can make it harder to change over time
• One interesting data point: Google touches 50% of their files every month - it means that their architecture is "not completely baked"
• But in other systems, the "core" may be very stable, with changes mostly around the edges of the design

Booch spent a lot of time early in the talk going over the history of what he called "computational art" -- really just the evolution from the Renaissance to the information age of drawing and painting techniques (especially 3D perspective), followed by advances in computer graphics and computer animation technology (ray tracing, fractals, motion models) to render more and more realistic images. Some parts of this evolution are due to better hardware and better algorithms, but there is also an evolution of architecture and design.

Booch mentioned the need for architecture work in the Internet of Things area -- where there will soon be "billions and billions" of devices communicating on the Internet.

Booch also spent a bit of time talking about the evolution of the software workforce.

• The most common software development model is direction "StackOverflow-driven development" -- doing web searches in StackOverflow.com to find code snippets to implement each task.
• Most software developers are not formally trained in programming. This is OK for a lot of product development, but certainly not for life-critical systems.
• (We heard Mary Shaw citing some of the same statistics in her SATURN 2015 keynote and her SPLASH 2015 panel session.)

One insight Booch shared was the differences in the amount of creativity in solving standard (or classical) problems and in building unprecedented systems

• The primary means of solving classical problems is "theft" (reusing existing solutions -- or using StackOverflow). There is a much smaller component of "using a method" or "applying intuition".
• But unprecedented systems require a lot of intuition in the solution process.

Booch argues for a few important development practices:

• iterative development with a regular heartbeat
• some kind of architectural governance -- to make sure we have some levers we can use to control the system structure
• a set of best practices that can be applied to assist innovation and quality (make sure to include time to refactor an improve the software)

Two potential problems to watch for:

• code bloat, often caused by cut-and-paste development
• organizational structure problems - you must consider organizational structure and teamwork issues, and sometimes you must "refactor the team" to be effective

Booch talked about the importance of architecture in long-lived systems. The agile community has shied away from architecture planning, but Booch mentioned two systems that have benefitted from having good "central architects" - Linux and IBM Watson.

Architecture isn’t easy in building unprecedented systems. You must be prepared to fail -- to take time to rethink the architecture decisions. Booch’s advice is to fail early, fail often, fail safely, use a good toolbag, and be prepared to get out of your "comfort zone". It is valuable to try to do the hard parts first.

Next year’s SATURN conference

Next year, SATURN 2017 will be in Denver -- May 1-4, 2017. Check the SATURN website: http://www.sei.cmu.edu/saturn/2017.