SATURN 2011 Session: Agile and Architecture (morning session, May 18, 2011)

Notes by Jack Chen.

Agile Product Line Architecture
Paul Clarke, Northrop Grumman

Chief Architect of the airborne ISR product line.

Trying to be agile with a product line.

  • There is an existing architecture, no greenfield development.
  • How to make changes and evolve the architecture within a product line.
  • Adoption of agile development and how that factors into large systems; retain architectural practices.

Topics are applicable to any product lines, though the perspective here is from a government contractor.

There is a brick wall between similar projects, but hard to obtain reuse.

Product line approach, look at core assets across all products and figure out how to exploit the commonality.

Managing variation within a product line: requirements, design, and change management

Key concerns for Airborne ISR

  • scale for hardware and embedded systems
  • aircraft variation

Roadmaps are important!

  • market view – what is the competition doing?
  • solution view – what does our system need to look like in terms of technologies?
  • threats & mission – what to counter (threats) and how to accomplish (missions)?

Define a gap analysis and trade studies to develop a roadmap.

Roadmap methodology overview

  1. What are the gaps?
  2. Develop business case
  3. Evaluate technology trends
  4. Re-evaluate entire architecture
  5. Define end-state architecture
  6. Create architecture roadmap
  7. Periodically reassess roadmap and adjust

Various visual representations to allow for easier gap analysis

Strategies for changing the architecture

  • simplify – remove rarely needed features and exploit new standards
  • isolate – reduce internal interfaces, favor simple interfaces; favor abstraction
  • downsize – re-package for smaller scale; compress hardware functions opportunistically
  • unbundle – split monolithic functions; independent development
  • bundle – create larger-grained modules as a standard for reusable components
  • find new modularity – focus on reuse and flexibility
  • retain backwards compatibility

Devise a series of transitions from where you are to the defined end-state

This step-process, or roadmap; defining the time sequence and funding sources

“Stumbled” into agile development

  • Identified a component that did not meet the benchmark needs
  • Plunged into XP and were able to meet their deadline needs
  • Using this success and decided to try Scrum on a larger scale

Benefits

  • Staff was motivated.
  • Architecture was dealt with through design stories.
  • An entire sprint was used to create the architecture (sprint 0).

Embedded software requires longer iterations (3-4 weeks); longer turnaround time.

Problem tracking reports (PTRs) for a sprint

If something couldn’t be finished within a sprint, a new story was created for the next sprint.

Frequent and tangible milestones are invaluable.

Question: roadmap, how do you keep it up to date?

  • It is a significant problem. Started off in Excel, moved onto Microsoft Project
  • Major changes to the roadmap do not happen very often

Question: how long was the first sprint on architecture?

  • 3-4 weeks, but it may take multiple sprints, must be flexible.
  • Hardware is a much more linear process than software, in terms of organization and coordination.

Question: how do you enable architectural change?

  • The key is the infrastructure, mostly known pieces are built without having a solid infrastructure, e.g., the bottom layer of a layered system
  • We have used a software abstraction layer to hide changes in the hardware.
  • Build isolation layers in the beginning.

Question: roadmap changes may not be visible to the end-consumer, how do you articulate their value?

Management needs to see the big picture, what you’re changing, how you’re doing it; it is a balancing act.

Question: how did team size change from pre-Scrum to Scrum? How did this affect communications between the existing teams?

Team sizes didn’t change; used the Scrum process to coordinate better.

Low Ceremony Architecture
Jeromy Carriere, eBay, Inc.

Abstract

New initiative at eBay called X.Commerce.

Brief introduction of his past with Vistaprint

  • Data-driven, energetic, passionate, execution-focused
  • After getting the customer started with a basic style business card, to change styles, you have to enable a premium service.
  • Vistaprint will help you target your customers and send marketing information to them.
  • Mass customization is key!

Push accountability onto each project manager, developer, analyst

Not a start-up anymore. Each individual contribution is small given the surface area.

Architecture was viewed as a barrier by various stakeholders.

  • A feature is known to be good, but the architecture stood in the way.
  • Internet companies have the expectations for failure, as long as they do it quickly.
  • If you’re not keeping up with the marketplace, you’re dead.
  • Ironically, these organizations need architectural disciplines the most.
  • They operate within an uncertain future.

Architecture should not be about the artifact, but the practice.

Choice of programming language

  • Hard to change
  • Large impact on quality attributes.

Everyone could be making an architectural decision.

  • Must raise its visibility.
  • Organizational changes
  • Platform team
  • Solution architects were dispersed, decentralized.

“Guardrails,” guiding principles

  1. Articulate distinct choices, choose the one that maximizes full economic value.
  2. Choose designs that will result in the smallest, least coupled software.
  3. Build software that is robust, intentionally designed, with understood limitations.
  4. Utilize standardization to increase predictability and scalability.
  5. Plan for post-development phases including deployment, testing, ops, and maintenance.

Roles, not titles. Defining the architecture competency model, we noticed that it was very close to the engineering model.

Project-oriented organization

  • A project manager is responsible for end-to-end business success of a project.
  • Technical role is responsible for the technical success, resulting in local optimization.
  • The consulting architect is responsible for maintaining the overall system’s vision.
  • Well-specified decision rights in terms of responsibilities assigned to the roles

Autonomy: yes, build silos, but know how to cross between them.

Practices

  • Must map a $$ figure for architectural changes.
  • Managing technical debt as a portfolio; you have to measure it, understand whether you can afford it, be aware of “balloon” payments in the future.
  • design & code reviews, etc
  • explicit current & target state diagrams

Make architectural transitions visible to the organization.

  • Show how projects carry the organization from the current state to the target state.
  • Clearly articulate the benefits and attach those to $$.

Everyone believed that a developer hour was worth X, this was a calibrated scale.

  • It didn’t matter if it was right, since everyone used it as a standard.
  • This then can be converted to an actual $$ figure when measuring productivity.

Go write code.

Don’t “boil the frog” with standards; slowly add standards and constraints and people will buy it.

Question: how did the five standards come to be?

  • These were about building a collaborative culture.
  • Sat in a room with various stakeholders and multi-voted to get these standards.

Question: biggest challenges faced implementing these changes?

  • Role baggage; credibility building – must get involved wherever you can
  • Team dynamics, had to convince them that you were going to do the right thing by demonstration. If something is standing in your way, come to me, I’ll make it go away.

Question: formal process between project & consulting architect?

  • No checklist, but let the organization arrive at their own equilibrium.
  • e.g., Project architect would publish some spec, the consultant architect would review and they would talk.

Question: how were conflicts avoided or resolved?

LAAAM was the solution, this decision process was awesome at resolving differing opinions. This method helps you reason through opinions focused on the quality.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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