Yearly Archives: 2011

Case Study: Architecture-Centric Engineering in Financial Industry

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.

Improving Testing Outcomes Through Software Architecture – Paul Clements

Testing plays a critical role in the development of software-reliant systems. Even with the most diligent efforts of requirements engineers, designers, and programmers, faults inevitably occur. These faults are most commonly discovered and removed by testing the system and comparing what it does to what it is supposed to do. This blog post at the SEI Blog by Paul Clements summarizes a method that improves testing outcomes (including efficacy and cost) in a software-reliant system by using an architectural design approach that describes a coherent set of architectural decisions taken by architects to help meet the behavioral and quality attribute requirements of systems being developed.

See also these additional posts by Paul here on the SATURN blog about architecture support for testing.

Software Architecture and “The Principle of Small Decisions”

I am a huge fan of Donald Reinertsen’s book The Principles of Product Development Flow. Reinertsen draws on a diverse set of disciplines including Lean manufacturing, economics, statistics, queuing theory, control engineering, and maneuver warfare to create a set of principles to guide the product-development process and improve product-development flow.

One principle in Reinertsen’s book is Principle E8, “The Principle of Small Decisions: Influence the Many Small Decisions.” Reinertsen describes this principle as follows:

Continue reading

Lean Principles and Software Architecture: The Waste of Information Transformation

This is the third in a series of posts about Lean principles and software architecture by Nanette Brown.

Read first post, Lean Principles and Software Architecture: Categories of Waste.

Read second post, The Waste of Waiting.

In Lean production, the waste of transportation and the waste of motion refer to the unnecessary, non-value-added movement of parts and material and people and equipment. While software development  inevitably  involves a certain amount of movement of people and equipment, information is the primary entity that moves or flows throughout the  development process. Therefore, the mapping of  the wastes of transportation and motion to software development might best be characterized as the “waste of information transformation.”

In software development, information is constantly being transformed. The end user’s mental model of the system as a set of capabilities is transformed to the architect’s mental model of system structure and the developer’s mental model of components, interfaces, and algorithms and the tester’s mental model of test strategies and test cases. These mental models are in turn transformed into human-readable artifacts (such as user stories or architecture diagrams or test cases) and machine-readable artifacts (such as code and automated test suites). The question is, What is the most effective way to transform the information? Which transformations add value and which add waste?

Continue reading

Cloud Computing for the Battlefield

The U.S. Department of Defense (DoD) is increasingly interested in having soldiers carry handheld mobile computing devices to support their mission needs. Soldiers can use handheld devices to help with various tasks, such as speech and image recognition, natural-language processing, decision making, and mission planning. Three challenges, however, present obstacles to achieving these capabilities.

  1. Mobile devices offer less computational power than a conventional desktop or server computer.
  2. Computation-intensive tasks, such as image recognition or use of a global positioning system (GPS), take a heavy toll on battery power.
  3. Networks and bandwidth are unreliable.

This post at the SEI Blog by Grace Lewis explores SEI research in overcoming these challenges by using cloudlets. Cloudlets are localized, lightweight servers running one or more virtual machines (VMs) on which soldiers can offload expensive computations from their handheld mobile devices, thereby providing greater processing capacity and helping conserve battery power.

The Amazon EC2 outage

I have recently been educating myself about the cloud and infrastructure as a service (IAAS). One of the issues that came up in my reading is the outage that Amazon EC2  suffered on April 21. There seem to be two schools of thought about this outage:

  1. This goes to show that you can’t trust the cloud to be 100% reliable.
  2. Of course the cloud is not 100% reliable and the prudent thing for an engineer to do is to assume that it will fail and to architect your system so that it is resilient to failure.

I have been convinced by the second argument mainly because I have been reading the Netflix tech blog. In one post, they describe why Netflix  customers were unaffected by the Amazon outage even though Netflix has moved almost all of its operations onto EC2. It comes down to, in the words of one commentator, whether 99.95% availability should be read as saying that an outage is an extremely rare occurrence or whether it should be read as a guarantee that EC2 will be unavailable .05% of the time. Netflix took the second interpretation and architected their cloud usage to survive the outage.

- Len Bass, SEI

Free SEI Webinar 6/23: Service-Oriented Architecture: A Quality Attribute Perspective

Grace Lewis

On Thursday, June 23 from 1:30 to 2:30 Eastern time, Grace Lewis of the SEI will present a free SEI webinar, titled “Service-Oriented Architecture: A Quality Attribute Perspective.”

Register.

About the Webinar

Service orientation is an approach to software systems development that has become a popular way to implement distributed, loosely coupled systems, because it offers such features as standardization, platform independence, well-defined interfaces, and tool support that enables legacy-system integration. From a quality attribute point of view, the primary drivers for service-orientation adoption are interoperability and modifiability. However, a common misconception is that an architecture that uses a service-oriented approach can achieve these qualities by simply putting together a set of vendor products that provide an infrastructure and then using this infrastructure to expose a set of reusable services to build systems. In reality, there are many architectural decisions that need to be made. An architectural decision that promotes interoperability or modifiability can negatively impact other qualities, such as availability, reliability, security, and performance. This presentation will talk about  the effect that service orientation has on system quality attributes.

Continue reading

Lean Principles and Software Architecture: The Waste of Waiting

This is the second in a series of posts about Lean principles and software architecture by Nanette Brown. Read first post, Lean Principles and Software Architecture: Categories of Waste.

In Lean production, “..waiting refers to the periods of inactivity in a downstream process that occur because an upstream activity does not deliver on time. Idle downstream resources are then often used in activities that either don’t add value or result in overproduction.” 1

The “waste of waiting” is certainly applicable to software development. Developers waiting for architecture specifications to be produced may be underutilized or may begin development anyway, potentially producing throwaway code or, more likely, making the “official architecture” moot. Developers waiting for requirements will often be pressured to start coding and therefore may feel obliged to make their own best guesses about what the customer wants. Testers may be idle waiting for a code drop, followed by an intense, exhausting blitz once the code finally does arrive.

Continue reading

Summary of SATURN 2011 by Presenter Walter Ariel Risi

Walter Ariel Risi, who presented Next Generation Architects for a Harsh Business World: Sourcing Non-Traditional Talent and Revamping Existing Talent at SATURN 2011, provides a detailed chronicle of his experiences at SATURN at his blog, Valterblog.

Guest Post: Architects Wanted in the Cloud: Thoughts on the SEI SATURN Conference Cloud and SOA Track

James Downey, PhD, a solution architect for Dell Services, blogs about cloud computing at http://CloudOfInnovation.com and contributes to @DellinTheClouds on Twitter. Also an active member of SDForum, James often writes for the SDForum newsletter on issues of interest to the software engineering community.

Will cloud computing make software architects obsolete? If cloud vendors take responsibility for quality attributes through SLAs, what work is left for architects? What decisions remain after the one big decision of moving to the cloud? Throughout the SOA and Cloud Computing track at the Software Engineering Institute (SEI) SATURN conference held this past week near San Francisco, SEI researchers and industry practitioners made clear that by increasing design options, the cloud dramatically expands the role of the architect. In reality, the decision to go cloud is anything but binary.

Continue reading