Jiri Lundak

Archive for April, 2007|Monthly archive page

The 3 Axes of Agile Architecture

In Agile, Architecture, Programming on April 30, 2007 at 11:10 pm

When thinking about my last post today, I was not quite satisfied with it. The values seamed quite unfocused to me in hindsight.

Actually I think we need to condense – especially the values – some more, so that we get at the essence of the agile spirit we need to be able to measure a good architecture against it.

In the end I think it boils down to the following three axes, along which an architecture (maybe embodied by a framework) can be judged (see the figure below).

Agile Software Architecture Principles

I would contend, that an architecture satisfying all three of the axes is THE agile architectural basis for software development that is able to deliver on the agile promise.

Let us have a deeper look at the individual axes:


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.

If it is easy to change and the developer is free to change his application at will, without too much effort, without breaking existing functionality of his application, then the overall design of the architecture (and the framework eventually embodying it), will remain simple, clean and easy to grasp over quite a long period of time (good tending practice implied).


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.

It simple does not allow to circumvent good coding practices. It allows freedom of interpretation only in dimensions, that are in the application domain. It helps the developer to test his code in an easy, dare I say fun fashion, so that he wonders, how he could ever live without the safety net he is constantly weaving.


Though I mention this axis at the end of this text, it is the focal point of agile software development. When we do not produce the right thing, it is of no use to produce it as fast as possible with the highest possible quality.

That said, 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.

At the same time it should prove to be a tool in the developers hands, that allows to try out easily alternatives, that can be quickly transformed into a visible artifact to put in the hands of the customer, so that fast feedback can be harvested, which eventually flows back into the development cycle.

Complementary products like acceptance testing support and generic self-documentation should help to produce value faster.


To produce an architecture (embodied in a application framework) that supports these essential values, may not be easy, but at least this is a starting point to think more deeply about principles that support this value-system.

As a nice side-effect I now have a system, that allows me to have a look at existing application development framework and weight them against each other. But I will spare this for another post.

Agile Software Architecture Principles

In Agile, Architecture, Programming on April 30, 2007 at 1:30 am

It is not a secret that I am fond of Agile software developement. I have published multiple articles over the last few month on pitfalls with Agile implementation and I am even writing a book about it.

But in my chest there still beats a heart of an architect and developer. As such I would like to see still better tools, frameworks and development practices. Last friday I was the last standing man at our company, with a colleague of mine and we were fantasising about our personal take on a lean, mean application development framework. We found quite a common ground, when it came to our dislikes with the existing way to develop software in the Java world.

It is always easier to articulate your dislikes, instead of reflecting on the values and principles, that you would like to see flourish.

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 hunderts 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

When going through these points in retrospect, I would like to synthesize some values and principles, that I would like to see in a framework, that really helps me concentrate on giving a customer what he needs, without much of the grieveance included, when using today’s breed of tools.

Here are the values I would like to see embodied by an ideal framework:

  • Efficiency
  • Purity
  • Easy Modifiability
  • Expressiveness
  • Openness

These should be support by principles the framework should enforce and follow:

  • Ease of use
  • Transparency
  • Scalability
  • Maintainability
  • Testability

There is some tendency towards easing the pain of development with the advent some of the newer frameworks for web development, maybe started by the hype surrounding Ruby on Rail. Other new frameworks, that fit in this category are SEAM and Grails.

While these frameworks tend to point into the direction I would like to imagine, they are still not there, yet. Too much boiler-plate code, sometimes too much XML. And if all else fails: I could still argue, that they are not Java frameworks! 😉

I just would like to take the Agile thought to the extreme and make it as easy as possible (in Java) to implement and maintain an enterprise-ready application. “I know I’m a dreamer…but I’m not the only one”, to speak with Lennons words.

But who knows, out of idealism, sometimes something new and revolutionary can emerge. Let’s get surprised.

Technorati : , ,
Del.icio.us : , ,
Ice Rocket : , ,

Low Scrum Adoption Rate in German-speaking world?

In Agile, Scrum on April 30, 2007 at 12:45 am

A week ago I was presenting a session at the JAX conference’s Agile Day, hosted by Jutta Eckstein. Exceptional was the interest people have in Agile software development. First it was thought that only about 100 people would attend the Agile track, instead 280 showed up, showing the increased awareness.

Quite contrary to this only a few people (about 10) raised their hand, when asked who was already using Scrum. But even more surprising to me was the fact, that only about another 10 or so signaled their interest to use Scrum in the near future, when I asked them.

I think, that there is still a lot of potential to educate people to use Agile in their work. But how can we lower the entry barrier? During lunch I was talking to a group of people, that had their reservation about what to expect from Agile development. They mentioned the thought, that what was needed to provide would be some week long immersion workshop, to experience the benefits, for one’s own work.

Maybe this is missing, especially in the German-speaking part of the world.

Technorati : , , , ,
Del.icio.us : , , , ,
Ice Rocket : , , , ,

Poor People … Being So Platform-Dependent

In Programming, Technology on April 1, 2007 at 2:55 pm

In the April 1st 2007 issue of SD Times, in an article called “At Last, Visual Studio 2005 Works on Vista” David Worthington wrote:

“The Visual Studio product team had a decision to make last fall as Windows Vista progressed toward release: It could either ship a first service pack for Visual Studio 2005 that worked on the then-current versions of Windows, or wait for Vista. If it waited, there would be no compatible version of Visual Studio ready when Vista launched. Since a delay wasn’t acceptable to the team, the service pack was made available in December 2006. Vista was unveiled one month later, but Visual Studio 2005 was not certified to work with the operating system.

Since that time, Microsoft has caught up with itself. Visual Studio 2005 Service Pack 1 for Windows Vista arrived in March. Earlier versions of Visual Studio cannot run on Vista.”

This is just one consequence for making the software development environment dependant on the operating system. It actually shows the problems Microsoft is going to have in the future, when it continues with these dependencies.

Sure this makes developers dependent on the operating system release and forces them to buy a new operating system version, to get new features and to buy a new IDE version to be able to develop on top of the new operating system release. A downward spiral.

This does not lend itself to an agile software development approach and only make developers slaves of the platform.

This also shows how plattform abstraction in the virtual machine of a runtime environment is so important. And Microsoft is not able to deliver something similar. So I remain still grateful, that I never went down the track of .NET too far. Else I would have been crippled in my choices, something I prefer not to be.