1. Have you seen/experienced cases where software architecture emerges successfully from continuous small refactoring?
Yes. I have experienced cases where software architecture continuously influences the development approach within small refactoring efforts. I do NOT see architecture emerging FROM each refactoring effort, I see architecture influencing the approach at the beginning of the sprint and then development iterations provide slight alterations to the overall architecture. What emerges has been strongly influenced by the architecture specified (or agreed to) going into the sprint.
I have seen this approach creating many successful and implemented architectures. Architectural mores (or best practices) become entrenched within the team and continuously influence design at the beginning of each sprint.
2. What are the main reasons that make the emerging of software architecture from continuous small refactoring success, according to your observations/experiences?
- Grounded in actual software implementation
- I manage refactoring projects as improvement projects. The architecture is also improved.
- Successful architecture should be measured by implemented architecture. (As opposed to documented and prescribed architecture)
- Refactoring success using agile approaches includes a high level of communication. Within an experienced group this dialogue always includes architectural themes; this also improves architecture.
Architecture will always occur. No system can be implemented without architecture. The architecture may be optimal or it may be chaos; either should be considered architecture, for better or worse... it is still architecture. I have experienced two cases where architecture did not emerge from the continuous small refactoring. In both cases architectural groups (separate from the agile development teams) were present within the organization. Essentially the architecture groups dictated the architecture; the agile teams were restrained and worked within the prescribed architectural constraints.
4. What are the main reasons that cause such unsuccessful emerging of software architecture from continuous small refactoring, according to your observations/experiences?
- See answer to previous question.
- Architecture is dictated by and architectural group, the architecture must be complied to or the project with not continue.
Banking Software: 250 person software development company focused on Core banking systems had five person architecture group with one manager. Agile groups of developers were restrained by architectural guidelines created, promoted and “enforced” by the architectural group.
Insurance Company: 5000 person insurance corporation with numerous IT and development groups had 10 person Enterprise Architectural group. Some small development teams used Agile approaches. Architecture did not emerge from refactoring efforts due to architecture groups governance (or restraints) upon architecture.
6. How many years of experience do you have in using agile methods?
Seven
7. Which agile methods (e.g., Scrum, XP) have you used?
XP
8. Which application domains (e.g., automobiles, telecommunications, finance, medical devices, web-based socio-technical systems, and etc.) you have been working in?
Core Banking, Wealth Management, Insurance, Health / Medical, Legal education, DRM / software licensing, Others...
9. What is your definition/understanding of software architecture? (You can refer to a definition you like or give your own understanding.)
Wikipedia has a reasonable definition; http://en.wikipedia.org/wiki/Software_architecture
Or
The infrastructure (hardware and software), guidelines, approaches, designs, roadmaps and best practices that sheppard solutions toward business strategy.
