tag:blogger.com,1999:blog-74499775304600298882024-03-13T17:33:50.394+13:00How much architecture?Michael Waterman's tales of academic research into the relationship between software architecture and agile software development. And other interesting agile stuff.Michael Watermanhttp://www.blogger.com/profile/13727958568384473423noreply@blogger.comBlogger18125tag:blogger.com,1999:blog-7449977530460029888.post-36673553874773284712018-05-08T19:35:00.000+12:002018-05-08T19:35:36.725+12:00Agility, Risk, and Uncertainty, Part 2: How Risk Impacts Agile Architecture
I was recently invited to write an article based on my doctoral research for the Pragmatic Architect column of IEEE Software magazine. It turned into an article that was too large for one column, so we split it into two. The first, Agility, Risk, and Uncertainty, Part 1: Designing an Agile Architecture, was published in the March/April edition of the magazine, and the second, Agility, Risk, and Anonymoushttp://www.blogger.com/profile/08145082456574012465noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-35293700236834115182018-05-02T21:08:00.001+12:002018-05-07T21:23:57.663+12:00Agility, Risk, and Uncertainty, Part 1: Designing an Agile Architecture
I was recently invited to write an article based on my doctoral research for the Pragmatic Architect column of IEEE Software magazine, for a non-academic audience. It turned into an article that was too large for one column, so we split it into two. The first, Agility, Risk, and Uncertainty, Part 1: Designing an Agile Architecture, was published in the March/April edition of the magazine. Anonymoushttp://www.blogger.com/profile/08145082456574012465noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-5004424193721874162017-05-21T20:00:00.000+12:002017-05-21T20:00:02.193+12:00New research - how does a software development team make the transition to agility?
I am excited to see Rashina Hoda has a new paper published at this week's ICSE conference.
Rashina is an academic at Auckland University in New Zealand; I was a colleague of Rashina's as she was finishing her PhD at Victoria University of Wellington just as I was starting out on mine in 2010.
At Auckland Rashina has continued her research into agile software development. This latest paperAnonymoushttp://www.blogger.com/profile/08145082456574012465noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-39762451824599506272015-03-30T19:30:00.000+13:002015-03-30T19:30:03.182+13:00The agile architect: who makes the architecture decisions?
This article is based on my research findings and is derived from part of one of my PhD thesis chapters.
In agile software development, architecture design is not the sole responsibility of a single designated architect or team of architects. Architecture decisions are made collaboratively by active members of the agile team, rather than by so-called ivory tower architects with one-way Anonymoushttp://www.blogger.com/profile/08145082456574012465noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-68257418126704525522015-02-16T21:56:00.001+13:002015-02-16T21:57:49.673+13:00Preprint version of agile architecture paper for ICSE conference
I have had an abridged version of my thesis accepted for the ICSE conference in Florence in May. We have uploaded a preprint version of the paper; the final version will be available from IEEE library after the conference.
Anonymoushttp://www.blogger.com/profile/08145082456574012465noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-63092464853360288172014-11-06T12:56:00.001+13:002014-11-06T12:59:53.102+13:00An emergent architecture is only half the story
I have heard many
stories of architects supposedly working in agile environments that suggest
these architects aren't maximising their agile potential. These stories often
describe architects who believe that an evolving architecture is simply one
that in which the emergent decisions are made in parallel with
development; they neglect continuously
refactoring the architecture to ensure Anonymoushttp://www.blogger.com/profile/08145082456574012465noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-79512407353911563162014-10-22T10:03:00.003+13:002014-10-22T10:03:35.451+13:00Agile software development creates change
In my
research, I defined agility as:
"...a software
development team’s ability to create change, respond to change and learn from
change so that it can better deliver value."
Someone commented to me
that the "create change" part of this definition was unusual: what does it mean?
Agile software
development actively encourages the customer to change the requirements of the product Michael Watermanhttp://www.blogger.com/profile/13727958568384473423noreply@blogger.com2tag:blogger.com,1999:blog-7449977530460029888.post-74227993638239946652014-08-19T18:00:00.000+12:002014-08-19T18:23:17.157+12:00A theory of agile architecture in a nutshell (part 2)
This post presents
the results of my PhD thesis in a nutshell (part 2 of 2). The first part introduced my research and talked about agile architecture. This part discusses the theory of agile architecture.
The final version of my thesis can now be downloaded from the VUW library if you want to read it in its full academic glory.
A theory of agile architecture
I have called the Anonymoushttp://www.blogger.com/profile/08145082456574012465noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-63281071379931515072014-08-15T18:49:00.000+12:002014-08-18T14:07:02.664+12:00A theory of agile architecture in a nutshell (part 1)
Today I deposited the final version of my thesis,
"Reconciling agility and architecture: a theory of agile architecture,"
with the university library. It is officially complete!
This post presents
the first part of a summary of my findings: my thesis in a nutshell. This part introduces my research and discusses what an agile architecture is. The second part, coming soon, Anonymoushttp://www.blogger.com/profile/08145082456574012465noreply@blogger.com5tag:blogger.com,1999:blog-7449977530460029888.post-65782578031705891752013-05-28T16:56:00.000+12:002013-05-28T16:56:55.618+12:00The effects of complexity and value on up-front architecture planning
Complexity versus size... and value versus cost.
What are the effects of each of these on up-front planning in agile development? I am presenting a paper on these results from my research at the XP2013 conference in Vienna next week.
Abstract:
A key feature of agile software development is its prioritisation of responding to changing requirements over planning ahead. If an agile development Anonymoushttp://www.blogger.com/profile/08145082456574012465noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-59519784340248381652013-04-05T17:00:00.000+13:002013-04-05T17:00:02.806+13:00The effects of size and complexity on architecture planning
Shaw and Garland opened their seminal book "Software Architecture: Perspectives on an Emerging Discipline" with this sentence:
"As the size and complexity of software systems increase, the design and specification of overall system structure become more significant issues than the choice of algorithms and data structures of computation".
That is, the bigger and more complex the Michael Watermanhttp://www.blogger.com/profile/13727958568384473423noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-29182685061718633462013-03-12T17:14:00.003+13:002013-03-12T17:14:47.724+13:00The relationship between requirements stability and up-front planningIs there a relationship between how stable a system's requirements are and how much up-front planning teams do?
If agile means delaying architectural effort till the last sensible moment so you can better respond to change and have less rework, then perhaps we can assume that the more stable your requirements are the more up-front planning you can do, so you can get the benefits of an complete Michael Watermanhttp://www.blogger.com/profile/13727958568384473423noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-91072755894130331592012-09-21T16:25:00.000+12:002012-09-21T16:34:57.961+12:00Modeling or experimentation?
Scott Ambler, of Ambysoft and Agile Modeling fame, has just had an article published in Dr Dobbs about disciplined agile architecture.
(This material is apparently based on his and Mark Lines' new book Disciplined Agile Delivery: A practitioner's Guide to Agile Software Delivery in the Enterprise, though I haven't read it yet.)
In this article Scott presents a number of choices that need to beAnonymoushttp://www.blogger.com/profile/08145082456574012465noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-46730003380262686852012-08-01T10:30:00.000+12:002012-08-01T10:30:58.242+12:00Learning agile methods at Victoria UniversityThis week the labs for Victoria University's Agile Methods course have started. The class of about seventy software engineering (and computer science) students is divided into teams, and have each chosen a development project to work on. Most projects have been provided by industry organisations who have some development work suitable for students.The projects last about ten weeks. The teams getMichael Watermanhttp://www.blogger.com/profile/13727958568384473423noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-55141930137590617162012-06-28T14:52:00.001+12:002012-06-28T14:53:41.614+12:00Wanted: Sydneysiders to help solve the "how much architecture?" paradox.Wanted: Sydneysiders to help solve the "how much architecture?" paradox.
I'm being let out of the office, and will be in Sydney for the week of 9 July 2012. If anyone in Sydney can spare an hour (at a time and place that suits you) and would like to participate in my research, drop me an email and I can fill you in with the details.
Basically, I'm looking for agile practitioners who have some Michael Watermanhttp://www.blogger.com/profile/13727958568384473423noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-10367258604409757542012-06-25T11:51:00.002+12:002012-06-25T12:00:59.605+12:00Why qualitative research?Why is my research qualitative, using data gathered from interviews, rather than quantitative, using data gathered from (say) measuring teams or software applications?
Here is the long answer:
When it comes to up-front planning in agile software development, there is general agreement that the 'big up-front design' (BUFD) doesn't work (that's the whole point of agile!), and that the 'no Michael Watermanhttp://www.blogger.com/profile/13727958568384473423noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-41896152925256273382012-06-06T11:52:00.002+12:002012-06-06T11:53:30.862+12:00XP2012 PhD SymposiumLast month, I attended the agile software development conference XP2012, held in Malmö in Sweden. I participated in the doctoral symposium, where a panel gives PhD students feedback on their research progress.
Each student submitted a paper to the conference, presented the paper with a twenty minute talk, and presented a poster
that summarises the research
at a poster session.
For this Michael Watermanhttp://www.blogger.com/profile/13727958568384473423noreply@blogger.com0tag:blogger.com,1999:blog-7449977530460029888.post-52233289474187055932012-05-26T00:05:00.002+12:002012-06-25T11:21:40.097+12:00An introduction to my researchAccording to the famous software engineer Grady Booch, software architecture “represents the significant design decisions that shape a system, where significant is measured by the cost of change”. Therefore, architecture design is an exercise in planning ahead – any changes made at the architectural level may require rework across the whole system. Architectural decisions include things like the Michael Watermanhttp://www.blogger.com/profile/13727958568384473423noreply@blogger.com0