Category: Software Architect

The support and maintenance of an application should never ever be an after-thought. Since over 80% of an application’s life-cycle is spent in maintenance, you should pay a lot of attention to the problems of support and maintenance when you’re designing. Fail to heed this and you’ll watch with horror as your application stops being the architect’s dream and becomes a vile beast that dies a horrible death and is forever remembered as a failure.

When most architects design applications they think mainly of developers, who have IDEs and debuggers in place. If something goes wrong, highly skilled software engineers debug away and the bug is discovered. It’s easy to think this way because most architects have spent most of their lives as developers rather than administrators. Unfortunately, the developer and the support guy have different skill sets, just as the development/testing environment and the production environment has different purposes.

Here are a few of the disadvantages that an administrator faces:

• An administrator can’t resubmit a request message to reproduce the problem. When you’re in production, you can’t re-issue a financial transaction against the “live” database to see what when wrong
• Once the application is in production, the pressure to fix bugs comes from customers and executives, not from the project manager and the testing team. And an angry CEO can be a lot more threatening.
• Once you’re in production, there is no debugger.
• Once you’re in production, deployment needs to be scheduled and co-ordinated. You can’t take a production application down for a few minutes to test a bug fix.
• The logging level is much higher in the development environment than in production

A few symptoms of this failure to plan for support are:

• most problems require a developer’s involvement
• the relationship between the development team and the support team is sour; the developers think the support team is a bunch of idiots
• the support team hates the new application
• the architect and development teams are spending a lot of time in production
• the application is restarted often as a way to resolve problems
• the administrators never have time to tune the system properly because they’re always fighting fires

To ensure that your application succeeds once it’s out of the developers’ hands, you should:

• understand that development and support require a different skill set
• get a support lead as early in on the project as possible
• make the support lead a core part of the team
• get a support lead to be involved with the planning for the application support

Design such that the learning curve for the support personnel is minimal. Traceability, auditing and logging are crucial. When the administrators are happy, everybody is happy ( espescially your boss)

Architects like to deal with metaphors. They provide nice concrete handles on subjects that are often abstract, complex and moving targets. Whether it is communicating with the rest of the team or talking through the architecture with the end-user it is so tempting to find something tangible or physical to use as a metaphor for what you are trying to build.

This usually starts well, in that a common language can evolve where people start to feel that things are moving in the right direction. The metaphor develops and grows over time until it takes on a life of it’s own. People feel good about the metaphor – we’re making progress!

What usually happens is that the metaphor for the architecture now becomes dangerous. Here’s how it can turn on it’s Architect creators:

• The business domain customer starts to like your metaphor more that your proposed system, in that the happiest possible interpretation is now taken by all concerned and where no real constraints are uncovered.

Example: We’re building a ‘transport system like a ship travelling between a series of docks’.

You think container ships crossing the Pacific. I was actually thinking a rowing boat in a swimming pool, with possibly one oar.

• The development team starts to think that the metaphor is more important than the actual business problem. You start to justify odd decisions because of a fondness for the metaphor.

Example: We said it’s like a filing cabinet so of course we have to show it to the user alphabetically. I know it’s a filing cabinet with six dimensions and of infinite length and clock built in to it, but we’ve done the icon now – so it has to be a filing cabinet…

• The delivered system contains relics of names from old broken metaphors long gone; archaeological testimonials to concepts long refactored and dug over.

Example: Why does the Billing Factory object create a Port channel for the Rowing boat system? Surely it it should return a Pomegranate view for the Hub Bus? What do you mean you’re new here?

So remember, don’t fall in love with your system metaphor – only use it for exploratory communication purposes and don’t let it turn on you.