Friday, 8 November 10:30-12:00 Exhibit Hall 4B
Practitioner Reports: Architecture Experiences
Chair: Lougie Anderson
Designing a Web Services Project for Maximum Value: The 90 Day Challenge
The 90 Day Challenge team set out to deliver an end-to-end Web services solution to enterprise sales agents in 90 days, with immediate plans to extend the solution to other user groups. In order to meet their commitments, the team would have to reuse the same component Web services in multiple contexts. By modeling the workflows and carefully managing scope at the component level, the team developed a suite of Web services that other teams could easily incorporated into multiple projects. As a result, three other programs to date have incorporated Web services from the 90 Day Challenge, saving weeks of development time.
Migrating Legacy Engineering Applications to Java
The Boeing Company, like many other engineering-centric companies, has a large base of legacy applications written in FORTRAN and C. In today's computing environment, maintaining and evolving these applications is becoming difficult. One such Boeing application, the Aero Grid and Paneling System (AGPS), is a 3D-geometry surface modeling tool. In the fall of 2001 we completed the migration of the AGPS source code from 300,000 lines of mixed C and FORTRAN to 150,000 lines of 100% Java. The migration resulted in many benefits; some anticipated and some unexpected. The benefits include widespread portability of AGPS on engineering workstations and PC-class machines, allowing AGPS to embrace many modern programming capabilities readily available in Java, greatly improving the maintainability and enhanceability of the AGPS source code, and an increased robustness of the AGPS code. During the migration we also took the opportunity to rearchitect major areas of the code using object-oriented techniques, to modernize the graphical user interface, and to implement a significant number of pending enhancements from our backlog.
This report looks into the details of the AGPS migration to Java, discussing our observations, lessons learned, migration techniques, and what we see in the future computing environment. Data are presented and discussed to substantiate our conclusions that Java is well-suited for compute-intensive engineering applications, Java portability is a reality, Java performance is no longer a problem, and that embracing object-oriented programming techniques produces a much superior product with less effort.
Defining and Growing a Scientific Analysis Software Architecture
The computing employed in oil and gas exploration is predominately scientific, resulting in a variety of data analysis applications. Although the analytical domains vary greatly (e.g., seismic processing, geologic modeling, engineering facilities design, etc.), the requirements that shape their software architectures are similar. Such analysis systems are rarely illustrated in the software analysis/design and architecture literature.
We describe a product line software architecture, SALSA (Scientific Analysis System Layers Architecture), developed at ExxonMobil's Upstream Technical Computing Organization. Key forces that led to the SALSA include the data analysis process itself, the need to access data stored in a variety of formats, integrating our analysis tools with third party tools, and isolating our codes from external changes. Although derived from Layers software architectures described in the literature, we have elaborated SALSA to identify objects within each layer specific to an architecture focused on analysis
SALSA is a product of a software development cultural change instituted over the past few years at ExxonMobil. We adopted a vision of "architecture-centric" software development. This vision, supported at the upper management and grassroots levels, began with a software architecture team to steward our architectures; and a career development program including OOAD training for all developers and a biweekly "School of the Architects" seminar series. Thus far, the results include a way of thinking about our main product, captured in SALSA; several product-line architectures based on SALSA; a beginning of an architecture-centric reuse effort, also based on SALSA; and a visible change in the way we view and approach software development.