Focus on Application Support and Maintenance
2015-08-26 09:26
363 查看

THE SuppoRT And MAinTEnAnCE oF An AppliCATion should never, ever be an afterthought. Since over 80% of an application’s lifecycle 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 pro- duction environment have different purposes.
Here are a few of the disadvantages that an administrator faces:
• An administrator can’t resubmit a request message to reproduce the prob- lem. When you’re in production, you can’t reissue a financial transaction against the “live” database to see what went 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.
114

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.
• Involve a support lead 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 (especially your boss).
Mncedisi Kasper is a director of technology and strategy at Open Xcellence ICT Solutions, a South Africa–based company specializing in enterprise application integration and SAP (ABAP/XI) consultancy.
Focus on Application Support and Maintenance
Mncedisi KasperTHE SuppoRT And MAinTEnAnCE oF An AppliCATion should never, ever be an afterthought. Since over 80% of an application’s lifecycle 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 pro- duction environment have different purposes.
Here are a few of the disadvantages that an administrator faces:
• An administrator can’t resubmit a request message to reproduce the prob- lem. When you’re in production, you can’t reissue a financial transaction against the “live” database to see what went 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.
114

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.
• Involve a support lead 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 (especially your boss).
Mncedisi Kasper is a director of technology and strategy at Open Xcellence ICT Solutions, a South Africa–based company specializing in enterprise application integration and SAP (ABAP/XI) consultancy.
相关文章推荐
- App调试内存泄露之Context篇
- 案例分析-引导设计
- Android插件化开发之OpenAtlas插件的安装与卸载、更新与回滚
- IOS 收集的一些第三方库
- 使用Core Graphics绘画一个山寨微信icon
- HTML5仿Apple Watch时钟动画
- Android Studio 提示错误 default activity not found
- Masonry教程--IOS自适配,丢掉Autolayout吧
- android 自定义Button,满足你对Button呈现样式的一系列要求
- android 自定义Button,满足你对Button呈现样式的一系列要求
- UIWebView与JS的深度交互
- 通过iOS 9 SFSafariViewController提供完整的Web浏览体验
- android学习笔记(1)
- 源码推荐(8.26):毛玻璃效果,学习iOS开发技巧及第三方包的DEMO汇总
- android 在一个应用中启动另一个应用
- iOS开发系列之Objective-C基础:NSString字符串类型(二)
- iOS label 加下横线
- Android应用开发(二):Activity生命周期剖析以及如何启动新的Activity或网页
- Android应用开发(二):Activity生命周期剖析以及如何启动新的Activity或网页
- iOS 导航栏透明 去掉黑线