Category Archives: IT architecture

IT architecture

I hate agile!

Honestly that’s just a catchy blog title. The Agile Manifesto is for sure one of the best things that happened to my industry just next to Open Source licensing models and the Web architecture.

But I hate the term agile as it conveys far too many different meanings. Eventually agile thus is rendered a meaningless term.

So instead of saying agile you should call the thing your organization is doing

  • Undocumented in case you omit to produce documentation after product development
  • Unspecified and therefore untestable in case you leave scope fully up to your development team
  • Uncontrolled in case you also let them call the shots on the timelines or resources
  • Unplanned if you don’t plan

But when doing (almost) the same as above you could as well call it

  • Trusted creation when you leave scope to the experts
  • Value-oriented and negotiable if the developers and the business stakeholders keep the right balance between iterating (refining) and incrementing (adding)
  • Risk-minimizing if you’re avoiding big bangs because you deliver in little chunks rather than huge, epic milestones
  • Realistic or lean of you don’t plan but prioritize

There’s not one single meaning of agile. And this causes lots, and lots and lots, and lots of discussions as it’s naturally becoming very hard to agree on something when you’re running in different directions with full motivation (or want to fight different things with utter resistance).

Allegedly even the 17 guys who wrote the Agile Manifesto themselves had a pretty hard time to find a proper term for what they had in mind but could not yet clearly name.

“But we need some word to describe the common views that we hold, and felt agile was probably the best to go with.” Martin Fowler

According to Dan North the first candidate was adaptive – which I prefer – but there had already been a book out with that title.

Eventually the whole story about agile is like raising my currently 3-year-old son Philip. Asking people what they think is the best way to nurture a child I usually get two types of answers:

Most of the people have very specific opinions about the subject and keep sharing their beliefs and implicitly try to convince you to follow their advice.

On the contrary far less people would just ask about your son’s character, about the specific problems you’re facing or the goals you want to achieve.

I think the latter exactly describes what agile is all about: You want to achieve a certain goal and have to consider the organizational environment, resources, existing constraints and most of all the people you’re embarking on such a journey with. Be adaptive and don’t focus on Scrum, Kanban, Planning Poker, retrospectives, etc. These are most probably all good tools, but they’re not the core of what puts you ahead.

IT architecture

Rethink reuse

Although I cannot share details of my current work except of fancy presentations there’s one general topic that keeps haunting me in a lot of discussions: The question of reusing code and components across platforms, target audiences, use cases, etc.

At first glance it looks like a brilliant idea: You build something once and use it several times for various use cases. Technicians love such a concepts because they’re motivated by complex problems; business people of course are fond of possible cost-reduction; IT architects love to draw boxes with arrows around them and usually feel big pain when comparable boxes appear twice in their diagrams.

The problem: Good ideas do not always work out. And what annoys me the most is the fact that software reuse seems to be an unchallenged goal, a mantra nobody dares to question. A lot of the obvious side-effects are rarely considered when going for reuse, such as:

  • growing complexity by serving additional requirements. This complexity exists in many areas, e.g. coding, testing, decision-making, etc.
  • operational issues by serving multiple target groups/stakeholders, e.g. when can you do a maintenance window?
  • losing advantages you’d have from very focused implementations, e.g. performance, optimized UX, etc.

The Space Shuttle: a terrible example of reuse

Let’s look at an example outside of my world of IT: The Space Shuttle – or better called the Space Transportation System (STS) – is an almost perfect case study where cost reduction and related benefits where promised from reusing components.

Just by looking at the picture below you can actually see (or at least imagine) all the parts which were only needed to fulfill reuse: wings with their heat shield, a tail, landing gear including unnecessarily heavy tyres, a fully functional cockpit for landing, solid liquid boosters (two rockets on the side) which fell down back into the ocean, etc.

As it turned out the Space Shuttle was limited in capacity, only reached low orbits, was more expensive and eventually killed more people than any other comparable space launch system. (A nice read on forbes.com)

Space Shuttle Launch
One of the most impressive vehicles ever built – and a total fail: The Space Transportation System.

Not being an expert on space travel let’s get back to IT. The example above just shows that there was tremendous overhead just to satisfy the requirement of reuse. As an architect I will in the future try to think twice and try to locate the space shuttle projects amongst my tasks. Reusing stuff is really cool, but only as long as it makes sense.