Minneapolis, Minnesota

Past Conferences: SATURN 2012

In 2012, the SEI Architecture Technology User Network (SATURN) Conference celebrated its 8th year. What began as a small gathering of practitioners and SEI technical staff members has grown to an international conference that attracts researchers, practitioners, and industry experts.

As projects continue to grow in scale and complexity, effective collaboration across geographical, cultural, and technical boundaries is increasingly prevalent and essential to system success. SATURN 2012 explored the theme of "Architecture: Catalyst for Collaboration." SATURN 2012 included presentations, courses, and tutorials on

collaboration in software development, for example, architecture in an Agile project

collaboration in the context of mobile computing, cloud computing, social networking, open frameworks, and service-oriented architecture

knowledge management for effective collaboration

systems of systems and ultra-large-scale systems: how to achieve collaboration across independently funded and managed organizations

multi-agent systems and collaboration among non-human entities such as software and networks

Evening Session: Architecture-Centric Acquisition

Software plays a critical role in most system acquisitions and is often cited as the reason for cost overruns, schedule slippages, and quality problems. An architecture-centric acquisition approach has proven to be an effective way of reducing acquisition risk. This presentation will cover the why, when, where, how, and what of architecture-centric acquisition for both government acquirers and commercial suppliers.

Conference Session: Architecture and Agile I

Agile software development methodologies focus on small iterations, resulting in incremental delivery of working software to the customer. The immediate concerns that arise are: How do we establish the architecture for a system? Do we begin development without a stable architecture in place? Or should we have a few iterations to get the architecture and design in place and then begin development?

This session will introduce participants to the Agile principles for architecture: iterative, incremental, and driven by stories. Some of the key aspects that will be illustrated are the role of architects in Agile projects, team involvement, architecture envisioning, identifying desired architectural qualities without committing to any specific architecture, implementing one story and establishing the highest priority architectural features with the help of the story, creating an application framework, and incrementally evolving the architecture across iterations with the help of real stories being implemented.

Agile teams that value working software over comprehensive documentation and believe that the best designs emerge from self-organizing teams need lightweight architecture-description techniques. Many of these teams rely on informal software architecture descriptions passed from developer to developer much like an oral history is passed from generation to generation. While an architecture oral history is critical to any team's success, ad hoc descriptions tend to overlook the importance of system properties.

During this session, I will share examples from my experience and show how to create a meaningful architecture oral history using two systematic yet lightweight techniques that facilitate collaboration and help establish a meaningful architecture narrative. The architecture haiku describes a system's architecture in a single page using concise, descriptive language. The refreshed system metaphor provides teams with guidance for describing a system's architecture using their own terms.

The trends of outsourcing software development and introducing Agile practices are not new. However, there is a growing emphasis on combining outsourcing with Agile to achieve greater total combined benefits. This fusion of benefits has the potential for major productivity gains in both commercial and government enterprises; however, if the acquisition model is not also transformed to be agile, the compound risks can overwhelm the benefits.

Agile software architecture practices are the pivotal element in transforming traditional acquisition into holistic Agile outsourcing. Architecture frameworks, reference models, and abstract release plans provide the necessary input to Agile contracting activities to define a clear vision, goals, and release cadence while allowing the flexibility in scope to realize the benefits of Agile and maintain an acceptable balance of risk. The resulting collaboration interface between client and supplier drives Agile practices.

This presentation will draw on current Agile enterprise-transformation efforts underway at various Hewlett-Packard clients in the commercial and government sectors to illustrate Agile outsourcing scenarios and degrees of agility introduced into an outsourcing enterprise.

Conference Session: Architecture and Collaboration I

We will share our experience in applying software architecture as the "glue" used to organize multiple Agile teams in building a single software product, InterDigital's Smart Access Manager. At the start, the Smart Access Manager's scope was small enough for a single Scrum team. Even at this stage, we used a shared architectural description to maintain collaboration within the single Scrum team. As development progressed, our product scope increased rapidly (features, quality attributes, etc.). To address this scope increase, we expanded our team, now five Scrum teams. A shared architecture description, serving as the guiding blueprint, has been a key in organizing and managing these teams. It has been essential in facilitating collaboration within and between the teams.

Our primary learning objective for the presentation is to share our experience in using software architecture as a key communication tool in transitioning a small single-team Agile project into a larger development program.

Multiple Views of System Specifications: Connecting a Distributed ProjectRobert Schwanke, Siemens Corporate Research

This talk is based on a project that used a system-specifications model to facilitate communication among its marketing, system architecture, and development groups. The project was distributed across two large and three small development sites on both sides of the Atlantic. Although these sites had collaborated before, there were substantial differences in their requirements-related practices and in their national and corporate cultures.

I used a rigorous, hierarchical specification model to elicit details and corrections from subject-matter experts in all three groups. As the model accumulated marketing, architectural, and implementation information, it became too large for any one stakeholder to review. Instead, we classified each specification according to which stakeholder groups were interested in it. The rigorous hierarchy of the model was invaluable for organizing, reorganizing, and classifying the specifications and continues to make it easy to maintain.

This talk will present the modeling tool (Enterprise Architect), the modeling method, the viewpoints, examples drawn from the project, and other hints and lessons learned.

Context-aware mobile applications can sense and respond to changes in environment or context. An example is a location-based application that uses GPS coordinates to define the information displayed to mobile users based on their current location. Our work focuses on the integration of an individual's context with that of nearby individuals operating as part of a group or unit, such as in the military or first-responder situations. This integrated context can then be used to enhance the precision of information provided to users and give a more complete picture of the status of a mission. Given the early stages of the research process when there are many unknowns, we defined extensibility as the main architectural driver.

This work has provided the ability to leverage the architecture to support collaboration. By identifying extensibility scenarios early in the design process, we were able to construct an architecture that supports multi-organizational collaboration to construct and evaluate different pieces of the architecture: context data models, context sources such as sensors, context reasoning engines and rules, and context visualization activities. This has allowed us to reach out to researchers from multiple universities and industry, resulting in synergistic research and development furthering the goals of all participants.

Studies on the life cycle of software-intensive systems conclude that the effort spent on maintenance can amount to 80% of the costs. People developing and maintaining such systems are confronted with a massive amount of information. Developers need to understand how the code to be changed relates to other features or bug fixes. Architects are interested in architecturally relevant changes only. Project stakeholders need to know the hot spots of frequent changes.

Currently, different versions of artifacts are compared at the code level only. Architecture or code-analysis tools evaluate and compare the quality of a software system at different points in time. The approach to be presented here focuses on the incremental or aggregated changes of the software over time. Changes are automatically resolved on structural levels such as architecture, design, and code. Architectural changes consist of added, removed, or changed components and changes of their dependencies. A component implementation is related to changes on the design-construct level, and these are categorized according to additional criteria such as being renamed or moved. Similarities are recognized over different design-construct versions.

When specifying a requirement or bug-tracking identification with configuration management check-ins, changes are also automatically related to requirements or bug fixes. This presentation will describe how impact analysis is supported by resolving all past changes attributable to a specific requirement starting with the last change to the code to be modified at the moment. Hints about how often a certain design construct has changed in combination with another design construct in the past indicate potential implications when modifying this design construct anew.

The complexity of modern science and engineering is daunting in terms of the complexity of analysis and processing, and volumes of distributed, heterogeneous data that must be managed. The cost of creating the software systems to support and manage these large-scale endeavors is significant, and historically most tools have been custom built and tailored specifically to particular scientific and engineering problems.

This talk will describe the architecture-driven approach we have successfully employed at PNNL to build core technologies that are broadly applicable across scientific and engineering disciplines. We rely heavily on leveraging robust, widely adopted open-source technologies and integrating them in novel ways through flexible software architectures. This creates functional, flexible systems at considerably lower costs than custom-designed technologies. We illustrate this approach by describing our Velo knowledge-management system, which highlights our "build systems, not code" mantra.

Conference Sessions: Architecture and Agile II

In this presentation, we share our experiences at John Deere in scaling Agile development with respect to factors such as system complexity, team size, and the degree of global distribution of developers.

We elaborate on short- and long-term effects that a paradigm shift to Agile software development exhibited and how the scaling factors influenced the respective transitioning strategies to be followed. We highlight philosophical, technical, and managerial mismatches that can cause tensions between Agile developers and software architects and report on the effectiveness of solution ideas for leveraging the best of upfront design and agility to overcome these issues.

Besides the central message of this presentation—that architecture plays a pivotal role as a communication facilitator and enabler—we show potential pitfalls and remedies of migrating to architecture-centric Agile software development.

Software architecture has a significant influence on the structural and nonfunctional quality of a software product. Ensuring success, teams employ architecture review by experienced architects, peers, and technical advisors. Agile teams practice rapid delivery and frequent sprints. In such conditions, thorough reviews are impractical because of logistics, peer reviewers' availability, and practitioners' reservations about what they perceive as an imposed organizational "analysis paralysis."

In SATURN 2011, we presented an abstract architecture specification (AAS) tool for Agile architecture documentation. In this presentation, we will present our practitioners' flexible manifestations of architecture review employed in the past year for supporting review in Agile development methodologies, with the AAS as one of its main inputs.

What Agile Architects Do and What They NeedViktor Clerc, InspearitRik Farenhorst, InspearitDaan Kalmeijer, Inspearit

Architecting in today's world requires omniscient architects: technically capable, communicative, collaborative, adaptive, and stakeholder aware across time and space. Luckily, architects are supported by a myriad of tools and techniques such as TOGAF and the availability of reference architectures, architecture principles, standards, and guidelines. Yet the key success factor remains the architect's agility: his or her soft skills and attitude while adapting to the often-changing business requirements of the stakeholders involved.

In this presentation, we will report on the architecting discipline in the Netherlands based on our experience supporting architecture-intensive organizations in various industries. Based on these experiences, we will summarize dos and don'ts for architects and demonstrate several pragmatic techniques that together form a lightweight but effective toolkit to help architects become more agile, that is, more adaptive to contexts and challenges.

Conference Session: Certification and Culture

This presentation will reveal the essential elements of the Lockheed Martin (LM) Architect Certification program, including its evolution since it began in 1992. I will discuss the four core components that LM views as essential to a software architect's career development and their qualification to perform on LM's largest programs. Finally, I will discuss implementation details as practiced in a widely diverse organization that spans many business units, technical domains, and leadership roles.

100 People and a Great Idea: Culture and Architecture for Corporate StartupsJeromy Carriere, X.commerce/eBay, Inc.

An extraordinary effort is underway at eBay, Inc.: the development of a platform to extend the reach of eBay's capabilities—the marketplace, PayPal, Milo, Where.com—to more merchants, while simultaneously delivering a truly open, standards-based platform to allow third-party developers to bring new capabilities into a "commerce ecosystem." This effort, known as X.commerce, is being executed as a startup-like business unit within the eBay, Inc. organization. However, characteristics typical of startups, such as a dynamic business strategy and volatile product requirements, are not easily accepted by a culture accustomed to rigorous and regular project and product-release cycles.

In this presentation, I will discuss the unique challenges and opportunities presented by incubating a startup-like culture and largely greenfield development effort within an established public company.

Eight years ago, Raytheon established its worldwide architect certification program with a focus on standards-based systems and enterprise architecture training. This year a new training program was developed for software architecture, leveraging both SEI and Raytheon-developed software architecture courses. But architecture-competence growth cannot focus exclusively on training—our organization's goal is to establish a global community of architect practitioners to share best practices, lessons learned, patterns, strategies, styles, and heuristics. Common training sets a foundation to facilitate collaboration, but other mechanisms such as social networking, repositories, symposia, and webcasts are also needed to cultivate this community of practice.

This presentation will examine the dynamics of collaboration by architects and how we have focused on enhancing these skills as part of our training program. We will discuss our collaborative training approach, feedback that we have received from our students, and relevant lessons learned.

Conference Sessions: Architecture and Process

A reference architecture is a complex and high-risk artifact. It is essential to the successful definition and management of a set of architectures that share common attributes and assets. You simply cannot afford to get it wrong, but there are few techniques that have been specifically aimed at defining reference architectures. We have developed a mashup of existing techniques that supports an architecture team in organizing the inputs required to create a robust reference architecture. This mashup takes advantage of several proven, widely used architecture methods. This approach allows the architecture-definition team to incrementally define the appropriate abstractions and patterns and to organize the information so that it is accessible and actionable.

The resulting technique has been applied to a large development effort aimed at creating a family of embedded computing architectures and applications for the DoD. The mashup is proving to be effective at focusing the team and giving them practical and proven tools for coordinating their work and making meaningful progress.

Managing software-development-intensive projects is often a daunting task, and even with software reuse there is a high level of risk involved. To be sustainable, software products need a documented architecture, test cases written up front and updated as the project evolves, software that is written in adherence to the architecture, and software and systems tests that pass repeatedly before product release. Agile teams are forming throughout industry, as well as around Northrop Grumman, and one of the biggest challenges most Agile teams have is in managing the workload. Scrum is good, but projects often find that they are either leaving their architecture behind in order to jump into the software development feet first, or they have no idea how much they have left to do and often fail their sprints.

This presentation will cover how our projects have successfully employed Kanban to manage Agile architecture and software development.

The SEI recently worked with Bursatec, the IT arm of the Mexican stock exchange, to help build an enhanced online financial trading engine. The end product had aggressive goals for performance and delivery, and it had to function flawlessly. Factors complicating a solution included scope outside the organization's recent experience, combining key technologies in new ways, and a constant stream of new requirements–challenges familiar to many in industry.

To manage these challenges while instilling disciplined but nimble engineering practices, the SEI employed its Team Software Process with architecture-centric engineering to set an integrated architecture/developer team in motion. The blend of technical, process, and project-management discipline was used to systematically address technical risk. This collaborative approach offers help to organizations to set an architecture/developer team in motion using mature, disciplined engineering practices that produce quality software quickly.

Conference Sessions: Architecture and Collaboration II

Thursday, May 10, 201210:30 AM – 12:30 PM

Use of Collaborative Agents and Autonomous Systems Within the Oil and Gas IndustryEinar Landre, StatoilHarald Wesenberg, Statoil

Over the past few years, Statoil has explored how multi-agent designs, platforms, and autonomous-system capabilities can be used to improve core upstream oil and gas business processes. Our hypothesis is that autonomous-system properties such as collaboration and negotiation can be used to improve human decision making and thereby enhance both operational efficiency and safety.

To most of us, an autonomous system in line with Stanley Kubrick's HAL 9000 from 2001: A Space Odyssey is unacceptable. Therefore, an overarching principle in an architecture is that the human operator must be in control and that the system should be regarded as a useful servant. To support this, we have developed an architecture whose bearing concepts are variable and delegated autonomy. In this presentation, we will discuss the principles, experiences, and challenges encountered with this architecture.

Based on initial work for the National Maritime Domain Awareness (MDA) Enterprise Architecture, this presentation will describe an approach intended to help prioritize system descriptions within a U.S. Federal interagency information-sharing effort.

The central concept is a novel category set for the systems depicted in an enterprise architecture that highlights the highest priority messages and information exchanges. It establishes an approach for developing system services from existing authoritative data sources and system functions.

Definitions are provided for system categories for sensors; monitoring systems; collection source systems; authoritative data-system fusion nodes; discovery, analysis, and dissemination systems; first-responder systems; and responder-action systems. Similar categories can be developed for business information systems, so examples will be provided.

The resulting analysis of the system categories and the messages can be used to develop or cross-check the process and data models, as a comprehensive way of achieving consistent iterations of integrated enterprise architectures.

In response to the maintenance problem—the delta between the knowledge on hand and the knowledge required—many system maintainers have self organized into a collaborative community to bridge this knowledge gap. There is evidence that this community of maintainers is succeeding.

Our research examines a community of about 1000 system maintainers that includes stakeholders from every aspect of the software life cycle. These members generate community-sourced knowledge to address the maintenance problem. This multidisciplinary research provides insight into the behavior of practitioners who operate in a dynamic and often unorganized post-development environment. We also describe the ethnography of the group and patterns of behavior that emerge through the collaboration process and detail how information and knowledge are validated. From the coalescing of the discoveries, we develop benchmarks of performance for collaboration and knowledge sharing for the system-maintenance domain.

Conference Sessions: Facilitated Architecture Techniques

Thursday, May 10, 201210:30 AM – 12:30 PM

Reflecting Stakeholder Perspectives in Architecture ReviewsSimon Field, Emirates Group & University of Glamorgan Business School

This presentation will describe the output of a research project that has explored the relationship between evaluation methods in the domains of software systems and service design. The results of this research, which build on the collaborative and inclusive nature of the Architecture Tradeoff Analysis Method (ATAM), are now being adopted for software architecture reviews in Emirates Group IT.

The presentation will draw on recent example architecture reviews to demonstrate the incorporation of a risk model so that tradeoffs are analyzed in terms of risk; the adoption and incorporation of a stakeholder model so that tradeoffs among stakeholder groups can be analyzed in addition to tradeoffs among quality characteristics; and the adoption of an industry-standard quality model, enabling wider comparison of architecture reviews between projects.

The author gratefully acknowledges the sponsorship of Public Service Management Wales and the Office for National Statistics, which has facilitated this research.

This work presents a real experience using architectural methods, techniques, and concepts to help a customer decide the way to evolve its solution architecture. The current architecture's solution processes an exceptional number of daily online financial transactions throughout Argentina and abroad.

The main motivation to evolve the current solution is that the product supporting the operation will be obsolete in less than five years. The presentation will cover how the software architecture's concepts, techniques, and methods were used to build a robust and well-justified reference architecture, considering not only technical issues but also business strategic issues.

This SOA reference architecture includes not only the architecture but also the life cycle suggested and the main patterns to achieve the strategic objectives established by the drivers. The presentation shows the strategy, the processes, the activities, and the learned lessons to define the SOA reference architecture in alignment with the organization's business objectives.

In this presentation, we will 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. Each MTW results in a set of challenges being developed during the follow-on activity.

We have reviewed and organized the challenges from 46 of these mission threads and found a surprisingly consistent overlap of the challenges developed, which are usability/automation, capability gaps, resource management, training, migration of legacy systems, and collaboration. The presentation will describe each of these general challenges in detail.

Many elements of formal software architecture evaluation approaches (e.g., ATAM and SAAM) have found their way into industrial practice–for example, using quality scenarios for writing high-quality requirements and prioritizing quality attributes using the utility tree. However, commercial industry has been slow to adopt these methods in their entirety because of perceived cost and effort. We have repeatedly witnessed real-world situations in which industrial architects facing tight schedule time boxes or budget constraints are precluded from using these methods. As a result, they often fall back to informal "evaluations" based on their judgment and experience. Even though they may use a few elements from formal methods, these lightweight evaluations are generally undertaken in an ad hoc manner.

We have developed a framework providing industry-friendly structure and guidance for tailoring lightweight architectural evaluations that work within common business constraints. This presentation describes the methodology and its pros and cons, and concludes with the results and lessons learned from the industrial pilot in which it was applied.

Conference Session: Large Scale

Thursday, May 10, 201210:30 AM – 12:30 PM

Software Architecture for Large/Critical ApplicationsVinay Krishna, CegedimAnirban Basu, East Point College of Engineering and Technology

Software architecture provides a blueprint for developing a system and plays a vital role in addressing quality-related aspects such as performance, security, and scalability. The architecture of a software system has to ensure that design is able to support all requirements as well as support any changes requested by the customer.

A common belief is that for a large and critical application, architecture needs to be planned well in advance to adequately meet all functional and nonfunctional requirements. This presentation will stress the need for agility in architecture and design for large/critical applications. It will examine the role of software architecture and design on failures of past software projects and why plan-driven architecture and design were not able to adapt to changes easily but rather introduced unnecessary complexity in the system. We will propose a strategic and goal-oriented approach that systematically combines evolutionary design with plan-driven development.

In recent decades, reuse has been the holy grail of software engineering. Nearly every organization is searching for an effective way of achieving software reuse, but few succeed.

Today, service-oriented architecture (SOA) and product line engineering (PLE) are among the most promising and popular approaches to achieving reuse. However, these approaches are seldom used together. The European research project INDENICA seeks to develop approaches to use and adapt PLE for the SOA world. This presentation will give an overview of the INDENICA approaches developed so far and early results from the first case studies.

Assessing Open-Architecture Systems for Naval UseNickolas Guertin, US NavyAdam Porter, University of MarylandBrian Womble, US NavyDouglas C. Schmidt, Vanderbilt University

The goal of employing open-architecture systems for Naval use is to foster competition and innovation to improve performance and affordability through the use of modular designs. At the heart of open-architecture systems are architectural concepts, services, and tools that are maturing as standards-based, commercial off-the-shelf (COTS) frameworks; component-based and service-oriented middleware; and model-driven engineering technologies.

Despite substantial advances in these technologies during the past decade, however, key challenges must be addressed before we can affordably and dependably build next-generation open-architecture systems. This talk will therefore provide a survey of key characteristics that make architectures "open"; examine the evolution of standards and enabling technologies that are relevant for open architectures; summarize new challenges for open-architecture systems arising from growth of scale, complexity, and expanded threat spectrum; and evaluate strategies for overcoming these challenges as well as limitations with existing open-architecture efforts. Examples from the shipboard computing domain will be used to illustrate key points.

NASA's emphasis on enabling the commercial launch industry has placed the John C. Stennis Space Center (SSC) near Waveland, Mississippi as well as other rocket propulsion testing (RPT) sites in unique positions to provide testing services to multiple commercial RPT customers. To provide these services to industry in a marketable and cost-effective manner, NASA's Rocket Propulsion Test Management Board (RPTMB) has determined that the software that operates the RPT's data-acquisition systems (DAS) at each of its testing sites should be common to each facility regardless of location and the underlying hardware. In addition, the RPTMB also understands the importance of the government maintaining full ownership and modification rights to the intellectual property of such an undertaking in order for commercial entities to be guaranteed the privacy of their data. Therefore, the RPT initiated an effort to develop such a software suite for the RPT's facilities during the fall of 2010, beginning with an effort to develop requirements for this software suite. This presentation will address the nature of this ground software-development effort and how to achieve collaboration across independently funded and managed organizations.

Conference Sessions: Architect Skills

Thursday, May 10, 20122:30 PM – 4:00 PM

Mythology for ArchitectsArjen Uittenbogaard, Inspearit

The ancient Greek myths about what may have been the first architect of mankind, Daedalus; the biblical story on the effort of building the Tower of Babel; and even fairy tales like "The Three Little Pigs" contain a lot of wisdom that cannot be expressed in UML or BPMN diagrams. If an architect's job is to realize systems that add value, his or her work is not limited to handling hard, technical information. An architect has to communicate, enthuse, and convince, and in the process deal with the emotions and political games this evokes.

Since the dawn of humankind, stories have been the means to deal with these types of complexity. An architect has to be a storyteller. He or she has to be able to find or create the right stories and to tell them effectively. In this presentation, I will tell a story or two about the power of stories for architects. Audience members will go away knowing the value of stories for sensemaking, collaboration, and communication in architecting work.

Anthropology provides a set of tools that can be applied to any social setting, including business and technology. Since architects often assume the role of leading discussions between their business and technology partners with different (sub)cultures, they need to understand those elements of culture that drive or impede cross-cultural collaboration.

In this presentation, I will discuss the elements of culture that the architect can observe in order to understand his business partners' culture(s) better, how to gain a better understanding of the culture through participant observation, and how to effectively leverage cultural knowledge to foster collaboration within and among groups.

In light of the size of current software projects, good project leadership is essential to a project's success. The role of project leader frequently falls to software architects, yet architects are often not trained in leadership or—even worse—are not aware of their roles as leaders. The following leadership strategies are frequently pivotal to a team's success. If neglected, they often lead to a project's demise; if followed, they often help projects succeed:

Convey the significance of the project and task at hand. Attitude can make or break a project.

Delegate ownership and recognize accomplishments. Empowering team members enables collaboration.

Create personal connections to manage politics. Manage the stickier side of architecture.

In this presentation, I will describe several concrete strategies that an architect can follow to achieve on-time and under-budget delivery of the system and illustrate the impact on projects with several concrete examples of success and failure.

Conference Sessions: Enterprise Architecture

Thursday, May 10, 20122:30 PM – 4:00 PM

Establishing Enterprise Security and a Risk Management Program in an Agile Software Development OrganizationSrini Penchikala, InfoQ

In this session, I will discuss the details of a security-management program that we established in our organization to build security and risk management aspects into all phases of the product-development life cycle. As part of this new program, we defined an agile, iterative, and repeatable security-architecture process that included touchpoints with security architecture and software-development processes at all levels of the Agile projects (feature, sprint, release, project, and product levels).

I will talk about the security-architecture assessments introduced to perform a high-level risk assessment of all the new products and services. I will also cover the security-architecture elements such as architecture framework components in the areas of security architecture, design, architecture governance, standards, identity and access management, system and information integrity, and security-information event management.

With the confluence of complex enterprise-class systems, requirements for high quality and minimal total cost of ownership, and faster development time, the need for an efficient and effective architectural approach became evident. The key component of this new approach is application of large-scale integration and use of service-based technology.

Integration is a key demand for the CVS Caremark enterprise due to increasing requirements for efficiency, responsiveness, and cost reduction. This talk will be about our experience at the CVS Caremark Corporation building large-scale distributed and high-performance systems.

Currently, the companies participating in the oil and gas industry are faced with challenges posed by dynamic changes such as fluctuating cash flows, shortage of qualified people, and strict laws demanding safer processes and systems. According to Zachman, it is possible to move an organization toward its business goals only by understanding its complexity. However, the IT domain has traditionally and systematically acquired and installed best-of-class technology before understanding how to connect the essential information capabilities of the organization to their installed processes and technology. This is a risk that that these organizations can no longer afford.

To avoid this risk, Ecopetrol has designed and implemented the ECO-MAPS approach, which consists of an enterprise conceptual model, an enterprise-modeling methodology, and its tool. With this approach, the driver for making decisions is the explicit identification of information that adds value to the business processes. In practice this has changed the paradigm in Ecopetrol from "technology first, information last" to "information of high quality first, technology last." This presentation will provide insights about the approach, the quality of the information-measurement program, and the current results of the implementation.