1 / 16

Continuous Attention to Technical Excellence and Good Design…

Continuous Attention to Technical Excellence and Good Design…. Agile Software Architecture – Why Do We Care ? 3/14/12 Jonathan Rayback, Motorola Solutions. Why do we care?. Shouldn’t this be someone else’s problem?. Why do we care?. Shouldn’t this be someone else’s problem?

adelle
Download Presentation

Continuous Attention to Technical Excellence and Good Design…

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Continuous Attention to Technical Excellence and Good Design… Agile Software Architecture – Why Do We Care? 3/14/12 Jonathan Rayback, Motorola Solutions

  2. Why do we care? • Shouldn’t this be someone else’s problem?

  3. Why do we care? • Shouldn’t this be someone else’s problem? • We’re executives after all!

  4. Why do we care? • Technical executives: • We want to have understandable, maintainable code. • We want our developers to be craftspeople. • Other? • Business executives: • We want to better understand what our money buys us. • We want to be able to respond quickly to business priorities (isn’t that what Agile promised us?). • If the structure is valuable in and of itself, you can sell the structure…the platform itself has value…shareholders care

  5. Obstacles? • Organizational? • Conway’s Law: “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” [1968] • Cultural? • “too” “agile”? • Coding seen as more valuable than designing? • Lack of skills needed to cultivate good architecture? • Habit of running faster than really capable? • Reality? • Not all software is green field…sometimes you inherit bad code

  6. Good software architecture…(From Robert C. Martin: http://www.youtube.com/watch?v=WpkDN78P884) • …should reflect what the software does. • Like building blueprints…

  7. Good software architecture…(From Robert C. Martin: http://www.youtube.com/watch?v=WpkDN78P884) • …should reflect what the software does. • Like building blueprints… • …allows major decisions to be deferred. • Story of FitNesse…

  8. Good software architecture…(From Robert C. Martin: http://www.youtube.com/watch?v=WpkDN78P884) • …should reflect what the software does. • Like building blueprints… • …allows major decisions to be deferred. • Story of FitNesse… • …maximizes the decisions not made. • “Simplicity – the art of maximizing the amount of work not done – is essential.”

  9. Good software architecture…(From Robert C. Martin: http://www.youtube.com/watch?v=WpkDN78P884) • …should reflect what the software does. • Like building blueprints… • …allows major decisions to be deferred. • Story of FitNesse… • …maximizes the decisions not made. • “Simplicity – the art of maximizing the amount of work not done – is essential.” • “Architecture is the art of drawing lines such that all dependencies that cross a line always go in the same direction.”

  10. ExampleIvar Jacobson as described by Robert C. Martin • Driven by use cases so architecture communicates what software does • User stories? • Use cases are architectural currency…they become objects: Interactor/ (Control) (Use Case)

  11. ExampleIvar Jacobson as described by Robert C. Martin Entity Interactor Entity (Use Case) Entity

  12. ExampleIvar Jacobson as described by Robert C. Martin Application-specific Logic Application-agnostic Logic Entity Interactor Entity (Use Case) Entity

  13. ExampleIvar Jacobson as described by Robert C. Martin Application-specific Logic Application-agnostic Logic Entity <I> Boundary Interactor Entity (Use Case) <I> Boundary Entity

  14. How? • Dean Leffingwell: Agile Software Requirements • “Requirements and [Architecture] represent two sides of the same coin.” • “What the system will do” is reflected in requirements • “How the system will do it” is the architecture • They are NOT independent! • Emergent architecture is good but sometimes it needs to emerge intentionally. • Eventually all systems will have portions that need to be re-architected. • Common vision, strategy and governance model required.

  15. Leffingwell’s Eight Principles of Agile Architecture • For large systems • Leverage desirable agile properties • Adds safety: • The teams that code the system also design the system. • Build the simplest architecture that can possibly work. • When in doubt, code it or model it out. • They build it, they test it. • The bigger the system, the longer the runway. • System architecture is a role collaboration. • There is no monopoly on innovation. • Implement architectural flow.

  16. Key takeaways: • Focus on your organization: Conway’s Law. • Get the right people with the right kind of temperament and skills. • Embrace the System Architect. • Insist that teams take time to nurture the code. • Don’t abdicate your role as steward!

More Related