SATURN 2013 Governance and Education Session (notes)

Notes by Ian De Silva

Software Development Improvement Program: Enabling Software Excellence at a Hardware Company
Sascha Stoeter, ABB

ABB has historically been a hardware company, but it has been slowly increasing the amount of software development it does since the 80s. It is a distributed company (in 34+ countries) with software embedded into products such as controllers. Each team has its own set of tools to support development efforts.

SATURN 2013 Fusion Methods Session (notes)

Notes by Ian De Silva

Lean and Mean Architecting with Risk- and Cost- Driven Architecture
Eltjo Poort, CGI

Solution architecture includes more than just the software; it may include business processes, information systems, technologies, and the environment. Solution architecture approaches fill the gap between enterprise architecture approaches and technical architecture approaches. Enterprise approaches are weak on transformation and implementation, while technical architecture is weak on cross-technology stakeholder concerns.

SATURN 2013 Architectural Evaluation Session (notes)

Notes by Brendan Foote

All Architecture Evaluation Is Not the Same: Lessons Learned from More Than 50 Architecture Evaluations in Industry
Matthias Naab, Jens Knodel, and Thorsten Keuler, Fraunhofer IESE

Matthias has evaluated many systems’ architecture, ranging from tens of thousands of lines of code to tens of millions, and primarily in Java, C++ and C#. From this he distills out commonalities in the various stages of the evaluations. To start with, the initiator of the evaluation was either the development company or an outside company, such as a current customer or a potential one. The questions being asked also varied—whether wondering if the architecture is adequate for one’s solutions, what the impact would be of changing the system’s paradigm, or how big a difference there was between a system and the reference architecture.

SATURN 2013 Mobile Computing Session (notes)

Notes by Frank M. Rischner

Architecture Patterns for Mobile Systems in Resource-Constrained Environments
Grace Lewis, Jeff Boleng, Gene Cahill, Edwin Morris, Marc Novakouski, James Root, and Soumya Simanta, SEI

First responders, soldiers, and other front-line personnel work in resource-constrained environments. It is necessary to use mobile systems in those environments. The systems are limited in performance and battery life.

This talk is about architectural patterns. The first pattern Lewis talked about is the Data Source Integration Pattern, which means the data source is on the server. Some of the operations on the data are very power consuming, so we don’t want them on the mobile device. The user defines the filters on the mobile device and sends them to the server. The second pattern is the Group Context Awareness Pattern. The users don’t go out in the field alone. The users’ devices are connected to the same controller, so all devices show the same view. Since the users are not in the field alone and probably operate in a close area, only one device needs the GPS has to be turned on. This model is a layered MVC pattern. Rule sets apply to the mission and are interchangeable. The third pattern is the Cloudlet-Based Cyber-Foraging Pattern. Cyber-foraging has been around for a while; the most known application is probably Siri from Apple. The Cloudlet-Based Cyber-Foraging base is on a VM manager.

Get Involved in SEI Research

The SEI is conducting a survey to understand more about the extent to which architectural concerns play a role in agile software development. In particular, the goal of this survey is to understand some of the existing practices used to quantify architecture. This topic is of growing importance. As successful agile techniques are applied to larger and larger projects, they require increased visibility into the architecture of the system. Your participation is important to allow the SEI to correctly characterize the nature of the problem and to understand some solutions that people have found useful.

SATURN 2013 Web and Cloud Architecture Design Session (notes)

Notes by Frank M. Rischner

The Design Space of Modern HTML5/JavaScript Web Applications
Marcin Nowak and Cesare Pautasso, University of Lugano

Whenever we create a web application, we have to decide where the application runs, either on the server side or on the client side. When using HTML5, we push everything but the data to the client.

In the example scenario, the server is treated as the database, and the browser is seen as a terminal. There are several Model View interaction patterns: Model View Controller Pattern, Model View Presenter Pattern, and Model View ViewModel Pattern, which is the most flexible one of the patterns. Most recent movements apply the “Model View *” pattern, which leaves out the controller.

SATURN 2013 Agile II Session (notes)

Notes by Ian De Silva

The Conflict Between Agile and Architecture: Myth or Reality?
Simon Brown, Coding the Architecture

Agile is about working in small increments, getting feedback, and improving the process or product. Architecture is about structure and vision. There is no conflict between agile and architecture because every software project has an architecture. There is, however, a conflict in the approach and team structure.

SATURN 2013 Agile I Session (notes)

Notes by Ian De Silva

Introducing Agile in Large-Scale Projects
Vladimir Koncar, Ericsson Nikola Tesla
Drago Holub, Ericsson Nikola Tesla
Zoran Kokolj, Ericsson Nikola Tesla
Emina Filipovic-Juric, Ericsson Nikola Tesla
Josko Bilic, Ericsson Nikola Tesla

In this talk, Koncar described his team’s experiences using agile on a large-scale telecom project at Ericsson. This hardware-dependent project was estimated to be about 10 million lines of code, requiring the work of 100 developers for two years. Because of hardware-plan instability, uncertain requirements, and sensitive time to market, agile was the development methodology of choice. In particular, they used Scrum with long-term, cross-functional teams.

SATURN 2013 Method Tailoring and Extensibility Session (notes)

Notes by Brendan Foote

Design and Analysis of Cyber-Physical Systems: AADL and Avionics Systems
Julien Delange and Peter Feiler, SEI

Architectural decisions affect nonfunctional requirements, which are critical to the safety of systems. Rework costs increase the later a defect is detected in the software development life cycle. In Delange’s experience, a $10,000 architecture-phase correction can save $3 million! These errors can be caused by mismatched assumptions in embedded software. One anecdote is a train on which the doors wouldn’t close, so the conductor stepped outside to push them closed. But the system assumes the conductor is inside, so the train automatically took off. Dual core laptops also violated many assumptions that developers had made up to that time. To put it glibly, if we can’t get iTunes right on dual core machines, how are we supposed to make safe airplanes with even more complicated hardware?

SATURN 2013 Modeling and Documentation Session (notes)

Notes by Brendan Foote

How to Build, Implement, and Use an Architecture Metamodel
Chris Armstrong, Armstrong Process Group, Inc.

Armstrong discussed the architecture-description standard UML model, showing how an architecture description expresses an architecture, fulfills the concerns of stakeholders, and more. He uses the difference between raw accounting data and the common views the way, say, a CFO would need to because of the way that an architecture is standardized by the RFC 42010 (that is, what subset of the entire UML model is particularly useful?). This leads to his refined viewpoint metamodel. His process group has added the “architecture scenario” to the metamodel, which he points out is not in conflict with the standard. This scenario is defined by a stakeholder, and it contextualizes an architectural concern. He goes on to show how stakeholders and concerns are also connected by architecture viewpoints, of which there are several types. Those types are defined differently depending on whether you talk to TOGAF, DoDAF, etc., but a modeling system should allow you to render your viewpoints in different ways for different consumers (e.g., a grid, diagram, catalog, or dashboard).