One of the concerns about automation is that in many cases, it just makes a crappy business process a much faster crappy business process.
Out the door quicker, but is the business more agile?
Is that all service oriented architecture and Agile programming are achieving in some cases? The two approaches are enabling business managers and technologists to assemble solutions and services to address processes very quickly, as needed. But does this result in things getting pushed out into production too hastily, putting processes and the business itself at risk?
We know that IT shops have businesses breathing down their necks, with long lists of jobs that need to be done yesterday. SOA and Agile methodologies get things out the door quicker, but if there are errors or poorly designed processes that are being automated, does this really help make the business more agile?
Jasmine Noel, for one, points out in a new post at CIO.com that "true business agility is about doing more application changes faster without sacrificing the application’s performance or quality of service," something the SOA-Agile combo doesn't necessarily guarantee -- or may even exacerbate.
Application quality needs to be addressed as early in the process as possible. "The number of application performance problems depends on: 1) how well the application is engineered for the production environment; 2) how well application updates are managed; 3) how well defect and problem knowledge are shared across organizations."
Noel urges that processes include greater collaboration between development and operations teams.