Mike Kavis与我们分享了他们开发第一个SOA项目时得到的经验。我则对Mike认为的“我们作对的事情”进行了评注。
1. 侧重业务而非技术
“我们做了一个为期90天的业务流程评估，总结现状，并充分考虑未来可能出现的局面，制定了一系列不同投资回报比率的项目。”
评注：认识到项目与业务发展紧密联系的同时，Mike团队实际上已经走上了成功之路。 软件与技术的进步应该成为促进相关业务发展的重要因素。绝不能依赖无法准确评估的隐性效益。
2. 充分的准备
“我们参加各种讨论会，学习博客上的知识，研究相关网站，与有经验的设计师合作，努力获取任何SOA相关的信息。”
评注：这个道理是显而易见的。 不幸的是，太多的IT客户过分依赖他们的供应商，而没有充分地学习相关知识。 这将导致不健康的依赖关系，影响机构内利益相关者做出明智的决定。
3. 全面的POC模型
“我们花了大量时间做客户对BPM与SOA工具需求的评估。”
评注：耐心做客户评估，进行POC验证，充分了解你的合作伙伴。俗话说，强扭的瓜不甜，仓促地进行大项目开发绝对不是个好主意。
4. 挖掘人才
“我们在IT与业务方面都安排了最优秀的员工。 同时，我们还派遣设计师到有合作关系的SOA公司学习。”
5. 有力的决策支持
“我们的决策人是业务部门的人，也是为我们的项目筹集到最多资金的人。与我们IT部门的几个人一样，她将这个项目视为自己的事业，为争取四年内实现可观的投资回报率而努力。”
评注：虽然这是他们的第一个SOA项目，Mike团队对软件实现却有深刻的认识。出于某些原因，业务管理人经常不太情愿为技术实现交出自己的资源。而强力的决策支持可以让业务方面的人员更自愿地参与帮助技术实现。
Mike的决策人将她的事业与项目紧密联系在一起，这也是承诺与信心的表现。如果你的决策人没有购买自己公司的股票，那你最好赶紧换一个。
6. 即时处理阻力因素
“无论何时遇到阻力或消极因素，我们都会马上处理。”
评注：到处都有唱反调的人。虽然建设性的批评总是有用的，消极的却必须及时处理。 Mike在这方面做的很对，当然实际解决问题的时候肯定会遇到一些困难。
7. 通过迭代交付取得短期成效
“我们首先分析已确定的项目，然后结合需求与SOA路线图决定各个项目的优先级与应用范围。”
8. 健全的体系结构
“我们在为一个松散耦合的服务体系结构打基础……”
评注：不要拿项目计划表或技术体系开玩笑。无论在业务还是技术层次，准确、专业的规划都是至关重要的。
虽然Mike团队是第一次进行SOA开发，但他们在很多事情上做的很对。 吸取这些经验，你的企业软件项目必然会更加成功。
本文作者:佚名 来源:本站原创
CIO之家 www.ciozj.com 微信公众号:imciow
免责声明:本站转载此文章旨在分享信息，不代表对其内容的完全认同。文章来源已尽可能注明，若涉及版权问题，请及时与我们联系，我们将积极配合处理。同时，我们无法对文章内容的真实性、准确性及完整性进行完全保证，对于因文章内容而产生的任何后果，本账号不承担法律责任。转载仅出于传播目的，读者应自行对内容进行核实与判断。请谨慎参考文章信息，一切责任由读者自行承担。