不知道大家是否知道什么是SOA，小婧是经常在一些产品宣传上看到这个词，号称支持SOA可扩展的柔性建构体系。
很多人说，这明显是技术的部分啊，什么平台架构，什么技术路线，应该是开发和SA应该去关心的事情，和我们做业务做产品的有什么关系呢？
我以前也是这种想法，所以虽然经常听到，但是一直没有关心过研究过。
最近刚好有个机会学习研究了一把，要是再有人说SOA与业务无关，我觉得可以关小黑屋好好反省下了。
言归正传，我来和大家讲一下我对SOA的理解，以及作为业务的角色应该为产品实现SOA做什么。
什么是SOA？
Service-Oriented Architecture，SOA是一种软件架构，它的主要组成部分有：
- Application Frontend应用前端
- Service服务
- Service Repository服务库
- Service Bus服务总线
很抽象是不是？我来打个比方。
你收到消息你家老祖宗在美国、瑞士、澳大利亚的本地银行都留了遗产，你想知道这事是不是真的，如果是真的有多少钱。
常规的做法是，你分别联系（打电话或者发邮件）当地的好几个机构，或者花钱请当地的调查机构帮你查。这里面面临几个问题：语言不通，时差，数据的准确定性，代价等等。
想想就觉得很麻烦。
如果有了SOA就不一样了。
你将你想要查询的内容输入到系统前台界面中，SOA的服务总线就自动将中文翻译成各个目的地国家语言，并且将你想要查看的内容告知各个机构，然后计算、返回结果，再翻译成中文告诉你。
SOA有什么用？
我们顺着上面的例子说。
首先，不论你的系统使用什么语言、什么架构什么协议，对方的系统使用什么语言、什么架构什么协议，只要你将你的需求用你的语言表述出来，SOA自动"翻译"。
在这个过程中，你不用担心你的信息被窃贼拦截，因为人家自带安全体系。
查着查着你发现在遗产其实在日本，但是日本没有接入进来，可以很方便的把它接入进来，而不用去考虑日语与中文的翻译问题。
回到我们的现实世界，现在任何的应用的软件都不是孤立存在的，我们会希望提升数据的利用率，让数据流动起来用起来。
在这个互联的世界，SOA就显得更加的重要了。
业务人员能为SOA做什么？
前面铺垫了这么多，小婧今天想要讲的重点到了。
不论你家产品是从0到1，从1到N，从-1到1，如果要想实施SOA，就面临一个问题：建模。
说通俗了，就是你怎么知道你要提供什么服务Service给别人，别人要什么呢？
有一个分析和设计SOA系统的模型叫做SOMA，它就是用来分析建模的。
它分为三个步骤，其中业务人员要全程参与，主要负责前1.5个步骤。
第一步：定义
业务人员需要整理产品作为一个黑箱分析可能与哪些系统产生关联关系。
这里面涉及到产品的战略及定位。
很明显这是业务人员需要关注的内容，特别是业务人员对未来的设想和发展的路线规划。
比如我们想要完成一个用户场景use case，其中会涉及到三个系统，那么这三个系统分别对应流程的哪些活动？
这些都是我们业务人员需要去分析的。
第二步：描述
我们定义好了我们可以提供的和我们需要的，那么接下来就是要进行进一步的描述了。
这部分工作的前半部分是需要业务人员主导的，后半部分是需要SA或者开发人员主导的。
我们重点说一下前半部分。
在第一步中其实我们就是定义了有或者需要哪些服务，那么：
这些服务之间是什么关系呢？
他们处于业务流程的什么位置上呢？
涉及到哪些功能和数据呢？有什么约束和规则限制吗？
有什么非功能性的需求吗？
这些都是业务人员需要去整理清楚的。
第二步的后半部分就是开发人员要去主导的，比如确定具体的服务组件、技术组件等。
当然业务人员也要参与其中。
第三步：实现了
因为SOA其实并不是一个小工程，特别是对已有产品想要实现SOA可能会面临大量的代码重构。
所以会建议先找影响不是很大，对SOA依赖比较重，业务价值大的先进行试点实施。
在不断的总结和积累的基础上逐步实现整个产品的SOA。
从上面的整个过程来看，SOA是要以业务为驱动的。
业务人员当然应该了解并参与SOA的建设中了。
写在最后：
而我觉得在整个产品的生命周期中，就应该让专业的人去做专业的事情，比如业务人员就应该把业务分析清楚，整理清楚，技术人员专攻技术难题和技术实现，而作为技术人员不应该去插手业务的决策（特别是这个场景到底是否存在），而业务人员也不要对技术人员的工作指手画脚。
大家交流提建议是赞成的，但是不要太多的去干涉专业人员的判断和工作。
所以，不要再认为SOA是纯技术的事情，作为业务人员也应该参与并主导相关步骤，实现真正的SOA。
嗯，欢迎技术人员前来拍砖！
小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
