Discussions

News: Jiri Lundak: The Three Axes of Agile Architecture

Bookmark and Share Get thread feed

  1. Jiri Lundak: The Three Axes of Agile Architecture (4 messages)

    Jiri Lundak has posted "The Three Axes of Agile Architecture," saying that there are three values that such an architecture embodies. It's a clarification of an earlier post of his, "Agile Software Architecture Principles," where he outlined his issues with existing frameworks and what he's looking for in an ideal framework. In the first post, he said:

    So what we dislike about existing frameworks boils down to the following short list:

    • Configuration in monstruous XML configuration files
    • The jungle of XML WebServices as the SOA silver bullet for all application integration
    • Way too much code generation in the past
    • Although we are fond of metadata to be leveraged in applications, we dislike too much annotations (obscuring further how things work)
    • Writing still applications for the single VM, not using the power of many distributed ressources
    • Frameworks, that grow to such giant dimensions, that you have to install a 60 MB package, of which you use only 1% in your application
    • Frameworks, that want to be everybody’s darling, by including hundreds of alternatives (we integrate anything) for each module and for this sacrifices ease of use and efficiency in programming
    • Generation of boiler-plate code seen as THE holy grail in increasing productivity
    In the second (more recent) posting, he condenses what an architecture should offer down to three axes: change-encouraging, value-producing, and quality-enforcing. An agile architecture (i.e., one appropriate for projects using agile methodologies) would fulfill all three axes. Short snippets from each axis' description:
    • Change-encouraging
      This axis focuses on embracing change. For an architecture to support this, it needs to be easily modifiable, extendable, refactorable. If it is hard to change, it will lead - over the long run - to clumsy code, horrible work-arounds, lots of glue code and very extensive documentation, that needs to explain all of its quirks and potholes.
    • Quality-enforcing
      Agility has one of its foundations in the delivery of production quality code on from iteration 1 to whatever number of iterations a project takes to complete. As such an application developed in agile manner needs a foundation, that has quality build right into it. This kind of architecture makes it hard for the average developer to make stupid mistakes.
    • Value-Producing
      ...[it] is crucial to produce value for the customer. The architecture should not stand in the developer’s way to produce some useful application. It should encourage him to produce value out of the box, to be able to show his customer a thin, but fully working, slice of the final product he will get.
    What do you think of his classification? Do you have any candidates for "agile architectures?"
    Reply to this

    Threaded Messages (4)

  2. Re: Jiri Lundak: The Three Axes of Agile Architecture[ Go to top ]

    Very interesting. I have been thinking along these lines for some time now, and have come to pretty much the same conclusions. I don't have any candidates for frameworks though. Yet.
    Reply to this Reply to original

  3. my OWN agile framework[ Go to top ]

    Interesting ... a lot of my projects requires agility to be the primary concern because neither the consultants (me) nor the customers understand it well, so it will have to grow over iterations. I have evaluated most of existing popular frameworks and found nothing fit my requirements, I decided to trash them and write my OWN framework, and find it to be the PERFECT solution for at least my last ten projects... refactorable bottom up, integratable almost with anything, and let me defines the granularity of the interfaces, so I can use different levels of business process abstraction depends on the requirement. You may wonder how I can come into this conclusion: 1. Existing fameworks has different motives, and it not always the solution, it probably only to seek popularity 2. Existing frameworks must cater so much user base so it could easily loose identity, simplicity and flexibility. How is this sound to you all ? Am i exxagarating ?
    Reply to this Reply to original

  4. Re: Jiri Lundak: The Three Axes of Agile Architecture[ Go to top ]

    I would think testability is the most important of his stated principles. A framework that supports an easily testable application will encourage change and enforce quality. And the testability of code is fairly easy to describe. "Value-producing" sounds nice of course, but I don't know how you describe this in real terms. I don't think something like "how much effort it takes to produce something that works" is always a good trait, since that may produce something that doesn't change easily at all.
    Reply to this Reply to original

  5. Re: Jiri Lundak: The Three Axes to grind[ Go to top ]

    Maybe it would be good to identify some frameworks and put them on the graph to see how they rate. Other drivers (a.k.a principles) I would include are efficiency and "critical mass." I prefer to work with opensource (and pay nothing) where the barrier to entry is usually lack of framework knowledge. Most projects/vendors give away the functional knowledge but use licensing/consulting to convey the non-functional knowledge like clustering/HA/specific integrations. That's where critical mass comes in. A framework needs to be validated in the market through use/knowledge-transfer/enhancements. I address the first three principles by using frameworks that support loose coupling and high cohesion (interfaces, IoC, MVC), testability (IoC, TDD), and for the value-producing principle - short iterations. Frameworks don't drive short iterations methodologies/process like agile does this.
    Reply to this Reply to original