Last week, we posted a link here to an article at the SEI blog about how Bursatec, the technology arm of Groupo Bolsa Mexicana de Valores (BMV, the Mexican Stock Exchange), used architecture-centric engineering to respond to its challenges.
Part two of this article was posted today: Using Team Software Process (TSP) to Architect a New Trading System, by James McHale.
Posted in Architecture-Centric Engineering, Architecture-Centric Practices, Quality Attribute Analysis
Tagged ADD, architecture evaluation, architecture review, Architecture Tradeoff Analysis Method, ATAM, attribute-driven design, non-functional requirements, SEI, software architecture, software architecture evaluation, software architecture requirements, software architecture review, software design, software development, software engineering, Software Engineering Institute
Bursatec, the technology arm of Groupo Bolsa Mexicana de Valores (BMV, the Mexican Stock Exchange), recently embarked on a project to replace three existing trading engines with one system developed in house. Given the competitiveness of global financial markets and recent interest in Latin American economies, Bursatec needed a reliable and fast new system that could work ceaselessly throughout the day and handle sharp fluctuations in trading volume. To meet these demands, the SEI suggested combining elements of its Architecture Centric Engineering (ACE) method, which requires effective use of software architecture to guide system development, with its Team Software Process (TSP), which teaches software developers the skills they need to make and track plans and produce high-quality products. This post at the SEI blog by Felix Bachmann—the first in a two-part series—provides a case study of how Bursatec used architecture-centric engineering to respond to its challenges.
Posted in Architecture-Centric Engineering, Architecture-Centric Practices, Quality Attribute Analysis
Tagged ADD, architecture evaluation, architecture review, Architecture Tradeoff Analysis Method, ATAM, attribute-driven design, non-functional requirements, SEI, software architecture, software architecture evaluation, software architecture requirements, software architecture review, software design, software development, software engineering, Software Engineering Institute
We learned an important lesson recently about breaking down barriers between architects and developers when we were challenged to deliver the architecture in smaller increments and shorter iterations.
In winter 2009/2010 we had the opportunity to participate in a project with Bursatec, the IT arm of La Bolsa Mexicana de Valores (the Mexican Stock Exchange), to replace its main online stock trading engine with one that would also incorporate trading of other financial instruments such as options and futures. The project had aggressive goals for performance and delivery, and as the face of Mexico’s financial markets to the world, the new trading engine needed to function flawlessly.
The primary purpose of the architecture for a software-reliant system is to satisfy the driving behavioral and quality attribute requirements. Quality attribute requirements tend to be poorly captured and poorly represented in requirements specifications, which focus on functionality. It is often up to the architect’s own initiative to capture the actual quality attribute requirements for a system under development.
SATURN 2010 / TECHdotMN field notes
by Jeff Pesek 5/19/10
Architecturally Focused Techniques for Managing System Evolution by William Koscho
Based on the premise that business strategy, process and units will inevitably change – the architect’s objectives are to: (a) understand/accept potential changes in the environment, (b) manage relationships between the environment and the architecture and (c) minimize the risk of the implementing change.
“Is this strategic change we want to invest in or is it arbitrary and therefore cost-sensitive?” Mr. Koscho asks in describing the internal thought process.
Posted in Architecture and Agile, Architecture-Centric Engineering, Architecture-Centric Practices, SATURN Conference
Tagged ADD, Agile Alliance, ATAM, attribute-driven design, documentation, non-functional requirements, SATURN 2010, SATURN Conference, software design, software development, system architecture, systems architecture
I am working with Bursatec, the technology company of the Mexican stock exchange on the architecture design for a new system. Bursatec is using the SEI’s Attribute-Driven Design (ADD) method embedded in a Team Software Process (TSP) environment for designing the new system. They also use the tool “Enterprise Architect” for documenting the system’s software architecture.
Last week, when working with Bursatec’s architecture team, they showed a nice little rule they implemented for using the design tool. Since I believe that many architects have the same problem when using a design tool, I thought it would be worthwhile sharing their solution. Continue reading
The community has done a good job in describing and understanding techniques for achieving operational qualities. Performance, availability, security, and usability have been well studied from the point of view of definitions and techniques to achieve them.
