Tag: Architect

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.

Source code control and continuous integration are excellent tools for managing the application build and deployment process. Along with source code, schema and data changes are often a significant part of this process and thus warrant similar controls. If your build and deployment process includes a list of elaborate steps required for data updates, beware. These are the lists that always have you crossing your fingers. They look something like this:

1. Create a list of scripts that need to be run, in order
2. E-mail scripts to special database person
3. Database person copies the scripts to a location where they‘re executed by a cron job
4. Check script execution log and pray that all scripts ran successfully since you‘re not exactly sure what will happen if you re-run them
5. Run validation scripts and spot-check the data
6. Regression test the application and see what blows up
7. Write scripts to insert missing data and fix blow-ups
8. Repeat

Ok, so that might be a slight exaggeration but it‘s not that far off. Many a project requires this type of acrobatic workflow for successful database migration. For some reason the data portion of the migration plan seems to be easily overlooked during architecture planning. As a result it can become a brittle, manual process that gets bolted on as an afterthought.

This complex web-work creates many opportunities for process breakdown. To make matters worse, bugs caused by schema and data changes don‘t always get caught by unit tests as part of the nightly build report. They like to rear their ugly head in a loud, boisterous manner immediately after a build has been migrated. Database problems are usually tedious to reverse by hand and their solutions tend to be more difficult to validate. The value of a completely automated build process that is capable of restoring the database to a known state will never be more evident than when you‘re using it to fix an extremely visible issue. If you don‘t have the ability to drop the database and restore it to a state that is compatible with a specific build of the application you are susceptible to the same type of problems you‘d have if you couldn‘t back out a code change quickly.

Database changes shouldn‘t create a ripple in your build‘s time-space continuum. You need to be able to build the entire application, including the database, as one unit. Make data and schema management a seamless part of your automated build and testing process early on and include an undo button; it will pay large dividends. At best it will save hours of painful, high-stress problem solving after a late night blunder. At worst it will give your team the ability to confidently charge forward with refactoring of the data access layer.