Download all the SATURN 2013 presentations now.

Migrating Legacy Applications: Challenges in Service Oriented Architecture and Cloud Computing Environments is a book by Grace Lewis of the SEI staff along with Anca Daniela Ionita (University Politehnica of Bucharest, Romania) and Marin Litoiu (York University, Canada) that presents a closer look at the partnership between service-oriented architecture and cloud-computing environments while analyzing potential solutions to challenges related to the migration of legacy applications.

The book recently received a favorable review from Pethuru Raj, IBM Global Cloud Center of Excellence (CoE), India, who wrote,

This book is all about the correct compilation of proven and potential approaches, tools, techniques and tips for smoothly and systematically modernizing and moving old software systems to service systems that can be easily deployed in and delivered from cloud environments. This is an informative and inspiring book authored by accomplished professors, practitioners and professionals for worldwide software developers, architects, consultants and experts who are assigned to ponder about the ways and means of legacy migration.

The second award, the IEEE Software SATURN New Directions Presentation Award, is given to the presentation that best describes innovative new approaches and thought leadership in the application of architecture-centric practices. Olaf Zimmermann, with his work on SOA architecture decision modeling, Walter Risi of Pragma Consultores, with his work on sourcing non-traditional talent and revamping existing talent, and Arjen Uittenbogaard of Inspearit for his work on storytelling and mythology for architects received this award in 2010, 2011, and 2012 respectively. This year’s award winner was Darryl Nelson of Raytheon for his presentation titled Next-Gen Web Architecture for the Cloud Era.

In addition to reflecting the high regard of SATURN attendees, these awards also contribute to the maturation of the practice of software architecture by recognizing sound and innovative practices.

A committee composed of IEEE Software board members and SEI staff members also selects a number of presentations, including those of the awards recipients, to be further developed into papers that are then considered for publication in IEEE Software. The selected papers go through the rigorous review process of IEEE Software, and the schedule builds in opportunities for feedback to the authors and mentoring in how to write an experience report. Selected papers are then published in the Insights section of IEEE Software.

SATURN 2013 drew 209 attendees, the most ever at a SATURN conference, 133 of whom had never before attended SATURN. There were 20 countries and 117 organizations represented.

IEEE Invited Talk: Games Software Architect Play: On Reasoning Fallacies, Cognitive Biases, and Politics
Phillippe Kruchten, University of British Columbia

Phillippe got exposure to large and not-so-large companies as a software architecture consultant with Rational in the early part of the century. Everywhere, he saw how design really was the same thing as making decisions, and everyone uses a process to do that.

Architectural design is about making decisions. Providing a rationale for the design is the argument behind it. “The life of a software architect is a long (and sometimes painful) succession of suboptimal decision made partially in the dark,” he says. On a positive note, architects can get help by dividing and conquering, bringing in an outsider for additional perspective, and reframing the problem, in addition to many other techniques. But not everything is rosy: there are cognitive biases, reasoning fallacies, and political games.

Cognitive biases occur because designers often rely on intuition, but their intuition is flawed. Reasoning fallacies occur because flawed arguments/incorrect reasoning leads to a potentially wrong decision. Beliefs can also be presented as facts, but most fallacies are accidental. Political games are a set of arguments, superficially plausible, possibly leading to a design decision, but with a concealed ulterior motive.

Phillippe mentions the coincidence of the overlap of this part of his talk with Mary Poppendieck’s this morning. Regardless, architects rely on their intuition, and it is flawed for various reasons. The most humorous of these is the bias bias, which is where the architects think they are not affected by bias!

Phillippe presents a catalog of these games:

• Golden Hammer: when you have a hammer, everything looks like a nail. After developing a deep expertise with some technique/tool/technology, architects tend to favor it, even when it’s not necessarily appropriate.
• Elephant in the Room: all architects are fully aware of some major issue that really must be decided, but everyone keeps busy tackling small items, ignoring the big issue, pretending it does not exist, hoping maybe that it will vanish by magic or that someone else will take care of it.
• Not Invented Here: an architect avoids using or buying something because it comes from another culture or company. Sometimes used jointly with the Golden Hammer.
• Anchoring: relying heavily on one piece of information, to the detriment of other pieces of information, to justify a choice.

But these mental shortcuts aren’t all bad. In his book Blink, Malcolm Gladwell praises the power of snap decisions.

• “Obviously…” is a strong heuristic to look for a non sequitur
• “Yes, but…” can be a delaying tactic
• Perfection or bust: thinking that we need an optimal solution (the fastest, cheapest, nicest, etc., way to do something)
• Cargo Cult: a group of people who imitate the superficial exterior of a process or system without having any understanding of the underlying substance. Gladwell points out that he saw this a lot as people tried to use the Rational Unified Process.
• It has worked before: the conditions when it worked before might have been different, though. This often follows a “blink” decision.
• Sour Grapes: when a tool or solution doesn’t work for you, you decide it is the tool that is the problem.
• Swamped by Evidence: repeating something in public often enough that in the end, it becomes familiar and will look more likely to be true in a subsequent department
• “It’s a Secret”: impose a solution but withholding any evidence, claiming that there are some business reasons to do it that cannot be disclosed at this point
• Teacher’s Pet: making a decision a certain way because the boss will like it
• Groupthink: within a deeply cohesive in-group whose members try to minimize conflict and reach consensus without critically testing
• Let us have a vote: substitutes popularity for correctness in decision making

So what do we know when we’ve become aware of these games? Well, we could always use the knowledge malevolently and exploit them to get what we want. We could be the contrarian who debunks these in a group, or at least challenges the premises.

If there is an opposite to operating under these biases, it must be critical thinking. By that we mean thinking for a purpose, reasoning about data, drawing conclusions, and inferring implications.

Further readings for understanding and mitigating cognitive bias include Thinking Fast and Slow, Daniel Kahneman.

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.

Sascha et al. are trying to transform this company, making it a software power house, and building a community to leverage knowledge and improve performance within the company. To support the transformation, they started by establishing communication and sharing networks such as newsletters, internal community-driven question-and-answer forums, and a training and information page. They then attempted to improve practices by providing training and a team assessment method to identify problem areas. This assessment method emphasizes static analysis, coding standards, and other “best practices.” This effort was then supported by tools unification, providing a set of tools for all organizations to use.

Sascha et al. also emphasized training taking a multi-pronged approach. They made e-learning available to employees to refine their skills; they also used the communication channels they’d established earlier to deliver additional training. The most effective and well-attended approach, however, was webinars and courses held concurrently around the globe. They found that the webinar attendance is constantly increasing. This is remarkable because software development is not consolidated into a business unit; rather, it is part of hardware development organizations.

In all, there is still significant work to be done to complete the transformation, but the steps taken by ABB have been promising.

Mission Thread Workshop (MTW): Preparation and Execution
Tim Morrow, SEI

Similar to the ATAM, the Mission Thread Workshop (MTW) is a process for eliciting requirements and shaping the architecture of a system of systems. There are three phases:

1. preparation
2. the meeting
3. follow-on

To prepare for the MTW meeting, the organization must express the system’s functionality as a mission thread (or system use case). The system-of-system’s mission purpose and business value must be described. The organization must answer questions like “What is driving the system?” and “Why is this system of systems necessary?” The architectural vision must be expressed along with the system-of-system’s scope and constraints. For each mission thread under consideration, the organization develops one or more vignettes, or step-by-step use scenarios, that enable communication between the team and the other stakeholders. Each vignette should also describe the actors and nodes involved in the scenario, as well as any assumptions. To complete preparation, the quality attributes and stakeholders must be identified for the system of systems. For stakeholders, the architect, modeler, program manager, and end-users must be included.

The MTW meeting takes about 1 to 1.5 days and consists of presenting the architectural plan, reviewing the mission threads and vignettes, and, finally, augmenting the mission threads with feedback and quality attributes.

After the MTW meeting, the mission threads and vignettes are cleaned up, and all comments and challenges are addressed. Before being addressed, the challenges are grouped and organized into challenge areas. Each of these challenge areas is then analyzed, and recommendations are formed to address the challenge.

Mission threads support the architecting of systems of systems. Leveraging the mission threads, the architect can walk through the use scenarios, improving the architecture.

Enterprise Architecture for the “Business of IT”
Charlie Betz

IT can be viewed as value chain (a process) with functions, services, and management data. This view is used to support running a help desk, portfolio management, or other operational applications. Charlie needed an architecture to define the system of record for the help desk, the portfolio management, etc.

At Wells Fargo, Charlie, identified four lifecycles:

1. application service
2. infrastructure
3. asset (the licenses and instances for the actual software)
4. technology product (the actual software)

IT services is a delivery of transactional value, but also a human who defines its value, its “moment of truth.” These IT services are a system of systems: there are application services running on infrastructure services, running on the assets or instances of a technology product.

Charlie defines a lifecycle for the inception through retiring of IT services. This provides a clean vocabulary for the process of developing IT services. Thus, both the process and the system of systems provide different IT value: the customer value and the IT value.

How can we evaluate this value, or more importantly, measure improvements? There are numerous things that can be measured such as lifecycle value, quantity of security breaches, data quality, etc. For this, we look at the function-decomposition view of the system to help. Unfortunately, without historical data as our baseline, we cannot measure improvements. With historical data, an understanding of all four lifecycles, and an understanding of the business architecture, you should be able to build reports to identify both risks and costs.

In summary, Charlie presented on a model for the IT business. From this work, he found that if you optimize portions of the system, the entire system will be less than optimal.

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.

In particular, Eltjo is interested in Risk- and Cost- Driven Architecture (RCDA). RCDA is a repository or practices—that is, a repository of light-weight, proven methods for addressing a problem. These practices can be adopted piecemeal by the development organization.

Why RCDA? Because costs and risks really drive the architecture, as they are typically the most important concerns. These need to be minimized by the project. Architecture should also be minimal because architectural decisions limit downstream decisions when more information is available. Thus, a minimal architecture allows greater flexibility.

RCDA practices are based on what the architect does daily (the core practices): identify and prioritize architectural concerns, research possible solutions, and decide on and evaluate the best fitting solution. These practices, performed iteratively, make up the RCDA workflow. The identification and prioritization is essentially a backlog. The result of the workflow is a set of architectural decisions. After making the decision, the architect needs to figure out what the architecture is going to cost, evaluate the risk, then allow the start of implementation.

To support the core practices, specific, extension practices and lifecycles are used, allowing the tailoring of the method to the needs of the organization.

RCDA is a method that is lean, mean, and agile. The practices eliminate waste, making it lean. The risk and cost focus support the business decisions, making it mean. The iterative decision-making process makes it agile.

Product Analysis Jump-Start Method: Consider the Big Picture Before you Sprint into Your Project
Stephen Letourneau, Sandia National Labs

Have you ever been overly focused on, say, a GPS, and not what places are around you? C’mon, you know you have. Most of us have blindly followed the GPS or even just focused on the next turn in the trip. This happens in development as well, when we don’t have an architecture, or we have an “emergent architecture.” What do you do when you get to a quality attribute requirement such as a security requirement? Well, we use a “refactoring iteration” to rearchitect the system. We could have benefited from an architecture that built in the quality attributes at the beginning of the project, or that we could have changed and communicated within the team more effectively.

Stephen suggests using a product analysis jump-start. This approach attempts to create the “bones” and “lets the development team put the meat on the bones.” The analysis jump-start workflow starts with understanding the business processes and developing a vision. Next, Stephen suggests developing a candidate architecture, mapping quality attributes to features. Finally, during close-out, the risks are prioritized, the architecture is communicated to stakeholders, and a project/product plan is created.

What are the benefits of this approach? It establishes agreement on what is being developed (created a project vision), builds a common understanding on why it is being developed, and identifies the major components. Unfortunately, it is difficult to only do “just enough” architectural design, to stay focused on the outcomes, and to get customer participation.

This is not a one-size-fits-all approach. You will need to tailor it to your organization. Further, it must be conducted fast to fit it into an iteration 0 and reduce waste.

In conclusion, this approach helps to ensure that we build the right system at the outset, providing a direction to keep the team “on-course.”

Introducing Design Pattern-Based Abstract Modeling Construct as a Software Architecture Compositional Technique
Sargon Hasso, Wolterskluwer

So you have the components for a system designed at the class level. How do you integrate these components? Can design patterns be used to integrate these components? Sargon presents a method for integrating components using design patterns. He does this by abstracting out the behavioral collaboration model (the collaboration between components) from the design patterns, using a role-modeling construct. This allows the behavior to be abstracted from the design pattern to show the collaboration among the components.

Let’s illustrate this with an example. Say you have three components for a resort’s room management system. Say we have a component for room reservations, a component with the resort’s organization, and a component for the resort’s services. We want to connect these components. Sargon recommends connecting these components with patterns one level up. In the example, we can use an adapter pattern to connect the resort’s organization and the resort services components. In this way, the behavior between the components are modeled and used to connect components.

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.

The typical evaluation had 2 people from Fraunhofer, 3-15 people from the initiating organization, and 3-15 from the company producing the system. The time the people had to spend varied much more greatly, with Fraunhofer having the lion’s share of the work. The effort’s driving forces included complexity of the system, complexity of the organization, and criticality of the situation.

One key finding was that requirements were neglected to varying degrees, more and more as they moved from runtime requirements, to dev-time, to operation time. Of 43 systems evaluated, the teams categorized their adequacy and found 6 to be “red,” 11 were “yellow,” and 16 were “green.” But these results often can be clouded by context, un-objective questions or goals, and whether or not the problems found are fixable.

Leveraging Simulation to Create Better Software Systems in an Agile World
Jason Ard and Kristine Davidsen, Raytheon Missile Systems

Raytheon is leveraging simulation throughout the entire missile development process: for system design, software development, and system assessment. Writing software for embedded systems, especially those that are part of a larger real-time system, is difficult, since test units can’t be acquired à la carte, and any defect found could be in either the software being written or the test unit itself!

Just as they build the system in layers, Raytheon builds the simulation progressively throughout the project. This is consistent with how simulation is shown as one slice of the space when using the spiral methodology, being passed through again and again. This makes the project more agile as well, providing much quicker feedback than could be gotten from physical tests.

Test-Driven Non-Functionals? Test-Driven Non-Functionals!
Wilco Koom, Xabia

Kent Beck is one of the founding fathers of test-driven development, which he pioneered in the Java World. These tests can be used not only while coding, but also for regression testing. Advantages of using tests include knowing clearly when the job is done, confidence in refactoring, and quality up front. But how can we test non-functional requirements?

Well, to test scalability, we need to create scale. This can be done, for example, with tools such as JMeter. More importantly, when Wilco created such a setup, with multiple JMeter instances pushing requests to Apache, which was configured with 3 JBoss nodes connected to a database, he built it before writing any of his system. That way he could measure the throughput of a single node, two nodes, and then three, and watch the trending.

Wilco says that in general, this kind of practice is really the most useful when automatable.

Keynote Address: Learning to Surf
Mary Poppendieck, Poppendieck.LLC 

We’ve always had to ability to think in different ways by pretending to “stand in someone else’s shoes.” But without even trying, we are using two different modes of thinking: type 1, the fast, reflexive, intuitive mode; and type 2, which is slow and thoughtful.

“Instead of learning to surf, conventional organizations try to organize the waves.” Holding to this metaphor, the more useful approach is to hone one’s type 1 skills. We should become expert surfers. And expertise is classically type 1 behavior, where reflexes are internalized and don’t require thinking. Experts have focused on a subject area long enough to make enough mistakes and get enough feedback to develop a mental model of a problem space, so that if things unfold in the way the expert expects, no thinking is required.

In thinking, there are pitfalls called cognitive biases. Three common ones are confirmation bias, anchoring, and loss aversion. Another potential pitfall is classifying decisions as purely either-or, of which both teenagers and corporations are guilty. But there are other options: why not both, or what about none of the above? Decision makers can also learn as much as possible and decide as late as possible. Solving by looking for patterns or analogies is also an effective technique for decision making. Cognitive biases can also be combated by sourcing different opinions from team members and checking them against base rates of the success of given solutions.

Can big companies surf, or must one necessarily be performing such a feat alone? Well, Ericcson was able to break the false dichotomy of either-or decision making in the context of speed or quality by automating processes sufficiently. He and his team also decided to manage features instead of projects, and to decouple their releases from development. They also embraced uncertainty by having teams not report an estimated completion date, but rather the earliest date by which they might finish, as well as the latest possible date.

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.

Lewis and her team have implemented all these patterns. Currently, they are working on combining all the patterns. Some of the patterns are implemented in a one-to-one situation, which means that one client connects to his own virtual machine.

eMontage: An Architecture for Rapid Integration of Situational Awareness Data at the Edge
Soumya Simanta, Gene Cahill, and Edwin Morris, SEI

Simanta picks up on the first presentation in this session and shows an implementation of the Data Source Integration Pattern.

The connectivity to the network is limited in disaster situations, and the application has to respond quickly. The eMontage server is placed in the tactical domain. Location awareness is important for the application.

It is important to add new data sources as quickly as possible. An approach is to decouple the data sources and encapsulate them. The data model presented is comprised of objects that are shared between the client and server. In order to add data, the different sources have to be mashed up.  The user interface should be unified in the system, and this can be achieved by using mashups. The expensive computations are offloaded to a server node.

Simanta and his team looked at three architectural alternatives: native mobile client only, mobile browser–server, and native mobile client–server.

Adapting View Models as a Means for Sharing User Interface Code Between OS X and iOS
Dileepa Jayathilake, 99XTechnology

Jayathilake showed how to share a significant amount of code between applications for OS X and iOS. The frameworks for those two platforms, Cocoa and Cocoa Touch, share a lot of code.

On first look, both platforms are only able to share the models. If we abstract common view behavior from the platform-specific view behaviors, we can share a lot more code.

Jayathilake applied his theory in a middle-scale application, showing that his ideas work.