业务平台的核心
 |
faye.feelcool
2010-03-25
好久没有写文章了，主要是近段时间都在做着应用产品的设计和编写工作。做了一段基于平台的应用，对平台也就有了更加深刻的见解。
做应用软件其实不需要那么多虚的，尤其是针对中小企业用的应用软件，更加需要直接，所以对平台的要求更加的精炼。而这些必不可少的功能要求，我想就应该是一个平台的核心支撑了（架构的核心机制不论，那属于平台内部所采取的架构策略和技术策略）。 一个WEB版本的应用，如果需要借助平台的话，它需要如下方面的支持：页面、数据访问、流程、组织、权限。也就是说如果一个平台能支撑这些的话，在做应用的时候，是十分的快捷的（这也是平台的初衷）。对于在技术实力和经济实力不强的团队来说，页面和数据访问可以使用业界通用的技术来解决，那么只需要要处理好流程（可以选用相应的中间件组件）和组织及权限就能很快搭建一个能够提升开发效率的平台了。 这样看来一个业务平台的核心就是：流程、组织、权限。 欢迎拍砖。 |
 |
凤舞凰扬
2010-05-04
其实将楼主所说的组织，改为组件，或者说业务模型组件，个人认为更为恰当。对于业务系统来说，业务流程及业务模型都是动态和发展的，一个好的业务平台必须要适应这个特点，其实对于组织、权限来说，他们都是相对固定的，除非出现组织机构重组之类的事，否则变动的范围和可能性都比较小。而对于流程、业务模型来说，它们的动态组合、它们的变动替换都会由于理解的不同、需要的不同、企业发展的情况不同而出现比较频繁的变动。一个好的业务平台必须要有一个灵活而又稳健的流程定义及控制功能，同时，也要有一个容易扩展和替换的业务模型组件架构，能确保组件间的消息能够有效畅通的进行通信与交互。
其实说到这，楼主会发现，它和SOA （SCA, BPEL/BPMN）的思想不谋而合了....... |
|
faye.feelcool
2010-05-26
你可以这样理解为业务模型组件，我单独提出来的目的是将业务模型组件进行一个简化，比较核心的就是组织和权限。其它的都属于业务应用领域的东西，做平台的，如果不了解的话，可以不去处理这些东西。当我们在某方面的应用比较多后，在总结下沉下来。
|
|
凤舞凰扬
2010-06-10
其实组织也好，权限也好，我们可以将其表述为公共组件，或者说是公共业务组件。可以说它们是业务运作的核心（并仅仅限于IT系统）。
但是对于IT系统，尤其是系统平台来说，它们应该一个可插拔的，或者说与平台无关的。平台是可以移植的，平台是可以与具体公司无关的，但组织和权限就不一定了（尽管大多数公司的组织结构模型相似，权限管理及分配相似，但是它们始终都是受公司个体的影响的）。 对于平台来说，一个良好的组件插拔模型及组件间的高效的通信机制才是真正需要关注的。而基于业务流程的编排与组合，面向业务流程的管理和治理，才是业务平台最核心之处。 对于各个不同业务平台开发商而言，它们和核心竞争不是谁的组织结构与权限做得好，而是业务组件的插拔管理，业务流程的编排及管理。 |
 |
CshBBrain
2010-09-22
引用 “平台是可以移植的，平台是可以与具体公司无关的，但组织和权限就不一定了（尽管大多数公司的组织结构模型相似，权限管理及分配相似，但是它们始终都是受公司个体的影响的）” 我觉得说得有些道理，比如有的单个公司的组织机构和集团公司的组织机构差别就很大；而衍生出来的权限控制差别就更大了。 其实我觉得业务流程的编排和管理也受组织机构类型的影响，以前我所做的都是用于单个公司的系统，对于流程节点中执行人很好计算。但用于单个公司的流程节点执行人计算方法在集团公司中就行不同了。 有时就相同的业务但在不同的公司中处理的业务流程大不相同，而有些公司又是相同的。有时候流程节点的执行人是不能跨出业务单据所在的部门的，有时必须是跨部门的，有时候跨公司；我也研究了不少其他的工作流引擎，好像目前还没有能支持集团公司业务流程的。。。。。。 |
|
凤舞凰扬
2010-10-15
其实楼上说的已经超出系统内工作流引擎职责的范畴了。
BPM应该是一个不错的选择，可以去了解一下。 |
