从架构到产品——从集成到产品化的转变之思

[从兴公司 - 陈百平]

很多年前，领导问我：我们做了GMCC网站，能否将其做成产品？这样当其它公司有网站建设需求时，我们就可以直接将产品部署上去了。当时的我一脸惘然，因为那时我对软件产品的概念浑然无知。

集成项目做多了，作为公司的高层或营销人员，自然想有一个产品的东西直接拿去兜售。卖一套是一套，最好压根就不用开发人员参与：将产品给客户装一装，再简单配置一下，就可以使用了。但是，我们所做的集成项目并不是产品，无法通过更改配置实现客户的需求。营销的同事又不能对客户说我们没有产品，无法满足客户需求。于是，营销的同事只好天马行空地给客户描述我们的“产品”有这个那个的功能、是多么多么的优越、并且会如何如何的好用，经常会达到老子哲学的境界：无中生有。作为开发人员没能做好营销人员的后勤，每次我都觉得很惭愧。经过营销人员天花乱坠的陈述，客户选中我们的“产品”后，就轮到我们开发人员加班加点地开发以满足客户的需求。经过这样没天没夜的干活，开发出的系统也更特殊了，更没有通用性了。

很多年后的今天，当领导再次要求将我们将网通的网上营业厅弄成产品时，我脑子里还是一片空白。因为对于一个网站应用，页面设计是无法重用的。界面的东西有版权，总不能直接抄袭吧。后面的业务逻辑也是基本无法重用的，因为每个公司的业务总有些不一样。而因为这些不一样，对于一个具体项目来说，会导致重用业务系统的成本比重写系统的成本要高。再加上项目的赶工期，从而最终导致大家到喜欢重写业务系统，而不是重用业务系统。

一说到重写系统，很多人都会连连摇头，认为这是浪费资源。但我觉得这是无可避免的！因为我们目前的水平也只能是这样。可喜的是，我们已经开始意识到这一点，并开始思考系统重用的问题。对于一个网站应用，剥去无法重用的界面，同时也剥去难以重用的业务逻辑，剩下的，你会发现只有架构了。这几年架构满天飞，也说明了大家都开始认真思考软件产品化的问题吧。

但我们目前的优势并不是架构的开发，以后一段时间内也不是。相对来说，我们还是一个倚重集成的公司。于是，在向产品化的发展中，我们必需重新反省我们的营销手段、重新反思我们的开发模式，进而重新定位我们的营销方式、重新寻找我们的技术方向。

我想集成与产品的区别，从其解决问题的方式来说，大概是集成是解决一个特殊的问题，对于特殊问题中的共通部分则可使用产品实现；产品则是解决一个共通的问题，对于特殊的部分能够通过配置完成。

这个共通与特殊，是我们最难把握的。我们可能经常会遇到以下两种情形之一。一种情形是我们想把一个集成项目改造成产品，经过一番讨论研究后，发现很难改，因为项目一开始并没有采用产品化的设计思路。另外一种情形是我们一开始就想把一个项目规划成一个产品，但在用户不断变更的需求下，我们最终会惊讶地发现这个产品竟然神奇地变回一个集成项目。

从技术方面来说，从多个特殊中抽象出共通，这是从集成走向产品化的第一步。但产品化更重要的一步是将这共通的东西能通过配置完成特殊的需求，这也是我们最弱的地方。如何改善我们的短处，单单靠领导不断声嘶力竭地喊产品化是不够的，仅仅靠技术人员整日苦思冥想也不行的。如果将领导的产品化意识再加上我们这些技术人员的努力又会如何呢？我想还是难以达到目的。对于像我们这种一路做集成过来的，让我们做产品无疑有点闭门造车。我们所缺乏的不仅仅是技术。

但作为技术人员我们所能更深入探讨的却还是只有技术。虽然我们所缺的很多，产品化的道路还很漫长，我们仍必须上下求索地走下去，因为这是我们的责任所在。

不管如何，毕竟我们已在产品化的路上迈出了一步：架构重用。无论这个架构是我们自己艰辛积累的，还是顺手拿来的。我们既然勇敢迈出了一步，自然要迈出第二步：产品化。如何做？不知道！我真的不知道，从来没有学习过，也不曾有人告知过。自己只好去分析已有的架构，希望能得到些许的启发。当我仔细探究像 spring这些优秀的架构时，开始我弄不明白为何这些架构的设计如此之复杂、配置如此之繁琐。后来才渐渐明了，因为有了这些配置，这些架构才可以在不同的场合伸缩自如、随需应变。

架构这个东西除了可以直接使用外，如果我们对它进行认真的分析，确实可以获益匪浅，很多都可以借鉴到我们的产品开发中。架构这种良好的设计模式、规范的系统配置、清晰的演进思路都是在实践中反反复复的不断添加、精简、归纳而形成的。因而，我们做产品也应踏踏实实的做，不要期望我们能一蹴而就。

在业务方面我们已做得比较优秀，如果在产品化方面我们做得同样优秀，我们将所向披靡。

注：以上文章版权归立信集团《沟通》所有，不得转载、引用。