Ger Schoeber, Sioux Embedded Systems: Architecting & Agile: Friends or Enemies
Described a system architecting process, an incremental multi-disciplinary development approach. Starts with requirements derived from business goals for customers. Develops embedded software on a project basis. “We get paid only if our customers meet their goals.” Known functional requirements are main drivers.
Development process follows Scott Ambler’s approach. Start with a first iteration or sprint–focusing on requirements and architecture as foundation for activity, then build software on top of that. Embedded systems must take into account the environment in which the software must operate. Short sprints for software, less frequent iterations for electronics, and less frequent for mechanics. Then find integration points among software, electronics, and mechanics as early and frequently as possible.
As soon as system architect starts decomposing system, a decomposition and integration strategy must be in place, as early as possible.
“If you have to work in a project where the team is one person or more or is a project for a customer, miscommunication is the biggest risk.” So communication has to be deliberately addressed. To visualize the architecting project and as a means of facilitating communication among stakeholders, followed CAFCR framework, Gerrit Muller: Customer objectives, Application, Functional, Conceptual, Realization. Additional products were able to be derived from the first product by means of architecture.
- Incremental/iterative development with short feedback loops
- Integration as early as possible. This addresses the weak points in architecture/design (interfaces) in an early stage.
- “Vertical” integration strategy.
- Testing focus on non-functional requirements as early as possible.
- Daily stand-up meetings with the team, not only during development but in any phase of the project.
- Use information radiators, sheets on the wall for planning, status dashboard, architecture, business backgrounds.
- The customer is never wrong. Involve the customer whenever possible and use all the feedback you can get.
- Integrate over the disciplines as early as possible and as often as possible.
- Design a system from the point of view of the most important stakeholders (decision makers for buying the product).
- Only BDUF and a lot of paper work at the start.
- Give priority to functional aspects over performance and -ilities.
- Write documents for the shelf.
- Have the process in the lead.
- Communicate electronically only.
- Start without an architectural foundation especially when working on a family of products.
- Postpone integration to the latest stage of the project.
- Horizontal integration: Integrate layer by layer.
- Have user interfaces designed by technical people only.
Stevie Borne and Dave Hendricksen, Thomson Reuters: Designing and Building Large-Scale Systems in an Agile World
Some things that might work well in smaller projects don’t work as well on large scale.
Agile: deliver high-value, high-quality working software quickly. Principles: short feedback loops, inspect and adapt, collaboration and teamwork. Supported by ceremonies and techniques. Focusing on ceremonies and techniques will work on small projects, but not so well on larger ones. It’s especially important in large-scale projects to focus explicitly on higher level goals.
- cowboy coding
- no big design up front (involvement from architecture perspective is still needed, as early as possible)
- refactor later (when project is too large, refactoring huge amounts of code is not feasible)
- no documentation (“I challenge your documentation for the sake of documentation.” Need balance between creating a document because it’s done that way and creating a document because it does add value. Have to be able to write things down for, for example, global development. Don’t overdocument, but don’t underdocument. You do need documentation in agile, it just looks different; depends on what’s appropriate for the project.)
Pros of Agile approach
- better product – stories are evolutionary, not locked into complex specs that are unrealistic. Iterative customer feedback improves product.
- You build only what you need
- Fewer late defects
- increased time commitment – there’s architecture up front, but architect must also stay involved with project and where it is going throughout
- “stuck in a canyon” – tendency to end up in a spot where you didn’t want to be; need to keep an understanding and vision in mind of what the long-term value is.
- potentially more late changes, e.g., responding to competitors, hardware needs, arising of scalability issues because of not enough up-front design. “Tree to tree to tree to tree then…oh wow, look!”
Tips and tricks
- need a roadmap – approximate stages, pieces of functionality, and non-functional requirements. Need to deal with non-functional requirements up front
- story maps – view of the functional pieces that are key to the system. The key components that must be delivered and the want-to-haves – mapped on scales of low vs. high criticality and low vs. high value. Relative priorities of both. Good communication vehicle for the team, helps to set team priorities.
- define size and scale
- build capabilities not solutions
- domain modeling required
- experienced coach needed
- find the balance – how much design up front vs. iterating/coding
- keep vision nearby
- keep non-functional requirements in mind
- outside factors can still influence project
- people over process
The really short answer: think.
Amine Chigani, Virginia Tech: Agile Architecting: Using Agile Principles to Agilitize the Architecting Process
What can architecture learn from Agile? Goal is to make architecting process agile without compromising the integrity of the process itself.
Issue at VA Tech: balancing safety and openness on campus environments. Technical requirements: situational awareness, security control, and emergency response management in an open campus environment.
Followed principles of Agile Manifesto, which does acknowledge value in processes, tools, documentation, etc., but emphasis is on individuals and interactions, working software, customer collaboration, and responding to change.
Fundamental reason for agile paradigm is need to respond to constant change.
Four agile-like practices adopted:
- User stories – way to document conversations with a customer (Ambler); Mike Cohen’s pattern: As a (role) I want (something) so that (benefit).
- Quality scenarios – characteristics of the system, i.e., non-functional requirements. As a (stakeholder) I want (quality parameters) so to achieve (quality attribute)
- Architecture wall – movable whiteboard used to post and organize index cards and post-it notes describing architecturally relevant capabilities and their corresponding architectural blueprints
- Architectural refactoring – how index cards and post-it notes are shifted around in a structured manner to ensure the integrity of the existing relationships among user stories, among quality scenarios, and betweens stories and quality scenarios
- keep open mind about new ways of doing things
- we can work on being agile
- the more agile we become, the more we appreciate the role and importance of architecture
- consider doing the same for other phases separately
- increased visibility of intermediate work
- enhanced communication among architecture owners through ongoing assessment of architecture
- change-tolerant process; emerging requirements easily incorporated