Architecture in the Age of Compositionality
Jan Bosch,Vice President of Engineering Process and head of Central Mobile Technologies, Intuit, Inc.

The nature of software engineering is changing. Whereas building systems was previously the predominant activity, the focus has more recently shifted toward composing systems from open-source, commercial, and proprietary components, and to only build the functionality that truly is competitively differentiating. In addition, the way software is developed has changed, focusing especially on short development cycles and frequent (or even continuous) deployment. 

Because of these requirements, teams are often organized around features, rather than components, and can change all components in the system, including their interfaces. A third trend is the increasing adoption of software ecosystems, where significant development of functionality relevant for customers occurs outside the platform organization. Obviously, however, the quality attributes necessary for system success remain important, as well as the ability to easily incorporate new requirements into the system in a cost-effective fashion.

As a result, the role of software architecture (and that of a software architect in particular) is more important in this new world, but there is significant evolution in its implementation. This talk starts by characterizing the new approach to software engineering and the role of compositionality. It then explores the implications for software architecture and the role of the software architect. The talk will present examples from several industries to illustrate specific focus areas.

Click here to download this presentation.

The Intimate Relationship Between Architecture and Code: Architecture Experiences of a Playing Coach
Dave Thomas, CEO of Bedarra Research Labs, Managing Director Object Mentor

Why is that with so many architects we have so little true software architecture, so much technical debt, and such large intractable legacies?  Perhaps it is the fault of the developers who are not listening; not conforming to the architecture guidelines; style; patterns; or UML models. Perhaps it is the fault of profit-driven organizations, which devalue architecture and opt for near-term gratification, thereby encouraging corruption of the code base and violation of the architecture. Clearly it can't be the architects' fault—after all, more and more of us are now certified architects!  Or... are we part of the problem?  Are our disparate views, from the ivory tower of enterprise architecture to the dismissive Agile developer's emergent architecture, really helping?  In the end, our job is to produce software that meets the requirements of both today and tomorrow. Good software is a marriage of architecture and code reflecting the team that designed and built it.

In this talk, I explain why architecture needs to be intimately composed and refined along with the code, and argue that architect is a role, not a job. In my experience, architects with "no code on their hands" have limited positive impact, and even worse, may have substantial negative impact. Architects must express the essential architecture in a tangible way that is easily, effectively, and practically communicated to developers and testers. It is time to put an end to the whole idea of non-functional requirements that get dispatched to specialists who are patched in at the end of the life cycle. Given that what we ship is code, it is imperative that the architecture become an integrated part of the code.  We cannot continue to produce "Once upon a time..." diagrams on the wall or cryptic architecture description languages known only to archbishops and call them "The Architecture." We need to abandon the notion that embedded or database applications are special, and are therefore exempt and lacking tangibility. Only if the architecture and code co-evolve can the product retain its architecture and evolution history.

Architecture at Internet Scale: Lessons Learned from Serving Half a Billion Customers
David Chaiken, Chief Architect, Yahoo!

Imagine that your boss walked into your office and asked you to

• design a web site for one-tenth of the world's population
• capture more than $6 billion of revenue per year
• release new functionality for phones, tablets, and computers on three-week product cycles
• build on legacy systems deployed over the past 15 years

Let's say that you resist your initial impulse to run screaming for the door. What do you do? Where do you start?

It turns out that the principles that you've learned as an architect equip you to deal with systems at Internet scale, but there are some important lessons to learn from building these systems.

This keynote stress tests our understanding of how to manage complexity, the core challenge that architects try to solve on a day­‐to-­day basis. It draws from large-system use cases to show how to apply basic principles of software architecture to balance requirements and constraints. For example, a use case from a system that processes more than a billion transactions per day demonstrates how to solve simultaneously for the well-­known principles: "don't optimize prematurely" and "don't pessimize prematurely." Other case studies show how architects can work with a variety of stakeholders (engineers, business analysts, product managers, executives, and others) to find creative solutions to challenging systems problems. Analyzing these real-­‐world examples gives a realistic but encouraging view of the evolving role of software architects in our industry.

IEEE Software Speaker and Plenary Speaker Presentations from SATURN 2011

Agile Adoption: Does it Have to be All In or Fold?
Rebecca Wirfs-Brock, President, Wirfs-Brock Associates

Adopting Agile approaches can have a huge impact on software development teams. Agile practices can help teams yield more accurate assessments of project progress, better ensure that what gets delivered will be useful, and lead to higher quality products that are more maintainable.

Yet it can be difficult to successfully transition to an Agile approach. Taking an all-or-nothing approach to adopting recognized Agile practices rarely succeeds. As a result, the pragmatic Agile change agent learns to adapt Agile practices to their organization’s unique context. This requires courage, convictions, and experimentation. Successful Agile adopters need to know when to push for changes to the “standard way we do things” and when to adapt or discard ill-fitting Agile practices. This talk will share lessons learned from experiences of those who’ve successfully adapted Agile practices presented by experience reporters that Rebecca shepherded at past Agile conferences. Not willing to leave it at that, Rebecca will conclude by challenging you to examine what it will take for you to succeed with Agile adoption.

Click here to download this presentation.

Managing Architecture for Value
John Favaro, Associate Editor in Chief, IEEE Software

After years of research and industrial practice, the software architecture community has acquired a mature understanding of essential technological issues and is turning its attention to understanding the interaction of architecture with the business and strategy of the organization. However, understanding the value created by architecture is proving to be a difficult and elusive task. Agile approaches are making a positive contribution in this area, but managing architecture for value seems to require yet another mindset. This talk will explore the topic of architecture and value creation from several points of view, including a perspective of corporate strategy and finance.

Click here to download this presentation.

Big Ball of Mud: Is This The Best That Agile Can Do?
Joseph Yoder, The Refactory, Inc.

While much attention had been focused on high-level software architectural patterns, what is, in effect, the de facto standard software architecture has seldom been discussed: the Big Ball of Mud. A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. We've all seen them. These systems show unmistakable signs of unregulated growth and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. Somewhat to our astonishment, since our original statement, no one has ever undertaken to dispute this premise. Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? And how can we make such systems better?

Click here to download this presentation.

Sponsored Presentation from SATURN 2011

Maintaining Technical Quality of Software—It’s the Architecture, Stupid!
Alexander von Zitzewitz, Hello2morrow

Most non-trivial software systems suffer from severe technical and structural debt, and this burden acts like an ever-increasing tax on every code change or new feature. The cost of change is growing significantly faster than the code base, and little is being done to address this problem in a meaningful way. Shouldn’t we assume that project managers and stakeholders would do everything in their power to fight structural and technical debt to keep the system maintainable and the cost of change manageable?

This sponsored session explains why this problem is so difficult to solve and identifies potential solutions that have a high return on investment. As the title indicates, software architecture has a very important influence on the overall maintainability and technical quality of a software system. During a recent informal poll at the New England Java User Group, 80% of the attendees agreed that architecture is the most important long-term success factor for a software system, while only 1% had a process in place to monitor and maintain architectural quality rules.

Program Presentations from SATURN 2011

Architecture is Not Just for Architects

Nurturing the Domain: Avoiding the "Pig in a Poke"
William Martinez Pomares, IASA

In any system, there are at least two domains: the IT domain and at least one business domain. Business stakeholders usually look forward to a solution that solves problems in their domains. Instead, they sometimes get a system that solves the problem in the IT domain, and are forced to learn IT concepts, such as tables and data queues, in order to use the solution. That is an example of the forced domain anti-pattern.

There are problems caused in the system development, adoption, and evolution when the IT domain solution is imposed in this way. Tools such as DSLs and structured walkthroughs, along with deep architectural reviews and glossaries, are used to get everybody working on architecture, speaking the same language, and solving problems using the same concepts. This presentation deals with the domain structure, shows the problems of the forced domain anti-pattern, and offers tips, tricks and strategies to avoid getting a "pig in a poke."

Click here to download this presentation.

Organizational Design Thinking
Anthony Lattanze, Carnegie Mellon University

Many organizations invest in architecture training for engineers to prepare them for roles as systems and product designers. Despite hours of training, organizations often find it difficult to adopt sound organizational architectural practices.

Organizations are not only about "architecture;" they are also about value creation and delivering products to customers. In fast-moving, highly competitive markets, it is essential that organizations can respond with the right value proposition, at the right price point, at the right time. To achieve this, organizations need to create design synergy with management, marketing, and technical experts working together throughout the product life cycle.

One way to achieve synergy is to broadly adapt a discipline of "design thinking" rather than focus on technical architecture in isolation. In this presentation, I will discuss impediments to design thinking, and lessons learned based on experiences working with companies such as Sony, Samsung, and LG.

Click here to download this presentation.

How to Break a Mammoth Project into Bite-Size Pieces
Kevin Nguyen, Northrop Grumman
Esther Johnson, Northrop Grumman

A successful project requires a solid architecture, while a successful product line requires a solid, sustainable architecture. A good architecture requires the buy-in of all stakeholders and an allowance for different design steps, which would enable the design team to capture everyone's input in the design process.

The only way to achieve a solid, sustainable architecture is through understanding the customer's requirements. Design teams often play the "bring me a rock" game instead of working with their customers to understand the requirements before trying to break them down. This discussion covers the lifecycle of a project and provides key tips to help determine if you're bringing the correct rock to the table.

Our key focus areas are

• capturing customers' requirements
• systematically translating requirements into system of systems requirements
• transitioning requirements from systems to software engineers
• tracing requirements from womb to tomb
• accurately designing the intended system-based requirements

Click here to download this presentation.

Architecture, Agile Development, and Business Agility

Agile Architecture: What the Agile Architect Can Learn From a Hurricane Meteorologist
Eric Richardson, Chemical Abstracts Service

There are compelling analogies to be drawn between an architect in an Agile environment (AA) and a hurricane meteorologist (HM). This paper draws on these analogies to provide guidance for developing and maintaining an Agile architecture. Like HMs, who produce forecasts of various types, AAs produce a variety of architectural documents. HMs use many different kinds of data sources as inputs to forecasting, and AAs also need to gather diverse data types and employ different techniques to acquire them. Unlike the HM, who has well-established meteorological practices for preparing and scheduling forecasts, the AA has far fewer standard practices to follow, since Agile practices can differ drastically from those of traditional architecture. Still, this paper will cover several reliable methods for defining an Agile architecture plan and deciding on a schedule for its preparation and update. The approach presented will help the AA establish a successful long-term program.

Click here to download this presentation.

Covert Use of Architecture for Rapid, Agile Product Development
Robert J. Curry, Raytheon

Over the past few years, the term “architecture” has become somewhat tarnished in some circles due to early over-promising and under-delivering
of capabilities. Program managers have learned that having an architect or two around may result in numerous indecipherable diagrams and dense< terminology that seem to have no direct bearing on their need to develop a new product.

That said, the use of architecture perspectives in system design can provide real value to a program and is vital to the development of effective systems of even moderate complexity. The challenge for the architect is to recognize this situation and make the best of it. Through some examples, this presentation suggests how architecture principles can be used covertly in rapid development environments without the team being aware that they created an architecture description until the end of the project.

Click here to download this presentation.

Agile Product Line Architecture
Paul S. Clarke, Northrop Grumman

In this presentation, we discuss the challenges we have encountered in being agile in our airborne ISR (intelligence, surveillance, and reconnaissance) product line architecture, which includes millions of lines of code and over 100 kinds of hardware components. A product line enables reuse benefits, but inhibits green field innovation. However, we must be agile and innovative, and we discuss how we accomplish this goal.

We employ a modified Agile development practice for both software and hardware development and use technology roadmaps to plan for improvements and upgrades that create new business opportunities by extending the product line's capabilities. Through architecture changes, we have significantly reduced our products' costs, time to market, size, and weight while significantly increasing the performance, capabilities, and range of offerings of our products. In the presentation, we will discuss how we achieved these agilities and improvements.

Click here to download this presentation.

Low Ceremony Architecture
Jeromy Carriere, eBay, Inc.

Unfortunately, many agile, fast-moving companies have aggressively resisted or rejected the principles of "big-A" architecture, which is most notably characterized by EA frameworks, formal architectural documentation, centralized technical oversight, and top-down (or inside-out) standards setting and enforcement.

An "architectural" mindset will ensure that successful agile companies are able to scale to enjoy the benefits of their market positions and transition from startup to sustainable company. Unfortunately, therein lies the problem: how do you know when to invest in architecture? Except at enormous cost, you can't code in quality (maintainability, scalability, reliability) at a later time, but investing too much in these quality properties at the wrong time in a given lifecycle almost guarantees failure.

Click here to download this presentation.

Soft Skills for Architects

Next Generation Architects for a Harsh Business World: Sourcing Non-Traditional Talent and Revamping Existing Talent
Walter Ariel Risi, Pragma Consultores

Imagine a harsh business environment that contains two architects who are both alike in technical mastery. The first has a prestigious educational background but struggles through some unsatisfactory jobs, and finally lands as a senior developer in a small software shop. The second, a former drugstore clerk and skillful guitar player, jumps from a round-the-corner kiosk to become top architect for a multinational powerhouse. You may found the story familiar…and if not, you may want to look at your best architect's background!

This presentation goes through some of the softer "life skills" that non-traditional architect candidates exhibit that make them develop exceptional performance in short time. On one hand, we provide the audience with tools to recruit and develop non-traditional talent. On the other, we provide elements for traditional architects and managers to recognize and develop these skills, thus increasing performance and the chance of a rewarding career.

Click here to download this presentation.

Seven Habits of Highly Effective Architects
Ger Schoeber, Sioux Embedded Systems B.V.

Although a great deal of the architecting job of a successful architect deals with technology, the essence of the work is in the areas of process and business, but especially in communication.

Software architects typically have a software engineering background. They have a lot of practical expertise in software programming, as well as experience with a specific domain. But once they're specifically assigned as an architect, they suddenly find that they must focus on the non-technical aspects of a project.

Many of my activities are based on Steven Covey's principles from The Seven Habits of Highly Effective People. I use these seven principles as a foundation for my daily professional work, as well as in my private life. This presentation will show how the ever-busy role of an architect can be carried out in a highly effective and efficient way.

Click here to download this presentation.

Why Good Architects Act As Chameleons
Rik Farenhorst, DNV-CIBIT B.V.
Eelco Rommes, DNV-CIBIT B.V.

It is a common misunderstanding that the architect's major task to produce architectures—but the truth is that an architect should understand and change the behavior of the social system that actually produces the architecture. De Caluwé and Vermaak distinguish five ways of thinking about and reacting to change in organizations. Based on their theories, we have created a model that illustrates how architects can change their own "color" in order to provoke change in the organization. We map this color model to three different cases from our own experience as architecture consultants, analyze these cases, and share what we learned from our successes and mistakes. We claim that good architects should act as chameleons, and give recommendations on how to approach different kinds of stakeholders and how to deal with the various types of power, interests, needs, and conflicts that naturally arise in any organization.

Click here to download this presentation.

Themes for Architecture Success
William Koscho
William Ries

Our experience shows that simply establishing the structures and relationships of a system is not enough for architecture success; a few overarching themes must be present. There are published assessment frameworks, architecture maturity models, and other tools that discuss competencies and processes present in mature architecture organizations. This presentation supports such findings and describes the deeper cultural infrastructure underlying successful architecture initiatives. This cultural infrastructure is described in terms of four major themes: Sponsorship, Common Goals, Decision-Making Mindset, and Trust. We present these four themes, a tool for assessing where organizations may have gaps, and techniques for the architect to facilitate closing those gaps. These techniques are based on our experiences, but we plan to validate them through a survey of other practicing architects. This presentation applies to audiences in different architecture disciplines and at varying organizational levels; it also applies broadly to those in both change agent and management roles.

Click here to download this presentation.

Architect as Organizational Change Agent
Suzanne Miller, Software Engineering Institute

The architect of a software-intensive system is clearly known as a technical leader within the engineering team that he or she leads. What may be less obvious is that the architect also has the opportunity to be a leader of organizational change, in terms of the organizational acceptance of architecture as a discipline worthy of investing time, skills, and resources. The architect may also be the leader of organizational changes in software practices that complement good architecture practice.This presentation will highlight the dual role of the architect and provide some resources and approaches for embracing the role of an organizational change leader.

SOA and Cloud Computing

Architectural Implications of Cloud Computing
Grace Lewis, Software Engineering Institute

Cloud computing is being adopted by commercial, government, and DoD organizations and is driven by a need to reduce the operational cost of their information technology (IT) resources. From an engineering perspective, cloud computing is a distributed computing paradigm that focuses on providing a wide range of users with distributed access to virtualized hardware and/or software infrastructure over the Internet. From a business perspective, it is the availability of computing resources that are scalable and billed on a usage basis as opposed to acquired, which leads to potential cost savings in IT infrastructure.

From a software architecture perspective, what all this means is that some elements of the software system will be outside the organization and the control over these elements depends on technical aspects such as the provided resource interface to business aspects such as the service-level agreement (SLA) with the resource provider. Therefore, systems will have to be designed and architected to account for a lack of full control over important quality attributes. This presentation will briefly define cloud computing and the different types of cloud-computing environments, and point out drivers and barriers for cloud-computing adoption. It will then focus on examples of architecture and design decisions in the cloud, such as data location and synchronization, user authentication models, and multi-tenancy support.

Click here to download this presentation.

Guidance Models and Decision-Making Tooling for SOA, Cloud, and Outsourcing Solution Design
Olaf Zimmermann, IBM Research

This presentation provides an overview of completed and ongoing architectural knowledge management activities in an industrial setting. After a brief review of the concepts for architectural decision modeling with reuse as presented at SATURN 2010, we conduct an in-depth investigation of ten particularly relevant and recurring SOA design decisions, and outlines several decisions that must be made when a cloud-computing solution is designed. Furthermore, the presentation covers how we extended existing decision modeling concepts to target the designers of outsourcing solutions and introduces tooling options for working with the presented guidance models and for decision making. Finally, we outline directions for future work.

Click here to download this presentation.

Experimentation in the Use of Service Orientation in Resource-Constrained Environments
Joseph Seibel, Software Engineering Institute

Service orientation can reduce integration cost and enhance agility in response to changing situations. However, it has not been widely applied to support mobile users in ad hoc, wireless computing environments, which are common in tactical military situations. Such environments are impoverished in terms of computational (CPU and memory), energy (battery), and network (bandwidth) resources.

The goal of this work was to determine the feasibility of using off-the-shelf service-oriented architecture (SOA) technologies and smartphones in military tactical environments and to understand the tradeoffs that are necessary to implement a service-orientation solution in such an environment. An Android-based prototype was built to evaluate the tradeoffs between performance, security, and interoperability. The prototype is a situational-awareness display that receives track and video data from UAVs and other tactical assets using a SOAP-over-UDP web service. In this presentation, I will discuss the architectural tradeoffs and engineering decisions used to implement the solution.

Click here to download this presentation.

Dealing with the Complexities of a Global Service-Oriented Architecture
Tarmo Ploom, Credit Suisse
Claudio Jossen, Credit Suisse
Roberto Di Paolo, Credit Suisse

Local SOA-based IT landscapes have been a research focus for many years. However, current research does not adequately address the needs of global SOA-based IT landscapes. This presentation focuses on global SOA and on the complexity of global SOA-based IT landscapes.

To analyze global SOA-based IT landscapes, we use the concept of solution space, which represents all possible design solutions under given design rules. To measure the complexity of global SOA-based IT landscapes, we propose a new metric: maximum system variety. Maximum system variety shows the maximum cumulative component dependency that a system can achieve under given design rules.

Based on an example, we show how this metric can be used for selecting design rules for reducing system complexity. Identifying and combining such design rules are required for finding a viable setup for a global SOA-based IT landscape. We propose to combine these design rules in a decision tree.

Click here to download this presentation.

Architectural Knowledge Management

Using the Corporate Management System to Communicate Architecture Knowledge and Reduce Technical Debt
Harald Wiesenberg, Statoil ASA
Einar Landre, Statoil ASA

Architecture is not only for architects. For an architecture to be properly implemented, a variety of stakeholders must be informed about the architecture and its roadmap. At Statoil, we have used the corporate management system to reach out to architecture stakeholders, and in this session, we take a look at how this is done and the lessons we have learned from this process. We also take a look at future plans for improving the management system and how this influences architecture communication. Our key focus area for future improvements is based on personalization as well as how best to deliver the right content to the right recipient. Additionally, we also plan to look at how integration between the corporate management system and the architecture governance and communication can be improved.

Click here to download this presentation.

On-Demand Generation of Views to Support Online Evolution of Software Product Lines
Danny Weyns, DistriNet Labs, Katholieke Universiteit Leuven
Bartosz Michalik, DistriNet Labs, Katholieke Universiteit Leuven
Alexander Helleboogh, DistriNet Labs, Katholieke Universiteit Leuven
Nelis Boucke, DistriNet Labs, Katholieke Universiteit Leuven

It is difficult to achieve assured conformance between architecture and code. We lacked proper architecture descriptions in the context of the evolution of an industrial software product line of logistic systems. As a result, a lack of explicit architecture documentation about the deployed products led to ad hoc update practices, which were error prone and resulted in unnecessary and undesirable shutdowns. To tackle these problems, we have codified the architecture knowledge required for evolving products in a viewpoint. Based on this viewpoint, we developed a supporting tool that allows generating on-demand architecture models. These models guide maintainers by listing the concrete tasks they need to perform when upgrading a system and by showing inconsistencies when they fail to do so. The evaluation of 68 updates of industrial logistic systems demonstrates a significant improvement in the quality of system updates with respect to the correct execution of updates and a reduced interruption of services.

Click here to download this presentation.

Research in Architectural Practices

Collaborative Design with the Software Architecture Warehouse
Cesare Pautasso, University of Lugano
Marcin Nowak, University of Lugano

Designing a software architecture requires access to domain knowledge and experience, combined with the ability to make good decisions based on partial information. We present the Software Architecture Warehouse (SAW, http://saw.inf.unisi.ch/), a Web-based tool that supports distributed architecture design teams by managing their shared knowledge and enabling consensus-based decision making.

After introducing the extensible knowledge meta-model of SAW, we will present various scenarios of in-meeting design-dialogue mapping and discussion support, along with visual aids. We will demonstrate how SAW can be used to induce synergy effects between knowledge reuse and remote collaboration. We claim that giving immediate feedback to the whole design team about the implications and constraints of a design decision results in an improvement in the quality of decisions made.

Click here to download this presentation.

Towards Automation of Architectural Tactics Application: An Example With ArchE
Roger Champagne, ETS, Montreal, Canada
Sebastian Gagné, ETS, Montreal, Canada

This presentation describes a project where the goal was to add new capabilities to ArchE, an expert system developed at the SEI that automates some of the tasks an architect performs when elaborating software architectures. This new capability consists of the ability to automatically suggest and apply performance tactics to a software architecture model.

The main challenges that arose in this work consisted in mapping documented performance tactics to an automatable form, identifying rules to determine when a given tactic is applicable (based on various properties of the current software architecture), and identifying properties that can be assigned to architectural elements in order to support the automatic application of various tactics. The main contributions of this work are an actual implementation of some performance tactics in ArchE (including the rules mentioned above), and an improved overall design of tactics implementation in ArchE that is reusable in future ArchE extensions.

Click here to download this presentation.

Architecture Documentation for Agile Development
Sofia Sherman, Information Systems, University of Haifa
Irit Hadar, Information Systems, University of Haifa
Ethan Hadar, CTO Office, CA Technologies
Jay Harrison, CTO Office, CA Technologies

The growing use of Agile methodologies and the need to adjust them to enterprise products and complex systems' development have created a need to comply with the requirement of minimalism in Agile methods as well as the need for well-defined up-front architecture artifacts. The main concepts of Agile development are flexibility, minimalism, and collaboration. These are achieved by our proposed automatic Abstract Specification Tool for creating a short and focused architecture document. The tool is nimble and flexible to changes, bundled and integrated with a modeling tool, and supported by evolving checklists added by reviewers. This short and focused approach supports and fosters minimalism, a common language, and collaboration among stakeholders as well as focused, incremental architecture evolution steps. This presentation will provide information on the structure and value of the Lean documentation, include a demo of the tool that supports it, and will show the ease of use of the integrated design and documentation approach.

Click here to download this presentation.

Model-Driven Architecting

Design and Implementation of an Agile Price Management Platform for Banking
Thipor Kong, Credit Suisse
Ulrich Hildebrand, Credit Suisse

This practitioners' report describes Credit Suisse's new client-centric price management platform, with the aim of replacing over 20 disconnected legacy applications with an integrated solution. We plan to improve business agility and to enable new ways of creating, controlling, and governing prices across all the bank's businesses.

We have decided to employ the federated architecture pattern as an enabler for a stepwise inside-out renewal. This approach leads to a highly distributed platform, with customizable components for specific business needs. As a result, the platform is designed and managed as a software product line.

A software product line leverages reuse potential and helps to enforce required commonalities—but a product line also requires a dedicated design and management approach. We'll present our approach, which is based on model-driven engineering and domain-driven design, and will show how a clean separation and customizability of both domain-dependent and domain-independent aspects are supported.

Click here to download this presentation.

Using Architecture Models to Predict Software-Intensive Technology Interoperability Deficiencies
Kristin Giammarco, NPS Dept. of Systems Engineering, C4ISR & Network Modernization
Kimali Messado, CACI, C4ISR & Network Modernization

This presentation introduces the audience to a new approach for assessing interoperability using architecture model data, consistent with the principles of model-driven architecting. The following are key takeaways:

• An ambiguous requirement for interoperability can be formalized into measurable goals using a goal hierarchy.
• The necessary conditions for achieving interoperability goals can be expressed in terms of architecture model elements and relationships.
• These necessary conditions provide an unambiguous foundation for developing formal specifications to assess the interoperability of a design.
• Viewing the model as pairs of performers that need to interoperate aids in the stepwise refinement of the physical architecture and enables assessment of the necessary conditions for interoperability at every layer of the protocol stack.

This modeling technique was used by C4ISR & Network Modernization at a 2010 Integrated Capabilities Event to provide a better understanding of its deployed architecture and to improve its planning capability for future event architecture configurations.

Architecture-Centric Engineering

Using Architecture-Centric Engineering on a TSP Project
Luis Carballo, BMV
James McHale, Software Engineering Institute
Rod Nord, Software Engineering Institute

In summer 2009, the SEI began a project with Bursatec (the IT arm of the Mexican Stock Exchange) to replace their main online stock-trading engine. The project has aggressive goals for performance and delivery and must function flawlessly.

The SEI answer to this challenge was to blend two of its methodologies, architecture-centric engineering (ACE) and the Team Software Process (TSP). Those attending the presentation will learn how:

• Key concepts of the TSP framework, and a process structure for iterative development by self-directed teams, provide management early visibility into the team progress.
• ACE practices are combined with TSP to launch the architecture phase of a project, and can help guide and train junior architects throughout the phase.
• An architecture-centered approach provided early measures of quality. The combined approach offers help to organizations to set an architecture/developer team in motion using mature, disciplined engineering practices that produce quality software quickly.
  

Click here to download this presentation.

Capability Maturity Model Integration V1.3 and Architecture-Centric Engineering
Lawrence G. Jones, Software Engineering Institute
Michael Konrad, Software Engineering Institute

Capability Maturity Model Integration (CMMI) is a process improvement approach that provides the essential elements of effective processes that ultimately improve organizational performance. It is estimated that over 1,200,000 people worldwide work in organizations that have conducted process appraisals using CMMI.

Early versions of the CMMI paid little attention to architecture, agility, product lines, and other modern engineering practices. A significant change to the CMMI V1.3 models (released in November 2010) is the new emphasis on the role of architecture in the design process. This presentation will address the basics of architecture-centric engineering and show where and how these practices are now reflected in the CMMI models.

Topics will include

• process improvement and CMMI
• structure of the CMMI models
• essential architecture-centric engineering practices
• architecture-centric engineering practices in CMMI V1.3
• additional modern engineering practices in CMMI V1.3

Click here to download this presentation.

Evaluating a Partial Architecture in a ULS Context
Len Bass, Software Engineering Institute
James Ivers, Software Engineering Institute
Rick Kazman, Software Engineering Institute
Gabriel A. Moreno, Software Engineering Institute

Architecture evaluation has been well established in industrial practice for over a decade, but one assumption that all evaluation methods have made is that there is an architecture to evaluate. In ultra-large-scale (ULS) systems, the architecture may not yet exist for portions of the system or there may be competing architectures for the same functionality in different portions of the system.

We describe an application of the principles underlying traditional architectural evaluation methods to the problem of analyzing an architecture landscape: a broad set of architectural decisions representing a spectrum of potential architectures. Why would we want to analyze an architecture landscape, rather than a concrete architecture? We are motivated to do this when there are many architectural decisions to be made, many stakeholders, and many systems to be built, and when the architectural decisions are non-trivial with far-reaching consequences. Smart Grid demand-response systems are examples of such landscapes.

Click here to download this presentation.

Mission Thread Workshops: Lessons Learned in End-to-End Capability and Quality Attribute Specification for SoS Architecture Development
Mike Gagliardi, Software Engineering Institute
Bill Wood, Software Engineering Institute
Tim Morrow, Software Engineering Institute

In this presentation, we discuss lessons learned from using mission thread workshops (MTW) as an early architecture development step for a number of DoD systems of systems (SoS). The approach is based on defining a number of critical warfare vignettes, then developing some associated end-to-end mission threads that stress the envisioned capabilities of the SoS, and finally, augmenting these threads with quality attribute and capability considerations elicited from the SoS and system stakeholders in a facilitated workshop. The MTW explores these threads with the stakeholders in a number of half-day or full-day sessions to determine gaps in the functional and non-functional capabilities (e.g., performance, availability, usability, security) at each step. Architectural challenges are then derived from the resulting augmented threads, and these can be used to drive follow-on efforts, such as building the DoDAF views and products. We will also discuss integrating this type of approach into a program's architecting process and acquisition plan.

Click here to download this presentation.