如今，似乎每种产品中都或多或少存在着某种嵌入式计算机技术。汽车、电话甚至洗衣机都大张旗鼓地推出了各种交互功能。而十年前，这些功能是人们所无法想象的，即使有，产品的价格也比现在昂贵得多。

　　这些产品进入主流的原因很容易理解（图表1）。智能电话、电子导航设备和支持 Wi-Fi 功能的电视，以合理的价格提供了便利性、便携性和个性化特征。但这种进步的代价正在使 IT 架构1和设计日趋复杂。

　　过去五年的事实告诉我们，在汽车行业生产的每一辆新车中，高科技功能型发动机控制元件的平均数量，由原先的20个增加到了80个。而在手机行业，每年基于 IT的更新大约为40次，是2000年的两倍以上。虽然最近几年经济形势不佳，但新型飞机引入的驾驶舱的网络电话、风力传感器和电子飞行手册等航空电子功能的数量还是翻了一番。产品越来越需要基于电子技术的增强功能，因此，各个行业中的企业置身于快速变化的技术浪潮之中，时刻面临着产品升级的压力，它们拼尽全力，想要控制成本。

　　技术复杂性产生的问题

　　产品开发的步伐在设计和技术开发方面产生了巨大的挑战。传统的产品开发在很大程度上是由硬件方面的因素推动的。当您按下模拟电话上的一个按键时，只能拨出一位号码，这对它的功能造成了限制。如今的技术主导型产品依靠对多种软件和硬件组件的成功集成，这是一个涉及方方面面的过程。现在，按下新款智能手机上的一个按键，可以通过不同的方式连接到十多种应用程序上。

　　就本质而言，软件更加抽象，它们是在相互联系的层次上拼合起来的一连串程序代码。新产品设计底层的 IT 架构远比传统产品的规格复杂得多。例如，在进入数字化时代之前，各种吸尘器的工作方式大同小异。但在里面放入硅芯片后，您也许就能拥有一台 Roomba：一种由传感器和处理器控制的智能吸尘机器人。

　　糟糕的产品架构

　　开发团队常会被要求提供各种定制功能的呼声所困扰，不过，他们可能却没有意识到，如果事先决定的产品架构十分糟糕，那么，很可能会在下游产生代价高昂的后果。这些团队往往由电气工程师领衔，他们有时缺乏必要的软件工程技能，因此难以预测编程、升级或重复使用等方面可能存在的问题。这一问题可能会形成恶性循环：糟糕的设计决策和架构导致代码无法管理，并且增加了复杂性。例如，在汽车行业，一家制造商因电子问题被迫召回产品，从而蒙受了近3亿欧元的损失。这些设计失误可能会让一家公司的名声毁于一旦，而这正是某xx汽车制造商得到的教训。该制造商推出了新的用户界面，但事实证明，新界面极难操作，该制造商终因软件问题而破产。

　　过多地纠缠于任何单一产品的各种技术需求，可能会妨碍公司的思考能力，使之难以从更广的角度考虑如何在其产品组合中利用某些的特性和功能。这种失策也许会迫使企业采用一系列“一次性”的应用程序。苹果公司的工程师将新硬件（一种触摸屏）与更优秀的软件逻辑（一种直观、友好的用户界面）结合起来，成功地设计出iPod的触摸功能，而其他公司的工程师们却在为如何创造灵活的集成架构而大伤脑筋。例如，某家用电子产品供应商在每次升级产品时都不得不设计一套新的用户界面，与在产品开发中更多地利用模块化（或即插即用）方法的竞争对手相比，这是一大劣势。

　　缺乏与业务重点任务的密切联系

　　对于某些机构而言，更严重的问题在于，技术主导型产品面临的技术挑战往往与经营战略相冲突。

　　许多企业在开发大批量生产的硬件主导型产品方面拥有数十年的经验，例如，电视机、收音机和家用电器等使用寿命相对较长的产品。因此，这些企业一直以来都围绕着批量生产和效率来优化设计和研发流程。技术主导型产品的新时代已经到来，这些产品往往面向利基市场，产品变化的速度更快，这就要求企业拥有一套xx不同的流程和技能，而且在转变传统经营模式的过程中要花更长的时间学习。其结果是，企业面临着成本上升、周期延长和任务膨胀等巨大风险。产品经理们为了压倒竞争对手而绞尽脑汁，他们会要求实现新一代的设计改进，而这常常超出了现有技术的限度。热衷于利用某一应用程序之能耐的IT 开发人员，可能对某一组功能进行过度的设计。

　　要让产品战略取得成功并具有可持续性，就必须以业务因素推动技术因素。例如，为了始终如一地提供高品质的游戏体验，任天堂公司有意使其 Wii 系统保持了简单的底层架构，限制了功能数量，以利于遵循严格的质量和控制标准。消费者对这些特性感到十分满意，该平台也因此成为一款畅销产品。确保业务受众理解那些深入产品基本架构而且很不直观的选择是十分重要的，而其他一些公司可能忽视了这一点。

　　很多嵌入式 IT 系统具有抽象性，因此，很难描述其功能。业务部门中的非技术管理人员可能很难从成本、易用性和流程时间等角度，来判断功能和可选方案的适用性。例如，一家手机公司有过这样的教训：职权界线的不明确导致产品开发和工程两个团队为由谁来负责某个产品的功能、成本和时间表而争论不休。这种混乱使得完成该产品的时间过长，无法提供与公司的竞争对手相抗衡的技术。

　　在技术主导型产品环境中，软件和硬件组件的生命周期常常不一致，使得架构集成非常困难，这大大增加了成本管理的复杂性。如今艰难的经济环境更是让这一问题雪上加霜。经理们承受着沉重的压力，需要在节约成本的同时迅速将新产品推向市场。由于缺少兼顾技术和业务因素的明确的开发框架，开发团队常常会寻求快速搞定，或者寄望于“天才招数”，而不是去寻找更具有持久性的解决方案。比如说，为了赶上发布日期，某公司的工程师在设计设备时采用了已有的功能丰富但价格昂贵的第三方软件。这种做法虽然让这家公司实现了如期发布的目标，然而成本却超出了预期。

　　挖掘更大的价值

　　由于各行业中消费者对于技术主导型产品的需求都在不断增长，一些制造商正在解决这些问题，对产品的电子架构进行优化。

　　协调业务和工程设计目标

　　汽车和高科技等行业中某些企业之所以能够取得成功，其背后的关键原因在于用集成的方法来设计电子产品的架构。在实际操作中，这意味着要在产品构思与设计之间、单个产品的路线图与更广泛的电子平台战略之间进行协调，最终使产品管理中的业务方面与工程设计方面取得一致。企业只有设立了要求进行这种协调的明确目标，才能将客户和商业考虑因素都摆在核心位置，为开发流程和尽量降低不必要的复杂性打下基础。这种管理开发团队的优劣之别，能够使总体生产率相差十倍。

　　良好的架构具有一系列重要特性：它是模块化的，允许给各个部分加标签、储存起来并且应用在不同的产品中；它是按标准构建的，更容易集成；它是可配置的，可以让一个系统满足许多客户需求；它还是可更新的，基本勿需摒弃旧版本就能实施新功能。

　　这些特性看似简单，但是，知道什么是好的架构是一回事，构建这样的架构并使之保持良好状态又是另外一回事。设立正确的目标还需要清楚地了解任务的各个方面。考虑一下技术主导型产品由哪些东西构成。硬件、塑料、树脂、螺母和螺栓构成了“骨架”。晶体管、微电路和其他各种电子元件管理着信息的流动，就像生物的组织和血管。而软件则进行类似于神经系统的联系，指导和控制各项操作。这一层次化架构确定了产品的解剖结构，详细说明了用户界面、产品的工作方式以及产品与其他系统和组件的互动等各个方面。

　　采用透明流程

　　企业必须采用一种能够优化各层次协作方式的管理流程。该流程涉及工程、市场营销、产品设计和其他产品职能之间新的协作方式。IT 和工程开发团队之间的互动，有助于在市场对于功能的需求与企业对成本和时间周期的需求之间实现更好的平衡。当然，这一切应当限定在技术上可行的范畴内。如图表2所示，{zh0}的解决方案通常会在多种权衡因素间取得平衡。

　　在此架构的指导下，来自业务部门和 IT 部门的团队开始着手描述产品需求，并且解决诸如“买方受众是谁？”、“{zd0}的机会来自何处？”以及“什么是正确的功能特性？”等问题。在综合考虑了成本、预算和其他限制之后，团队会将有可能对客户满意度产生{zd0}影响的功能特性作为重点。这些特性将转化为一系列架构组件，在成本和性能方面，每个组件都有自己的优势和劣势。团队在{zj1}业务合理性和{zj1}技术合理性的可选组件方案之间反复斟酌，所得的答案确定了产品的底层架构。

　　在梳理出业务需求之后，团队将检验各种可选的架构设计方案。他们可能会发现，自己所需要的方案在商业上并不切实可行，或者必须进行太多的定制工作才能实现大批量生产。这些限制使团队不得不在自己需要的方案和现实方案之间反复斟酌，以便找到最适合的架构。这种反复的过程迫使业务和 IT 部门的视角相互融合，从而在产品的总体战略目标和以技术为主导的适当架构之间达成一致。

　　关注可行架构的局部

　　一家手机制造商需要制造一种在新兴市场上销售的低成本手机。根据业务要求，这种手机应当具有坚固耐用的设计和有限的功能。在经过反复设计之后，工程团队拿出了几套设计方案，这些方案侧重于能够经受恶劣自然环境的电子和机械部件，与之配套的是成本相对较低的小型处理器。另一家手机制造商打算争取 iPhone 的用户群，因此拥有不同的业务要求，青睐于更加复杂的内存密集型架构，该架构需要支持各种功能，即使提高成本，也在所不惜。

　　根据业务战略在不同的可选设计方案之间进行平衡，是对技术主导型架构进行优化的基础。架构框架的不同要素支持着产品性能的不同方面。例如，有些要素控制着面向客户的流程，定义软件和硬件的关联方法，或者指导着各应用程序之间的相互操作（图表3）。我们发现，团队可以通过主要关注架构的部分特定要素，权衡它们对于整体业务目标和产品功能的相对重要性，来简化这一过程。

　　我们看看某个竭力改进其燃油喷射系统的汽车供应商的经历。这家公司原先采用孤立的机制，在每次升级时，工程师会从头构建定制的 IT 组件。这种方法拖延了生产时间表，使该公司无法跟上其他市场{lx1}者的步伐。

　　该公司将提高投入市场速度作为主要业务目标，组建了一支跨职能的产品开发团队，该团队坐下来处理上面所说的重复设计过程。为了停止一切从头做起的做法，这支团队决定建立一个内部资源库，以便更好地利用现有技术。这些嵌入式软件系统和应用广泛的电子部件由架构的功能（域）层控制。为了简化开发并降低部件成本，该团队精心挑选出一些所需的燃油喷射硬件，并且找出了可以在多种发动机之间实现标准化的基本部件。为了加快开发速度，工程师和产品经理们决定利用模块化的软件和电子元件。这些软件和电子元件可以插入用于支持燃油喷射系统正常运行的各种应用程序之中。

　　最终，电子架构以相当于旧架构两倍的速度将产品推向市场，而且工作量更少。通过优化内部的电子设备，用简单架构取代复杂架构，该公司生产每一辆车都能省下一笔资金。整个系列产品所节省的资金累计超过1000万欧元。此外，该平台最初是为四缸发动机而设计，而现在可以用于八缸发动机，这为该公司进一步节省了成本和开发时间。

　　再举一个例子。某发电设备供应商迫切需要将新的风力发电机产品线投入市场。但是，用于这些风力发电机的高级控制设备遇到了一个重大障碍：该公司需要找到一种经济高效的方法来监测风力发电机向电网的供电量。该功能的业务要求表明，{zh0}的解决方案显然应当是具有低成本的控制设备，其架构应使其能够轻松地在整个风力发电机网络中大规模推广。

　　技术团队决定，将重点放在以功能域为主导的架构层来满足产品需求。技术团队与来自业务部门的团队举行了会议，针对系统流程的管理提出了三套可选方案：通用型处理器、微控制器和数字信号处理器。三种解决方案都能测量电力输出量，但每种都有各自的成本和优势。技术团队需要确保产品经理理解不同的权衡因素，以便他们能够共同为新的技术主导型架构做出{zj0}选择。

　　在权衡了三种可选方案之后，该团队发现，虽然通用型处理器具有易于安装和升级的优势，但支持处理器的硬件却需要单独购买，因此成本太高。数字信号处理器提供的分离的操作系统架构开发成本低廉，也可以监测基本的用电情况，但无法提供必要的计费和报告功能。这就使得微控制器成为{zj0}方案。它虽然成本较高，但使产品团队获得了完整的现成解决方案所具有的灵活性，因为所有必要的硬件和软件都已xx内置。

　　建立更好的产品开发组织

　　技术主导型产品的集成化开发需要同样集成化的管理方法。在一家成功的企业中，首先成立了由总体产品小组经理和首席技术官共同担纲的项目指导小组，由两人一起制定产品的平台战略并发出相关指示。在这一领导层下工作的业务和工程团队分别提出消费者需求和技术需求，然后，一同讨论最终方法的各个要素，并排定优先次序。两支团队将最终的架构汇报给产品小组经理和首席技术官，以确认这一解决方案能够满足公司在消费者、成本和市场交付方面的目标。他们还制定了一系列绩效指标，以量化成本和生产率效益，进一步细化自身关于待改进领域的构想。这种着眼于全局的过程有助于确保业务和技术团队集中精力处理最重要的功能，也就是与产品的总体战略目标息息相关的功能。

　　为技术主导型产品建立正确的架构，决非一项一劳永逸的工作。它是一个持续进行的过程，对于支持产品的生命周期尤其重要。当对正确架构的寻求上升为工程师和业务部门共同遵循的准则后，拥有技术主导型产品的企业就能在生产率、质量和成本方面获益匪浅。