Creating An Incremental Architecture For Your System
2 likes495 views
Giovanni Asproni discusses the concept of incremental architecture and its benefits in software development during the Accu Conference in April 2018. He critiques the rational design process, suggesting that software design is often not rational and advocates for an incremental approach to build systems in manageable increments while engaging stakeholders early and iterating as needed. The document emphasizes the importance of simplicity, testing, and the evolving nature of software architecture, particularly in legacy and brownfield systems.
![http://handbookofsoftwarearchitecture.com/?p=63
“Every software-intensive system has an
architecture. In some cases that architecture is
intentional, while in others it is accidental […]
the architecture of a system is the naming of
the most significant design decisions that
shape a system, where we measure significant
by cost of change and by impact upon use.”
Photo from: https://commons.wikimedia.org/wiki/
File:Grady_Booch,_CHM_2011_2_cropped.jpg](https://image.slidesharecdn.com/creatinganincrementalarchitecture-accu2018-180415093017/85/Creating-An-Incremental-Architecture-For-Your-System-3-320.jpg)
Creating An Incremental Architecture For Your System
- 1. Giovanni Asproni email: [email protected] [email protected] twitter: @gasproni linkedin: http://www.linkedin.com/in/gasproni Creating An Incremental Architecture For Your System ACCU Conference, April 2018, Bristol, UK
- 2. Agenda • What is Software Architecture • The problems with the “Rational Model” • What is Incremental Architecture and its advantages • Getting started • Growing the system • Incremental Architecture for legacy and brownfield systems
- 3. http://handbookofsoftwarearchitecture.com/?p=63 “Every software-intensive system has an architecture. In some cases that architecture is intentional, while in others it is accidental […] the architecture of a system is the naming of the most significant design decisions that shape a system, where we measure significant by cost of change and by impact upon use.” Photo from: https://commons.wikimedia.org/wiki/ File:Grady_Booch,_CHM_2011_2_cropped.jpg
- 4. “Cost of change” is a relative value
- 5. “Impact upon use” is about how much the users of the system are affected by those decisions
- 6. “Today’s programmers make design decisions about the architecture every single day. When one line of code can tank a required quality attribute, then you are a software architect whether you identify as one or not.”
- 7. Architecture Is For • Making important structural choices • Recording and communicating decisions • Guiding implementation decisions • Splitting work among teams
- 8. What Does Architecture Include? • Static and dynamic views of the system • Sketches • Prototypes and reference implementations • Documentation • Design and implementation guidelines • Anything else necessary to understand “the shape” and the behaviour of the system
- 10. The Rational Design Process From: The Design of Design, Fred Brooks
- 11. The Rational Design Process Doesn’t Work! • Design Isn’t Just to Satisfy Requirements, but Also to Uncover them • Design Isn’t Simply Selecting from Alternatives, but Also Realizing Their Existence • Often the domain is not well understood even by the domain experts! STAKT 1 - '•» T m mm | II
- 12. The chances of success of a big upfront design are inversely proportional to the size of the system being designed
- 13. BUFD Is A Red Herring • Most projects have: • Speculative Upfront Design (SUFD) • Absence of refactoring
- 14. “incremental design (also called evolutionary design) allows you to build technical infrastructure (such as domain models and persistence frameworks) incrementally, in small pieces, as you deliver stories”
- 15. Incremental Architecture • One small (set of) feature(s) at a time • Design • Implement • Test • Deploy
- 16. Adding increments is not enough, you need to iterate as well! One More Thing…
- 17. An Incremental Approach Can Alleviate / Remove Constraints • Early production => early revenue => fewer budget restrictions • A technology can be learnt while creating and deploying the system • Often, important deadlines can be met with just some basic functionality
- 18. An incremental approach allows to create the right domain model for the application
- 19. Qualities: Incremental Approach • Architectural Patterns • Hoisting • Prototyping
- 20. Getting started
- 21. “If the politics don’t fly, the system never will”
- 22. Engage with stakeholders and the development team from the start!
- 23. Start Small! “A complex system that works is invariably found to have evolved from a simple system that worked.”
- 24. Focus On What You Know • No SUFD • Sufficient design • Remove “reusable” and “flexible” from your dictionary • Address major risks
- 25. “Favoring simplicity before generality acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality.” Kevlin Henney
- 26. “Choose Your Tools With Care” Giovanni Asproni
- 27. You may have an idea of the final shape of the system. However, that’s just as an hypothesis
- 28. http://www.developerdotstar.com/mag/articles/reeves_design.html Test Your Hypothesis “Coding actually makes sense more often than believed. Often the process of rendering the design in code will reveal oversights and the need for additional design effort. The earlier this occurs, the better the design will be.” Jack Reeves, “What Is Software Design?”
- 29. Don’t Fall in love with your design!
- 30. Walking Skeleton From: http://alistair.cockburn.us/Walking+skeleton “is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.”
- 31. Walking Skeleton
- 35. The main purpose of automated tests is to make the system maintainable and evolvable
- 36. “When testing is done right, it is almost unreasonably effective at uncovering defects that matter.” John Regehr http://blog.regehr.org/archives/820
- 37. Create Feedback Loops • Continuous Integration • Continuous Deployment • Continuous Delivery
- 38. TDD at all levels helps Write a failing acceptance test Write a failing unit test Make the test pass Refactor
- 39. Often Forgotten Things • Buildability • Deployability • Configurability • Versioning strategies
- 40. How can I include architectural tasks in my workflow?
- 41. • Architecture in the Backlog • Architectural Trigger • Architectural Spike • Technical Debt Management Patterns
- 42. Documenting The Design IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-12, NO.2, FEBRUARY 1986 251 A Rational Design Process: How and Why to Fake It DAVID LORGE PARNAS AND PAUL C. CLEMENTS Abstract-Many have sought a software design process that allows a program to be derived systematically from a precise statement of re- quirements. This paper proposes that, although we will not succeed in designing a real product in that way, we can produce documentation that makes it appear that the software was designed by such a process. We first describe the ideal process, and the documentation that it re- quires. We then explain why one should attempt to design according to the ideal process and why one should produce the documentation that would have been produced by that process. We describe the contents of each of the required documents. Index Terms-Programming methods, software design, software documentation, software engineering. I. THE SEARCH FOR THE PHILOSOPHER'S STONE: WHY Do WE WANT A RATIONAL DESIGN PROCESS? APERFECTLY rational person is one who always has a good reason for what he does. Each step taken can be shown to be the best way to get to a well defined goal. Most of us like to think of ourselves as rational profes- sionals. However, to many observers, the usual process of designing software appears quite irrational. Programmers start without a clear statement of desired behavior and im- plementation constraints. They make a long sequence of design decisions with no clear statement of why they do things the way they do. Their rationale is rarely explained. Many of us are not satisfied with such a design process. That is why there is research in software design, program- ming methods, structured programming, and related top- ics. Ideally, we would like to derive our programs from a statement of requirements in the same sense that theorems are derived from axioms in a published proof. All of the methodologies that can be considered "top down" are the result of our desire to have a rational, systematic way of designing software. This paper brings a message with both bad news and good news. The bad news is that, in our opinion, we will never find the philosopher's stone. We will never find a process that allows us to design software in a perfectly rational way. The good news is that we can fake it. We can present our system to others as if we had been rational designers and it pays to pretend do so during development and maintenance. Manuscript received March 18, 1985. This work was supported by the U.S. Navy and by the National Science and Engineering Research Council (NSERC) of Canada. D. L. Parnas is with the Department of Computer Science, University of Victoria, Victoria, B. C. V8W 2Y2, Canada, and the Computer Science and Systems Branch, Naval Research Laboratory, Washington, DC 20375. P. C. Clements is with the Computer Science and Systems Branch, Naval Research Laboratory, Washington, DC 20375. IEEE Log Number 8405736. II. WHY WILL A SOFTWARE DESIGN "PROCESS" ALWAYS BE AN IDEALIZATION? We will never see a software project that proceeds in the "rational" way. Some of the reasons are listed below: 1) In most cases the people who commission the build- ing of a software system do not know exactly what they want and are unable to tell us all that they know. 2) Even if we knew the requirements, there are many other facts that we need to know to design the software. Many of the details only become known to us as we pro- gress in the implementation. Some of the things that we learn invalidate our design and we must backtrack.Be- cause we try to minimize lost work, the resulting design may be one that would not result from a rational design process. 3) Even if we knew all of the relevant facts before we started, experience shows that human beings are unable to comprehend fully the plethora of details that must be taken into account in order to design and build a correct system. The process of designing the software is one in which we attempt to separate concerns so that we are working with a manageable amount of information. How- ever, until we have separated the concerns, we are bound to make errors. 4) Even if we could master all of the detail needed, all but the most trivial projects are subject to change for ex- ternal reasons. Some of those changes may invalidate pre- vious design decisions. The resulting design is not one that would have been produced by a rational design pro- cess. 5) Human errors can only be avoided if one can avoid the use of humans. Even after the concerns are separated, errors will be made. 6) We are often burdened by preconceived design ideas, ideas that we invented, acquired on related projects, or heard about in a class. Sometimes we undertake a project in order to tryout or use a favorite idea. Such ideas may not be derived from our requirements by a rational pro- cess. 7) Often we are encouraged, for economic reasons, to use software that was developed for some other project. In other situations, we may be encouraged to share our soft- ware with another ongoing project. The resulting software may not be the ideal software for either project, i.e., not the software that we would develop based on its require- ments alone, but it is good enough and will save effort. For all of these reasons, the picture of the software de- signer deriving his design in a rational, error-free way from a statement of requirements is quite unrealistic. No 0098-5589/86/0200-0251$01.00 © 1986 IEEE
- 44. When The System Grows… • Increasing team size • Increasing the number of teams • Feature teams or component teams?
- 45. Brownfield And Legacy Systems • Rewrite from scratch rarely works • The incremental approach still apply
- 47. Books And References ptg6985396 From the Library of Giovanni Asproni ptg6985396 From the Library of Giovanni Asproni IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-12, NO.2, FEBRUARY 1986 251 A Rational Design Process: How and Why to Fake It DAVID LORGE PARNAS AND PAUL C. CLEMENTS Abstract-Many have sought a software design process that allows a program to be derived systematically from a precise statement of re- quirements. This paper proposes that, although we will not succeed in designing a real product in that way, we can produce documentation that makes it appear that the software was designed by such a process. We first describe the ideal process, and the documentation that it re- quires. We then explain why one should attempt to design according to the ideal process and why one should produce the documentation that would have been produced by that process. We describe the contents of each of the required documents. Index Terms-Programming methods, software design, software documentation, software engineering. I. THE SEARCH FOR THE PHILOSOPHER'S STONE: WHY Do WE WANT A RATIONAL DESIGN PROCESS? APERFECTLY rational person is one who always has a good reason for what he does. Each step taken can be shown to be the best way to get to a well defined goal. Most of us like to think of ourselves as rational profes- sionals. However, to many observers, the usual process of designing software appears quite irrational. Programmers start without a clear statement of desired behavior and im- plementation constraints. They make a long sequence of design decisions with no clear statement of why they do things the way they do. Their rationale is rarely explained. Many of us are not satisfied with such a design process. That is why there is research in software design, program- ming methods, structured programming, and related top- ics. Ideally, we would like to derive our programs from a statement of requirements in the same sense that theorems are derived from axioms in a published proof. All of the methodologies that can be considered "top down" are the result of our desire to have a rational, systematic way of designing software. This paper brings a message with both bad news and good news. The bad news is that, in our opinion, we will never find the philosopher's stone. We will never find a process that allows us to design software in a perfectly rational way. The good news is that we can fake it. We can present our system to others as if we had been rational designers and it pays to pretend do so during development and maintenance. Manuscript received March 18, 1985. This work was supported by the U.S. Navy and by the National Science and Engineering Research Council (NSERC) of Canada. D. L. Parnas is with the Department of Computer Science, University of Victoria, Victoria, B. C. V8W 2Y2, Canada, and the Computer Science and Systems Branch, Naval Research Laboratory, Washington, DC 20375. P. C. Clements is with the Computer Science and Systems Branch, Naval Research Laboratory, Washington, DC 20375. IEEE Log Number 8405736. II. WHY WILL A SOFTWARE DESIGN "PROCESS" ALWAYS BE AN IDEALIZATION? We will never see a software project that proceeds in the "rational" way. Some of the reasons are listed below: 1) In most cases the people who commission the build- ing of a software system do not know exactly what they want and are unable to tell us all that they know. 2) Even if we knew the requirements, there are many other facts that we need to know to design the software. Many of the details only become known to us as we pro- gress in the implementation. Some of the things that we learn invalidate our design and we must backtrack.Be- cause we try to minimize lost work, the resulting design may be one that would not result from a rational design process. 3) Even if we knew all of the relevant facts before we started, experience shows that human beings are unable to comprehend fully the plethora of details that must be taken into account in order to design and build a correct system. The process of designing the software is one in which we attempt to separate concerns so that we are working with a manageable amount of information. How- ever, until we have separated the concerns, we are bound to make errors. 4) Even if we could master all of the detail needed, all but the most trivial projects are subject to change for ex- ternal reasons. Some of those changes may invalidate pre- vious design decisions. The resulting design is not one that would have been produced by a rational design pro- cess. 5) Human errors can only be avoided if one can avoid the use of humans. Even after the concerns are separated, errors will be made. 6) We are often burdened by preconceived design ideas, ideas that we invented, acquired on related projects, or heard about in a class. Sometimes we undertake a project in order to tryout or use a favorite idea. Such ideas may not be derived from our requirements by a rational pro- cess. 7) Often we are encouraged, for economic reasons, to use software that was developed for some other project. In other situations, we may be encouraged to share our soft- ware with another ongoing project. The resulting software may not be the ideal software for either project, i.e., not the software that we would develop based on its require- ments alone, but it is good enough and will save effort. For all of these reasons, the picture of the software de- signer deriving his design in a rational, error-free way from a statement of requirements is quite unrealistic. No 0098-5589/86/0200-0251$01.00 © 1986 IEEE