Another caveat for the erstwhile agile developer
If your objective is a "sense of urgency", or maybe "time to value", please don't think this gives you carte blanche to push patchy, chewing-gum-and-bailing-wire solutions out into production. Expect the expectation that the production systems' availability level must be maintained.
Confused? It sounds like I'm taking two opposing sides ... I want speed and quality, and doesn't the Iron Triangle force you to pick between the two?
It's possible, of course, you just need to practice a little discipline. Pay attention to the spirit, not the letter, of the "law". So how to reconcile the two ideas?
- Fast, iterative Push-to-Test: If you're in a complex production environment (like an ERP), use the Test environment to get your iterations in front of your end users / testers. You can get the ideas out there, people can see what you mean, but the ultimate push into production only happens after a thorough, hopefully regressive, test.
- Segment your Content: If you have decent change management capabilities, you can segment low-risk changes to production (like HTML and PDF files on a web page) from high-risk changes (like DTS scripts that process financial transaction imports). Fast-track the low risk stuff; better yet, completely automate it!
- Formal Change Management Process: This may seem like old hat to the larger IT groups, but for those smaller organizations that have not experienced the pleasures of Sarbox ... a decent change management system (or even a hack one) should track all changes, keep a log of who and when, and make back ups of the before and after - so you can put things back they way they were.
posted by James P. MacLennan at 7:18 PM
| Permalink
| 0 Comments
