SATURN 2014 Presentations

This file contains presentations from the SEI Software Architecture Technology User Network Workshop (SATURN 2014) event (May 5-9, 2014 in Portland, Oregon).

Sessions and presentations included:


*Approaching Security from an "Architecture First" Perspective, Rick Kazman, Jungwoo Ryoo, and Humberto Cervantes
*Archinotes: A Global Agile Architecture Design Tool, Juan Urrego and Dario Correal 
*BI/Big Data Reference Architectures and Case Studies, Serhiy Haziyev and Olha Hrytsay
*Combining Architectural Methods to Build a Reference Architecture for Ground Radar Monitoring Systems, Alejandro Bianchi, Andres Diaz-Pace, Leonardo Seminara, and Gustavo De Souza
*The Costing View of Architecture, Eltjo Poort
*Creating a Sustainable Architecture Organization, William Beshilas
*Engineering Velocity: Continuous Delivery at Netflix (Keynote), Dianne Marsh
*Expanding Legacy Systems Using Model-Driven Engineering (MDE), William Smith and Kevin Nguyen
*Experience of Combining QAW and Social Listening for Better Architecture, Seung Ho Nam 
*Facilitating the Mini-Quality Attributes Workshop, Will Chaparro and Michael Keeling
*For Maximum Awesome (Keynote), Joe Justice 
*How to Incorporate Software Architecture into Your Business Model, Tim Kertis
*Identifying and Protecting Architecturally Significant Code, Mehdi Mirakhorli and Jane Cleland-Huang 
*Impact of Architecture on Continuous Delivery, Russell Miller 
*Integrating Enterprise Architecture, Voytek Janisz
*Is Your Team Instrument Rated (Or: Deploying 89,000 Times a Day), J. Paul Reed
*Metrics for Simplifying and Standardizing Enterprise Architecture: An Experience Report for an Oil and Gas Organization, Alexis Ocampo, Jens Heidrich, and V. Basili 
*The New Era of Integrated Software Delivery with DevOps, Sujatha Perepa
*Past, Present, and Future of APIs for Mobile and Web Apps, Ole Lensmar
*Service Variability in Multi-Tenant Engineering: A Systematic Literature Review on the State of Practice, Limitations, and Prospects, Ouh Eng Lieh 
*Sink or Swim: Enhancing Pipe-and-Filter Diagrams, Ivan Gevirtz
*Software Architecture Community of Practice at Raytheon, Sunitha Vallabhaneni, Douglas Dusseau, and Keith Nolan 
*Software Architecture in the Presales Process, Humberto Cervantes
*Teaching Architecture Metamodel-First, George Fairbanks 
*Transparency: An Architecture Principle for Socio-Technical Ecosystems, Felix Bachmann and Linda M. Northrop
*Under N: Acceptance to Delivery in N Hours, Umashankar Velusamy
*Understanding Reference Models and Reference Architectures, Chris Armstrong
*What Happens When You Break All the Rules?, Harald Wesenberg, Jorn Olmheim, and Einar Landre







Approaching Security from an "Architecture First" Perspective, Rick Kazman, Jungwoo Ryoo, and Humberto Cervantes

While software security is an increasing concern for software and system architects, few architects approach this quality concern strategically. Architects and developers typically focus on functionality, and they often apply security as a Band-Aid solution after developing an application. In this presentation, we report on three case studies of real-world projects—two industrial and one open source—for which we attempted to measure the consequences of three architectural approaches to security. These architectural approaches differ on the degree of adoption of security frameworks for the development projects: “no adoption,” where no security frameworks are used; “partial adoption,” where security frameworks are introduced in the middle of the lifetime of a software application; and “full adoption,” where one or more security frameworks are adopted from the beginning of the development process. We conducted the case studies by interviewing architects about the security tactics implemented in their projects and by scanning the systems to identify their vulnerabilities using a commercial security scanner (IBM’s AppScan). The results of our case studies indicate that a strategic, system-wide, architectural approach to security, implemented through the partial or full adoption of security frameworks, results in the best outcome from both security and maintenance cost perspectives.






Archinotes: A Global Agile Architecture Design Tool, Juan Urrego and Dario Correal 

Currently, many software-development organizations have adopted a work methodology around global software development in which the members of a geographically dispersed team can coordinate their activities through collaboration tools. These tools focus primarily on the construction process rather than on concrete design. This kind of organization usually has teams in which members are located in different cities or even in different countries. As a result, architects must attend face-to-face meetings where they can define the architecture together. To tackle this challenge, we developed Archinotes, a tool to support approaches to global agile-architecture design. Using this tool, architects can coordinate, communicate, and control an agile software-architecture design process while being geographically separated. In this presentation, we demonstrate the main features of Archinotes and present its main benefits for an organization with geographically dispersed teams.






BI/Big Data Reference Architectures and Case Studies, Serhiy Haziyev and Olha Hrytsay

If data were equated to temperature in physical analogy, according to the second law of thermodynamics its accumulation would lead to the heat death of the universe. In fact, 90% of the world’s data has been generated during the last two years. Fortunately, business intelligence (BI) architectures and technologies are evolving rapidly to keep up with the exponential rise of data and project complexity. An almost 30-year era of dominance for the relational database management system (RDBMS) ended, and there is no one-size-fits-all solution that solves all of today’s Big Data challenges. BI architecture drivers must change to satisfy new requirements in format, volume, latency, hosting, analysis, reporting, and visualization. In this session, we expose a number of reference architectures that address these challenges and speed up the design and implementation process, making it more predictable and economical:

traditional architecture based on an RDMBS data warehouse but modernized with column-based storage to handle a high load and capacity
NoSQL-based architectures that address Big Data batch and stream-based processing and use popular NoSQL and complex event-processing solutions
hybrid architecture that combines traditional and NoSQL approaches to achieve completeness that would not be possible with either alone
The architectures are accompanied by real-life projects and case studies that the presenters have performed for multiple companies, including Fortune 100 and start-ups.






Combining Architectural Methods to Build a Reference Architecture for Ground Radar Monitoring Systems, Alejandro Bianchi, Andres Diaz-Pace, Leonardo Seminara, and Gustavo De Souza

A reference software architecture (RSA) enables systematic reuse of domain knowledge and components when developing concrete architectures and systems, leading to reduced development cycles, increased quality, and conceptual integrity. However, creating an RSA is challenging because it requires an initial investment and should ensure adequacy of the RSA for the organization. In this presentation, we report the experiences of creating an RSA for an Argentine R&D company in the domain of ground radar monitoring (GRM) systems. This was a brown-field development: we departed from an existing system for processing telemetry from radars, and we evolved it toward a more general architecture. We aimed to adjust the development estimates for GRM products using the RSA as the baseline. Our architecture-centric approach was driven by the company’s business goals and the corresponding quality attributes for the product family. We captured these quality attributes through a Quality Attribute Workshop, then engineered them into an RSA blueprint following a three-iteration Attribute-Driven Design process. We documented key design decisions and architectural views, and evaluated the RSA using the Architecture Tradeoff Analysis Method. Along this path, the architectural vision defined an iterative and prototype-based development strategy and infused architecture-based techniques into the software division of the company. The resulting RSA successfully articulated the main elements and business rules of the GRM domain via a set of architectural mechanisms and practices.





The Costing View of Architecture, Eltjo Poort

All modern architecture documentation practices promote the use of multiple views to document how the architecture addresses various concerns of different stakeholders. So far, little attention has been paid to an important business concern: that of costing a solution. At CGI, we often have to architect and cost a solution in a very limited time frame, usually when answering a Request for Proposal within a hard deadline. One of the key objectives of Risk- and Cost-Driven Architecture (RCDA), CGI’s agile solution-architecting approach, is to focus the architect’s attention on economic aspects. In this context, we have developed a viewpoint that helps architects document their architectures in a way that lets them quickly establish the cost parameters: the Delivery Breakdown View. By combining guidance from the ISO 42010 Architecture Documentation standard with the Product Breakdown Structure known from project management methods, the Delivery Breakdown View helps architects address important cost-related concerns and communicate the resolution of these concerns to stakeholders. In this presentation, we will discuss the importance of costing in architecting, present the Delivery Breakdown View that we developed, and demonstrate its use in an architecture documentation template from CGI.






Creating a Sustainable Architecture Organization, William Beshilas

Our clients have asked us to help them to create or mature their architecture organizations, which are typically part of an Information Technology (IT) department. Through helping our clients, we developed a framework that we have used successfully with over 20 clients. The framework addresses the following aspects of what an architecture organization should be concerned with in order to be sustainable:

charter that includes mission and vision, roles, and organization
governance
service catalog
service delivery management
After reviewing the framework, we will present lessons learned from working with the various clients. After the session, the audience will be aware of the importance of defining the mission and vision of an architecture organization and of understanding the need for change management. With this awareness, the audience will be able assess how well an architecture organization understands its environment and determine if it is meeting the needs of the organization.







Engineering Velocity: Continuous Delivery at Netflix (Keynote), Dianne Marsh

At Netflix, we realize that there's a tension between the availability of our service and our speed of innovation. If we move slowly, we can be very available—but that's not a good business proposition. If we move super fast, we risk downtime—and that might annoy our customers. But what if we could increase our velocity without significantly impacting availability? How can we shift that curve so that we're moving faster without dropping any of those coveted 9s?

How can we engineer velocity by weaving together tooling and culture with software development to expose and elevate highly effective practices? This talk describes various components of Netflix's continuous delivery platform—much of which is available in open source. I'll show how these pieces fit together and allow us to build scaffolding so that we're comfortable with software developers making the decision to push the button for prod deployment—and to help them recover if necessary. As a result, we can run fast, trusting our tooling and our culture.

I'll also describe how we test our resiliency through simulating failure, unleashing the monkeys (Simian Army) on our production environment. Because if you're afraid of cute little monkeys, imagine how afraid you'll be of a production environment that offers those same risks but doesn't give you an opportunity to test your response to those dangers.

Throughout this talk, I hope that you will challenge yourself to consider how your company can "shift the curve" through tooling and achieve a high-velocity environment without negatively impacting reliability.







Expanding Legacy Systems Using Model-Driven Engineering (MDE), William Smith and Kevin Nguyen

Applying model-driven engineering (MDE) to develop software architecture for a new project is challenging. Using the same technique for an existing project is even harder. Add the complexity of developing on top of an existing legacy avionics software system, and it seems like moving a mountain. However, it is achievable! Many software systems do not have existing models. Furthermore, a legacy system may be huge, and building a model for it is not a realistic goal. In a time of financial belt-tightening, customers want to be involved in all parts of the design and development process to ensure that their money is spent wisely. They often require a company to use the MDE approach to develop the architecture of their product because it is easy to understand. Thus, they can monitor the progress of the project to make sure it is on target before development begins. So how can projects being built on top of colossal legacy software systems adopt the MDE approach? We will cover 

managing technical debt while expanding the capabilities of an existing system
using MDE to reflect the combined architecture of both legacy and new functionality to satisfy customers’ requirements
personal experience, pitfalls encountered, and results







Experience of Combining QAW and Social Listening for Better Architecture, Seung Ho Nam

The Quality Attribute Workshop (QAW) is a facilitated method of engaging stakeholders to discover driving quality attributes (QAs). To avoid missing important QAs, we would need to have all stakeholders in the QAW. For Samsung, a consumer electronics maker, consumers are our crucial stakeholders, but we could not invite them all to our QAW in the product-development phase. To mitigate the risk of not having the customers in our QAW, we introduced the social-listening technique to our QAW method and built a data analysis system for a social network service. Our system gathers Twitter users' tweets, analyzes them, and generates reports on keywords related to our products. Instead of hearing from real customers in person, we could hear their voices through Twitter very efficiently and turn them into significant QAs. We could not only identify the QAs that customers are most interested in but also capture new QAs that were not elicited by QAW participants. In this presentation, we present our system's details and real project data to discuss the strengths and weaknesses of our QAW combined with the social-listening method. 







Facilitating the Mini-Quality Attributes Workshop, Will Chaparro and Michael Keeling

What if you could reduce cost for a Quality Attributes Workshop (QAW) without sacrificing results? For software-development teams that need an effective yet inexpensive method for eliciting quality requirements with stakeholders, the mini-QAW is a lean workshop that quickly and cost-effectively helps teams identify and prioritize quality attribute scenarios. Unlike the traditional QAW, the mini-QAW substitutes time-consuming, ceremonial activities with equally effective group activities that better promote collaboration and understanding as quickly and cheaply as possible. The mini-QAW achieves this through a quality attributes taxonomy, a clearly defined subset of quality attributes tuned to the presumptive concerns of your stakeholders. The mini-QAW leverages this taxonomy in three primary ways:

Quality attributes defined in the taxonomy form the basis for a structured brainstorming activity called the System Properties Web.
The taxonomy enables an informative visualization that allows stakeholders to see the “quality signature” of their system.
A taxonomy-based questionnaire (TBQ) allows facilitators to reliably and predictably elicit good quality attribute concerns from stakeholders.
In this presentation, we describe the mini-QAW, provide concrete examples, and share advice for facilitating workshops based on our experiences conducting mini-QAWs. Attendees will gain the knowledge necessary to facilitate a mini-QAW, tailor a quality attributes taxonomy, and create a TBQ to fit their specific needs.







For Maximum Awesome (Keynote), Joe Justice

Team WIKISPEED is an Agile hardware and engineering company, using Test First development practices run by Scrum teams to produce road-legal cars, microhouses, and social good projects. Joe leads WIKISPEED, a team of 500 volunteers in 20 countries, and walks us through how their 100-MPG road car was made possible in just three months through object-oriented design, iterative development, and Agile project management. Joe worked with the team at Scrum, Inc., to share these learnings, and now he shares his experience report on exactly how Agile from software projects is applied to physical engineering and manufacture, and how cross-functional software team members can blow up the constraints we imagine around traditional manufacturing. Joe will use the example of the design and development of their ultra-efficient, modular cars and clients' projects in satellites, laboratory equipment, missile systems, radio systems, medical devices, and others. 







How to Incorporate Software Architecture into Your Business Model, Tim Kertis

The size and complexity of new software applications is increasing exponentially. Yesterday’s software applications may have been written in a single programming language to run on a single computing platform. The task was readily handled by software engineers. Many of today’s software applications might be written in multiple programming languages and distributed across multiple disparate computing platforms and operating systems. They may also use commercial off-the-shelf or open-source software products and integrate into very large and complex systems. The engineering may need to accommodate the common aspects of an entire product line. No longer is a software engineer trained or prepared for the complexities of this task. This is where new software architecture knowledge, skills, and abilities are needed, and this is where the software architect is born. But the rest of the organization also must recognize the need for software architects, new software-architecture processes, and the impact to the business model to be effective. This presentation provides an overview of the experiences and lessons learned as Raytheon, a technology leader and the fourth largest defense contractor in the world, takes on the challenge of incorporating software architecture into the business model of the organization.







Identifying and Protecting Architecturally Significant Code, Mehdi Mirakhorli and Jane Cleland-Huang

As a software system grows in size, it becomes progressively difficult for programmers to understand the underlying architectural intent and to extract the architectural knowledge they need to implement changes successfully. Unfortunately, anecdotal evidence has shown that such knowledge tends to be tacit, stored in people’s heads, and scattered across software artifacts and repositories. Furthermore, architectural knowledge has a tendency to vaporize over time. Given the size, complexity, and longevity of many projects, developers often lack a comprehensive knowledge of architectural design decisions and make changes in the code that inadvertently degrade the underlying design. In this talk, I present the Archie tool suite, initially funded by the National Science Foundation and further developed under sponsorship of the Department of Homeland Security (DHS). Archie is designed to detect architectural design decisions in code, monitor them during long-term maintenance activities, keep developers informed as they make changes, and help protect critical areas of the code from potential architecture degradation. Archie is a smart integrated-development environment, and several of its components are designed for integration into the DHS’s Software Assurance Market Place (SWAMP). This talk demonstrates how software-development organizations can utilize Archie to integrate architecture awareness into their developers’ daily programming and testing activities. Through a large-scale case study, I demonstrate Archie’s use in practice.







Impact of Architecture on Continuous Delivery, Russell Miller 

The speaker has been leading the construction of a SaaS application. Guided by lean principles and the need to release small, experimental changes, continuous delivery was a prerequisite. When the project began, we knew that DevOps practices would be required to achieve continuous delivery—that is, full automation of building, testing, configuration, and deployment. But we did not fully appreciate the need for an architecture that lends itself to small batches. Lean principles state that batch size impacts the ability to flow from concept to delivery. A greater up-front appreciation for the impact of architecture on batch size—and, in turn, flow—would have led us to make deeper investments in certain parts of the architecture sooner. This presentation highlights key lessons learned in the following areas:

aspects of architecture and design that impact batch size
strategies for minimizing batch size in an evolving architecture
other related design techniques that impact flow
It is not enough to have great DevOps. Architecture significantly impacts the likelihood of achieving continuous delivery goals. This session explains how specific investments in the architecture and design can decrease batch size. Smaller batch size increases flow. And the goal of lean, continuous delivery is the predictable, fast flow of improvements into user hands.






Integrating Enterprise Architecture, Voytek Janisz

In the era when contributing to business value is the principal consideration of IT, large and distributed organizations face a challenge of understanding how their capabilities are realized and how they can synchronously evolve them in alignment with business strategy. Structured information coupled with efficient architecture processes sets the foundation by addressing several issues: 

Complex interdependent systems that evolved independently increase technical debt. 
Nonexistent, inconsistent, or scattered architecture descriptions make planning difficult and extend the delivery time of solutions. 
Unclear dependencies of business capabilities on technology lead to weak commitment to business goals. 

The TOGAF, ArchiMate, and Sparx EA tools are cornerstones of Progressive's approach to integrated enterprise architecture. By leveraging existing systems-development life-cycle processes and architecture-governance structures, Progressive implemented elements of the TOGAF Architecture Development Method and established consistency in defining and reviewing target architectures. Investing in modeling skills and introducing standard building blocks for architecture models allow architects to describe the systems and capabilities in a uniform way that produces an overall view of the current and future states of the enterprise. This presentation presents a practical approach to implementing integrated enterprise architecture at a large organization. Specific tools, frameworks, and languages serve only as a context for this experience-based story.







Is Your Team Instrument Rated (Or: Deploying 89,000 Times a Day), J. Paul Reed

As DevOps matures from craft, through trade, to a science, we are starting to work on distilling out how we can make DevOps' implementation and the organizational transformation repeatable and predictable, across all kinds of environments. As part of that search, it is time to start looking at humanity's other "operational" endeavors and see what is applicable to DevOps. This talk examines one of the largest operational systems built to date: the national airspace system. We will look at specific aspects of how controllers (operations teams) work with pilots (developers) to safely move millions of passengers (customers) every year, with an incident rate that would make any development shop jealous. In aviation, harsher, more crowded, and inclement conditions all require additional training: an instrument rating. Similarly, developers and operations teams buying in to "DevOps culture" is a great start, but it's often hard to nail down what that actually means. We'll examine the specific behavioral and operational elements of this other complex system that has been tamed and look at what's applicable to implementing a DevOps culture within our own industry. Finally, we'll examine some of aviation's hard-learned lessons and look at ways we can leverage this knowledge and avoid those classes of pitfalls.







Metrics for Simplifying and Standardizing Enterprise Architecture: An Experience Report for an Oil and Gas Organization, Alexis Ocampo, Jens Heidrich, and V. Basili 

The concept of “software quality” is often hard to capture for an organization. Quality models aim to make the concept more operational by refining the quality of software-development products and processes into subconcepts to the level of concrete metrics and indicators. In practice, it is difficult for an organization to produce a reliable quality model because quality depends on numerous organizational context factors, and the model, metrics, and indicators must be tailored specifically to the organization. This is a presentation of the Software Product Quality Model, with emphasis on architecture metrics, developed for Ecopetrol and its application and visualization on real software systems of Ecopetrol’s enterprise architecture. The model contains metrics helpful for analyzing the external dependencies and structure of an application based on its modeled relationships to other applications as well as the used and provided interfaces according to the interface integration type. Equally advanced visualization of the models has been created for illustrating the coupling and complexity of the enterprise architecture. The model was rolled out in 2012 and has been helpful for architects to set baselines and monitor evolution toward the organizational IT strategy as they sought to simplify and standardize the IT landscape. The model specially tailored for Ecopetrol offers architects a common language for software quality, increasing model acceptance and improving communication.






The New Era of Integrated Software Delivery with DevOps, Sujatha Perepa

To succeed in the technology trinity of the new era—Big Data, cloud computing, and mobile technologies—we must embrace new and innovative methods of software delivery. Traditional development and deployment methods are too slow to cater to current fast-paced market trends and too expensive and manual for the present economic context. It is time to bring innovation to the forefront again and change the approach and pace of software delivery through development and operations integration, an incremental approach to delivery, automation throughout the delivery life cycle, and continuous delivery and monitoring of systems. These approaches require leveraging a company's existing investments while introducing new ones to their IT infrastructure. The presenter will discuss the approaches now available to software-delivery teams and explain IBM's approaches and solutions. Additionally, she will discuss the need for seamless synchronization of business and IT strategies and goals. The presenter will also cover how software delivery can enable the development and maintenance of multiplatform applications for cloud and mobile technologies. Finally, she will describe how the DevOps approach provides cost efficiencies while allowing software-delivery teams to maintain control of the quality and efficiency of the delivery.






Past, Present, and Future of APIs for Mobile and Web Apps, Ole Lensmar

Many companies today are moving Web application programming interfaces (APIs) to the core of their technology and business strategies, requiring them to build APIs that are both highly competitive and appealing to consumers. Given the rapid evolution of API technologies and consumer expectations, making the right choices when building and consuming these APIs is no easy task. Chief Architect Ole Lensmar digs into the diverse mix of historic, current, and upcoming technology trends in APIs for Web and mobile apps—including CORBA, Thrift, XML-RPC, and WebSockets—and gives hands-on advice about making the right technology and implementation choices for both API providers and consumers.  







Service Variability in Multi-Tenant Engineering: A Systematic Literature Review on the State of Practice, Limitations, and Prospects, Ouh Eng Lieh

Service variability is the degree of actual variability from the service provider over the variability required by the tenants for the service. With a growing number of tenants, the likelihood of facing more diverse tenants’ requirements will increase. We conducted a study of how choices regarding service architecture affect service variability and the cost of supporting a service. We identified positive and negative impacts of service architectural choices on service variability. We conducted workshops with industry service providers to validate our choices and their experiences on multi-tenant engineering. Knowledge of this information can assist participants with making more informed decisions regarding multi-tenant engineering.







Sink or Swim: Enhancing Pipe-and-Filter Diagrams, Ivan Gevirtz

Sink or Swim is a specialization of the pipe-and-filter architectural style. It enables developers to reason about hard problems in distributed systems and data processing by focusing attention on the push or pull nature of the filter coupling. This is accomplished by creating two connector subtypes (push and pull) and elaborating the filters with synchronous (active) or asynchronous (passive) ports. It is then possible to name and characterize eight subtypes of filters, one for each combination of {sync/async, input/output, middle/terminal}. This lighthearted talk covers how the style was invented, how it works, how it helps developers reason about hard problems, and how it was successfully applied to yield orders-of-magnitude performance improvements to existing systems. This style has several advantages over the regular pipe-and-filter style: 

The style makes problems easy to spot through a graphical notation that enables and encourages visual reasoning. 
The style makes anti-patterns visible by highlighting resource implications of given usage patterns.
A small catalog of rewrite rules guides developers to refactor designs at the style level to avoid performance (and other) problems.







Software Architecture Community of Practice at Raytheon, Sunitha Vallabhaneni, Douglas Dusseau, and Keith Nolan 

Four years ago, Raytheon established its Software Architect Training and Development Program (SWAP) to ensure that a standardized, repeatable approach to software architecting is deployed across the company. The SWAP complements our Raytheon Certified Architect Program (RCAP) and fills a gap that existed in providing skills for software architects entering the middle phase of their careers. A key component of the program is establishing and cultivating software architecture community of practices (CoPs). CoPs facilitate sharing architecture best practices, lessons learned, patterns, strategies, styles, and heuristics among architects working on a variety of programs across our businesses. We found that the most effective CoPs are those that are self-organized as opposed to management directed. Key to the CoPs is an effective collaboration environment providing the latest news, brown bags, roadmaps, architecture process, tools, and reference material needed to educate aspiring architects. This presentation provides a case study of our motivation for establishing the program and lessons learned that apply to other organizations deploying a similar approach. We examine the dynamics of establishing a new training program and creating an environment in which CoPs effectively form and flourish. We discuss our approach, including the structure of the program, how the SWAP compares to the RCAP, and what communication approaches worked in deploying CoPs across our business.






Software Architecture in the Presales Process, Humberto Cervantes

Quarksoft is a Mexican software-development company at Capability Maturity Model Integration Level 5 and develops custom software for government and private sectors in diverse domains using the Personal Software Process and Team Software Process. Although Quarksoft uses architecture practices during the development of software systems, we have found another moment in the life cycle of a project when these practices provide great value—the presales process. The presales process occurs when a customer requests a technical and economic proposal for developing a software system. The customer’s acceptance of the proposal results in building the software system. The technical proposal is developed in a short time, so usually only high-level requirements can be gathered. A software architect uses these high-level requirements to produce an initial architecture that, along with historical data, is used to estimate the project. Developing this initial architecture involves important decisions, such as selecting reference architecture, technologies, and the method of deploying the application. Furthermore, the estimate provided to the customer is typically fixed, so there is great interest in producing a good solution in a short time. In the last year, we worked to adapt architectural practices that are currently used in a development project to produce the initial architecture for the presales process. In this talk, we discuss these practices and our encouraging results.







Teaching Architecture Metamodel-First, George Fairbanks

Despite software architecture being recognized as a discipline for about two decades, it is not commonly taught in universities or to practitioners. One potential obstacle is the highly abstract nature of the subject: Less experienced students quickly forget the abstract lessons and experienced students feel that software architecture is disconnected from their daily work. In this talk, I discuss a novel approach to teaching software architecture based on metamodels. Students start by sketching a simple system. I then discuss typical flaws (e.g., showing a runtime “box” talking to a compile-time “box”) and build their understanding of the metamodel behind the diagram, including views for compile time, runtime, and allocation. I provide a standard palette (i.e., metamodel) for each view, and students learn why the constrained metamodel aids their reasoning. The overall message is that a diagram is really a model, and models elide details, so it is essential to know what question a model should answer so you can reveal (and elide) the right details. Then the students repeat the same exercise of sketching a simple system, with improved results. I have applied this approach with about 50 software engineers at my current company with good results: students stay engaged and report that the lessons are directly relevant to their daily work.







Transparency: An Architecture Principle for Socio-Technical Ecosystems, Felix Bachmann and Linda M. Northrop

The Extreme Science and Engineering Discovery Environment (XSEDE) Project is a large multi-institution effort to help scientists in multiple disciplines access and share a network of supercomputer resources, code, and data. XSEDE is a socio-technical ecosystem; it provides a computational infrastructure that helps scientists access many different supercomputing sites that have different policies and software infrastructures; the users come from different scientific and university communities with different priorities; and the developers and architects come from different institutions and subcommunities with local priorities. An SEI team has worked with XSEDE to establish sound architecture-centric engineering practices across the distributed architecture and development teams. However, productivity is not yet acceptable. An underlying cause is lack of transparency into the process and artifacts. Three factors contribute to transparency deficiencies:

Many groups do things differently, using different tools. That makes information disappear or appear when it crosses the boundary to other groups.
People desire to keep unfinished changes private, allowing them to become externally visible only when they reach a publishable state.
The sheer volume of concurrent activities and artifacts requires more time for reviews and decisions.
We report on efforts to increase transparency using automated support from collaborative development environments, online deliberation, information flow analysis, and machine learning tools.






Under N: Acceptance to Delivery in N Hours, Umashankar Velusamy

How about delivering a business need from acceptance to production in less than 12 hours? Or delivering in the absolute time it would actually take—not an hour more and not an hour less? Under-N methodology provides a framework to uncover hidden capabilities within IT applications and IT application teams and then to use the capabilities to deliver a business need, change, or want in under N hours, where N is the absolute time it takes to deliver. It also elicits capabilities that may not yet be present but that are possible, while outlining four atomic change capabilities that, when implemented, will enable IT applications to deliver changes in an under-N fashion by mixing and matching. The presentation outlines a template to frame these capabilities by asking the right questions to procure all the answers that will be needed to execute the capability and to engage the correct stakeholders. In addition, the presenter proposes ways to scale the capabilities across an enterprise by means of a challenge process and by celebrating the best.






Understanding Reference Models and Reference Architectures, Chris Armstrong

The notion of reference models and reference architectures are used pervasively in the architecture profession. However, when applying these concepts in practice, there is often confusion as to how they are different, yet related. The speaker will present industry-standard best practices regarding how to use reference models for categorizing architecture content for different purposes (such as planning, life-cycle management, gap analysis, and enterprise-wide alignment) and how they relate to architecture and solution building blocks (per TOGAF). The presentation continues with a discussion of how reference architectures are similarly used but also how they can be used to represent architecture patterns, design patterns, and best practices.






What Happens When You Break All the Rules?, Harald Wesenberg, Jorn Olmheim, and Einar Landre

In 2013 Statoil launched a public ocean observatory service outside Lofoten and Vesteralen, Norway. The key parts of the portal were developed in four months on a budget of 200K USD, but continuous development is under way to fulfill oceanographic and environmental research needs. All large organizations have rules to follow. In combination with other factors such as organizational structure, sourcing model, software architectures, and development approach, rules can increase project cost and slow development. The authors’ experience has provided a keen sense of what makes software projects successful and possible pitfalls to watch out for. Even in large organizations with comprehensive rule books, it is possible to run successful software-development projects without huge investments in time and money, but often a few rules have to be stretched. We address some questions facing software architects and use project experience to illustrate the learnings: 

What are the most important software-development rules in today’s dynamic business environment? 
How can you use the software architecture and development team structure to compensate for organizational and procedural failings? 
Faced with a thick rule book, how do you know which rules to break, and how do you handle breaking them?
How can you use models such as the Dreyfus model of skills acquisition to evaluate the team maturity and determine how strictly to follow the rules?