在OEA中，我们使用了ArchiMate 作为架构语言，这是一个高层、简单的描述语言，之前我也写过一系列相关的文字，

• 架构语言ArchiMate － 开篇：企业架构语言ArchiMate介绍
• 架构语言ArchiMate － 语言结构（Language Structure）
• 企业架构框架和语言 TOGAF & ArchiMate 电子资料

很多人在学习的时候都会问到一个问题，有什么工具可以很好地支持它吗？几年前就有了，Archi，但没有中文版本。不过，现在大家可以下载中文版了，因为昨天我已经汉化了一个版本，我这也算为推广ArchiMate做一点个人贡献了：）

如果你想成为一个高层架构师，想学习ArchiMate，那么看看下面的一些截图，喜欢的话抓紧时间点击这里下载 ，说不定哪天下载失效了：）

、

一个公司有三种经营模式，像游戏代理的属于运营型，做企业定制项目管理软件的属于项目型；互联网的大多数属于面向大众的产品型。而不管是哪种类型，其实背后都是有产品的支撑，游戏本身的主题就是游戏产品，定制项目的终极目标也是产品，正因为产品的重要性，所以OPD核心关注的就是有什么方法来支持一个产品如何从无到有开发出来？

我们生活中到处都是产品，iPad、小米，超市里你看到的所有东西其实也都是产品，还有你买的汽车保险，你用的开发工具、游戏引擎，这些都是产品，只是不同类型而已。这些产品中，我们可以分为三种不同的驱动类型，游戏引擎之类的属于技术驱动，保险产品属于销售驱动，小米手机属于市场驱动。对于不同类型的产品，我们会有不同的产品开发方法，OPD关注的是市场驱动型的产品，这也是上面OPD架构图中为什么在商业这个线上画了一个市场驱动型箭头的原因。

下面我就简要说一下架构图中各个圈代表的是什么？

商业

我们听过红海、蓝海之说，这也是图中以这两种颜色为渐变色的背后原因。现存的市场由两种海洋所组成：即红海和蓝海。红海代表现今存在的所有产业，也就是我们已知的市场空间；而蓝海则代表当今还不存在的产业，这就是未知的市场空间。 我把它叫做现有市场和全新市场。在现有市场中，如果出现垄断企业的话，我们一般推荐选择细分市场，也就是生产改良产品。

对于不同市场我们有不同的问题可以促发自己思考，例如现有市场可以从以下方面想想：

• 有哪些竞争对手？谁在引领市场？
• 竞争对手各占多少市场份额？
• 进入现有市场的代价有多大？
• 竞争表现在哪些方面，是功能、性能、价格，还是渠道？
• 前三年计划占领多少市场份额？
• 竞争对手如何定义市场？
• 是否存在同一的行业标准？标准由谁制定？
• 公司是打算遵守行业标准、扩展标准，还是另立标准？（扩展标准和另立标准意味着进一步细分市场）

组织

人不能产生需求，但是可以激发需求的产生。任何产品都是由一部分人想出来的，也是由这部分人带着团队做出来的，所以组织对于产品来说是极其重要的一个维度。说到组织，大家想到的可能就是那种庞大的机构，然而现在快速变化的市场必然要求组织也能适应变化，这就要求组织也变得敏捷起来，这就需要把组织分解为很多高效的团队，这些团队的协作来形成一个精益组织。然而，我们都知道，现在很多产品，特别是IT软件，其复杂度已经比过去的几十年复杂很多，不仅仅是产品需求复杂度，技术学习难度，还包括知识型工作人员管理的复杂性。不管组织、团队多大，目标是什么，最终都要落实到团队中的个人，也许不能做到每个人都是优秀的，但至少有几个优秀的，其他的人也至少是合格的。那如何让每个人都能胜任自己的工作呢？这就需要我们从组织、团队和个人三个角度去管理，战略方针靠组织、落实贯彻靠团队、行动执行靠个人，这也是为什么对于组织来说OPD关心精益组织、高效团队和敏捷个人的缘由。

流程

大的企业靠文化、中型企业靠流程、小型企业靠个人，话是这么说，但任何一个企业的运作都必须由流程来完成，只是这个流程的成熟度到了哪一级的区别而已。如果说一个企业的组织机构是比较稳定不变的，那么具体流程应该是随需应变的，然而我们可以抽取出流程之上的一些方法来作为流程的基础依据，这也是OPD中对流程的关注点。我们重在方法，而不是具体指导每一个细节步骤应该由哪一个人来怎么做到。

作为一个产品，从无到有，OPD关注三个大的流程，或者说三个大的方法：产品管理、架构开发以及软件开发。

产品管理

架构开发

软件开发

架构

不同的软件产品需要不同的架构，随着云、物联网的应用，架构也越来越复杂。在软件行业中，我们开发产品，面对的用户是一类用户，也许会是来做多个细分群。如何从产品层面的复用来快速的反馈市场，获得商业成功，这是架构需要考虑的事情，而基于产品线工程的模型驱动架构可能是一个好的办法。

商业、组织、流程和架构是OPD的四要素，以上是对开放产品开发架构图的大致说明，更多内容请继续关注OPD主题blog。

OPD？这是什么玩意？google一下。忘记说了，最近google被封锁的厉害，那就百度一下吧。可惜，OPD找不出是什么。你今天你找不到是正常的，因为之前还没有OPD，而现在才开始有OPD这个东东。相信很多人听过敏捷个人了，这个词汇到现在已经很容易被搜索到了，敏捷个人创立以来，我一直未放弃对IT技术方法的实践和整理，而OPD就是我又要创建的一个东西，全称是Open Product Development。没错，是OPD，不是IPD，当然两者会有些关系，之所以我取Open，是因为我的IT产品开发方法大多数不是原唱，而是来自现有IT界中的已有方法，我只是类似在敏捷个人体系发展中占据的角色一样，我是一个集成者。OPD的工作无非就是把这些方法无缝的配合在一起，这个事情看起来考谱吗？

靠不靠谱不能太随意下结论，现在重要的是先了解一下OPD是什么，看看是不是适合你和你的团队需要？如果需要的话，如何去学习、掌握并用在实际的工作中。

 OPD是什么？

OPD  （Open Product Development），它是由敏捷个人创始人周金根创立的另一个新方法体系，这一个来自实践的开放产品开发方法，它结合了精益创业Lean、企业架构TOGAF、架构描述语言ArchiMate、业务分析知识体系BABOK、敏捷开发Scrum、软件产品线、模型驱动架构设计OpenExpressApp。

原本这些方法是针对产品开发过程中不同人群的方法，但是方法设计者本身并未考虑到不同方法之间如何去衔接配合，这就带来了好方法不能被很好地使用的状况。如何在一个产品团队中，利用好这些方法，定制成一个适合一般性团队的通用方法就是OPD需要面临解决的问题。OPD会提供一些产品开发过程中的理念、框架、方法和工具来帮助产品开发团队中各个角色，不管是刚加入这个行业的初学者，还是工作已久的丰富经验者，我相信大家都会有所新的收获。

OPD关注的是产品开发的完整生命周期，要想知道涉及哪些角色，最简单的办法就是了解一下原本的方法是干什么的，主要面向哪些角色？所以，接下来我会概况的说一下Open中所指引到的那些方法分别是干什么的，有什么用，给谁用的。

 Open指引的方法

• 精益创业 Lean： 这部分适合产品人员，帮助产品人员从无到有创建一个正确的产品

• 企业架构TOGAF：这是一个企业架构方法，来源于IT信息化领域的发展，其中对架构的分层以及架构开发方法值得IT产品开发人员借鉴。如果想初步了解TOGAF，可以看看我以前的文章 企业架构 － 开篇：TOGAF介绍

• 架构描述语言ArchiMate：在我实践TOGAF和研究模型驱动开发中，我发现了ArchiMate，一个架构描述语言，一张A4纸即可把图例都列出，东西不多却功能强大。如果想初步了解Archimate，可以看看我写的 架构语言ArchiMate － 开篇

• 业务分析知识体系BABOK：一个产品应该做成什么样子？我们都知道这是需求工程师去做了解需求，然而产品失败率却一直很高，原因在哪里？就是因为缺少业务分析，而BABOK就是这样一个知识体系，它可以帮助业务分析人员、需求人员、产品负责人等于产品业务相关的人更好地去做产品业务分析。想初步了解BABOK的可以看看我写的 BABOK – 开篇

• 敏捷开发Scrum：敏捷开发是现在软件开发企业常用的一种开放方法，它重在产品价值，适合整个产品开发团队，包括业务负责人，通过学习和反馈来完成产品开发。如果想Scrum方法的可以看看我写的 从IT方法论来谈Scrum

• 软件产品线工程 BAPO：软件产品工程是产品级复用，能够加快产品的开发和上市，BAPO是软件产品工程中的一个方法，代表商业、架构、流程、组织。模型驱动开发是产品线工程复用的一个架构模式，OpenExpressApp是一个基于模型驱动开发的开源框架，虽然已经历时多年未更新，不过原有的产品可以看做是模型驱动开发的一个简单雏形。模型驱动开发是IT产品线级别的复用方法，适合技术架构师学习。如果想了解软件产品线工程的可以看看我写的 软件产品线：四个主要方法原则，如果想了解模型驱动开发方法的可以看看我写的 MDSF：模型驱动开发（MDD）介绍 

这些方法怎么能够串起来

如果我们简化产品开发，那就是产品负责任决定产品方向，做正确的事，然后由开发团队来争取的做事。这其中有几个重要的岗位，那就是产品负责人，业务架构师和技术架构师，这可以堪比三驾马车，只要这三个人掌管的事情弄好了，之间衔接也好了，那么产品的成功性就会比其他产品大很多，所以OPD必须要从产品管理、业务架构和需求分析、以及架构三方面去集成方法。

从上面我们可以看到，这些Open来的方法囊括了以上重要岗位的部分，并且这些部分原有方法的交集很少。因为交集少，自然方法之间的冲突也很少，这正利于这些方法的集成。通过这些方法的集成，从产品概念提出，到产品开发发版，我们全生命周期都关起来了，这是不是很好呢？如果你有志于了解如何更好地从无到有的做一个产品，你不甘于只是埋头了解和一直做手头的工作，那么OPD将是开拓你视野的一个好东西，也是你所在团队一个提升技能的好方法。

更多

后续我会继续写一些OPD主题的文章，如果你喜欢OPD，那就关注我的博客吧。