SATURN 2010 TECHdotMN Session Notes, Wednesday, May 19

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.


He does suggest inserting the architect earlier in the life cycle for fewer constraints and integration within the drivers vs. the typical placement (requirements phase).

Two key questions to assess the needs of the situation: what level of BP standardization do you want and what level of BP integration do you want?

“Unified and standardization isn’t always the way to make money; autonomy also works, that is highly integrated but lowly standardized.” says Mr. Koscho.

Architecture decisions should focus on how the system will interact with its environment. Typical influences include: functionality, infrastructure, architecture designs, changes to other interconnected systems.

He suggests “digging deeper,” that is, dissect the taxonomy in terms of usability, security, maintainability, etc. and discover and respect the underlying variables. Continue defining taxonomies of architecture plans for each operating model organized by quality attribute scenarios.

Lessons Learned Adapting an Existing Architecture in a Changing Business Landscape by Arthur Wright – Credit Suisse

Credit Suisse organizational context: 48,000 employees; 56 countries in four major regions; 1 trillion assets under management (2009).

Internal and all-encompassing “Streetside Program” focused on broker and client connectivity, compliance and maintenance, product enhancements, etc.

In the functional context, Streetside provided IT services for: asset management, investment banks, third-party banks and connected with some 60 brokers directly.

What does Credit Suisse actually do? They take orders, maintain compliance, and execute trades. FIX is a common trading protocol, and the company uses open-source version. Credit Suisse makes an annual investment of $10 to 15M USD annually.


The challenge was to collaborate and deal with the technical challenges of the legacy system in a sensible way; International rollouts are by far the greatest challenge that Credit Suisse faces.

First lesson learned: “people build systems” seems obvious, but interpersonal dynamics and organizational relations can manifest themselves into architecture in unique ways.

Second lesson learned: “time spent evaluating options is time well spent”; good for team chemistry because they focus on facts and constraints. COTS evaluation methods, ADD, ATAM, PLanguage.

Third lesson learned: “When producing design documentation focus on important stakeholders” Template documents, stakeholder oriented views, UML Template model, CMMI.

Fourth lesson learned: “Have an architectural roadmap.” This creates vision, will align tactics with strategy, accommodates change and allows for the option of reversing change.

Managing Software Interfaces on On Board Automotive Controllers by Anthony Tsakiris, Ford Motor Company

Today’s cars are heavily software intensive and reliant on electronic controllers that share information. There are between 20-40 controllers depending on the model. A “Power Pack” is the combination of a high-voltage battery, engine controller, and a transaxle series of motor+generator+gear set+controller.

Business Goals: Avoid duplication of engineering work, easily deploy new features and technology, be quicker to market, reduce product and development cost. Longer term, the objective is to easily transfer power packs across large product line.

Organizational Constraints: “Historically, we’re not architecturally driven,” he admits. Incremental change is typically favored to reduce risk. Collective mental model overwhelmingly focused on hardware view. Different brands have different business models.

The solution: A new project “to eliminate the problems that caused the first project’s failure.”

  • six working teams, one devoted to control architecture and interfaces
  • a committed team of subject matter experts
  • Interface homogenization: 1160 interface signals which were collected from legacy designs we condensed into three categories.  393 redundant or undesirable signals were eliminated.

Lessons learned:

  1. illuminate the entire product line constantly. Establish a framework for thinking about the system that covers the entire product line. Make it the basis for integrating new features. This helps balance new features.
  2. Keep the team attention to non-functional quality attributes. Do not disband the team unless other mechanisms are established to take its place.
  3. Evolution works too.
  4. Do not wait for a complete architecture description.
  5. Educate
  6. Be persistent and have patience

Architecture and Agile, Friends or Enemies? By Ger Shoeber, Siouix Embedded Systems B.V.

Incremental, multi-disciplinary framework with the process of business drivers-> requirements-> integration strategy.

The system architecture is the foundation for the mechanical devise, electronics device or software.  Measure your iterations frequency.

“Integration is about finding the unknown. Intented time to market is important to know what is possible or not.”

CAFCR Framework. ( Asks: not just what are the requirements, but why is the requirement there, that is, what is the rationale?  Ger’s Statement: If you have to work with greater than one person, whether an internal team, miscommunication is the biggest risk. Start with low-tech means to learn the CAFCR method.

A few lessons learned:

  • incremental/iterative development with short feedback loops
  • integrate as early as possible to address weak points in the architecture/design
  • vertical integration strategy
  • testing focus on non-functional requirements as early as possible
  • daily standup meetings with the team during every phase of the product development
  • the customer is never wrong, involve the customer whenever possible, accept feedback
  • design the system from the most important view, that of the stakeholder

Designing and Building Large-Scale Systems in an Agile World by Stevie Borne and Dave Hendricksen, Thomson Reuters

Mission: “We’re here to develop high value and high quality software quickly.” The challenge within Thomson Reuters is that large teams of 25-50 people are naturally complicated.

An Agile Outline:


  • short feedback loops
  • inspect and adapt
  • collaboration, communication, teamwork


  • training
  • project kickoff
  • release planning
  • iteration planning
  • daily stand up
  • review/demo
  • retrospective


  • iterations
  • user stories
  • co location
  • story boards
  • planning poker
  • etc.


  • big design up front
  • coding cowboys
  • refactor later
  • no documentation


  • refined product
  • fewer late defects


  • increased time commitment
  • stuck in a canyon


  • you need a roadmap
  • deal with non-functional requirements upfront
  • create a two-dimensional model of priority (story map) that plots the value and necessity of various components.
  • define size and scale
  • build capabilities, not solutions
  • find the balance
  • people over process
  • keep the visions steady
  • experienced coach needed

Agile Architecture: Using Agile Principles to Agilitize the Architecting Process by Amine Chigan

What can architecture learn from Agile? The goal is to make the architecting process agile without compromising the integrity of the process itself.

Specific project was focused on safety vs. openness on the campus environment in response to the Virginia Tech shooting. Aimed at providing situational awareness that enabled security control.

From the Agile Manifesto, there are four key values:

  • individuals and interactions over process and tools
  • working software over comprehensive documentation
  • customer collaboration over contract negotiation
  • responding to change over following a plan

While there is value in the items on the right, there is more value in the things on the left.

Scott Ambler’s definition is: user stories are a way to document conversations with a customer or stakeholder.

Mike Cohen’s Pattern: As a (role) I want (something) so that (benefit).

The architecture wall is the wall and moveable whiteboard used to post and organize index cards and post-it notes describing the architecturally relevant capabilities and their corresponding architectural blueprints.

Architectural refactoring: Code refactoring is the process of modifying the internal aspects of a program without affecting its external behavior.

Lessons learned:

  • keep an open-minded approach to doing things
  • the more agile we become, the more we appreciate the role and importance of agile architecture
  • application extends outside the software space


  • Increased visibility of intermediate work, that is, know what’s happening in between
  • Enhanced communication among architecture owners
  • Change tolerant process whereas emerging requirements can be more easily incorporated.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s