《实用软件架构:从系统环境到软件部署 》——第1章 案例研究1.1 业务问题

第1章 案 例 研 究

我这个人专门解决难题,有什么事尽管拿来问!

生活脱离了环境,就如同船没有了帆。环境使得我们可以专注于手头的工作,它能给人一种方向感,也能给人提供一个理由,使我们觉得完成某件事情是值得的。信息技术(IT)和计算机工程等领域中的架构也是如此,它同样需要有一个存在的理由。我们必须对架构进行实例化,必须按照需要将其实现出来,以解决实际的问题。

笔者将在本章中描述一个虚构的案例,以演示问题的陈述。尽管笔者不会明确宣称它与某个真实案例有所对应,但读者在工作中或许真的就会遇到这么一个类似的案例。这种描述实际问题的案例研究,能为我们提供一个环境,使得IT或软件架构中的元素可以在这个环境中呈现出来。该环境可以说是软件架构得以存在的客观理由。

1.1 业务问题

有一家名为BWM(Best West Manufacturers)的重型设备生产公司已经拥有稳定的客户群,主要开展机器和重型设备生产等传统业务。

行业展望分析和独立分析师的研究报告都指出:未来几年中,BWM公司通过与新客户签订设备购买合约来增加其市场份额的机会是相当有限的。

董事会为此举行了将近两周的闭门会议。在经过多番构思和头脑风暴之后,参加会议的人员对会议成果进行了总结,并将其作为业务指示,传达给了公司的高层领导。他们要求公司极力提升现有客户群对售后市场的关注程度,并想办法使客户在售后市场中进行大量消费。

公司的高层管理者分析了董事会所下达的指令,他们认为公司必须把注意力集中在怎样向客户提供更多服务上。这意味着BWM不仅要做好设备本身的销售工作,而且还要提供更多的增值服务。这些服务可以帮助客户提升机器的使用效率,从而最大限度地提高生产量,也可以帮助客户减少意外的停机检修时间,还可以帮助客户尽早预见有可能出现的故障。

1.1.1 技术挑战

为了在提供机器的同时,向客户提供一套高价值的服务,BWM需要打造一个高水准的IT系统作为公司的基本骨干。要构建这样一个健壮的企业级系统,就必须具有相关的IT知识,以便对其进行概念化、表述、架构、设计及构建,但公司内部现在明显缺乏这样的专业知识。

于是,很多问题接踵而至:

公司缺乏软件开发技能及专业知识。

公司对时下流行的先进技术接触得不够多。

公司对软件开发方法论接触得不够多,也没有足够的经验及专业知识。

公司没有一个能够安置企业级系统的IT基础设施。

技术团队在得到了公司的资助和支持之后,决定聘用一家顾问公司,来帮助本团队实现转型。于是这家顾问公司就过来了。

顾问公司把重点放在解决方案上,他们先挑出几个使用场景,然后将其表述成用例,以便使团队成员能够对即将要构建的这套解决方案所具备的复杂度、关键点和相关能力,有一个适当的了解及领悟。

本章将会描述其中某些关键的用例,这些关键用例具备如下特点:

它们主要是业务方面的用例。

实际的用例数量是比较多的,而本章所描述的用例只占其中的一小部分。

这些用例采用简单的语言和宏观的视角来描述,其中不包含技术表现形式或技术细节。

1.1.2 用例

在接下来的几个小节中,我们要描述几项系统特征,以刻画本系统所应提供的核心能力。这些能力用来表示一个可以完全发挥其能力的IT系统,该系统会参与到一个更大的生态环境中,该环境里整合了点对点的供应链,其中包括设备销售和售后市场的增值服务(这是本IT系统的重点所在),也包括优化之后的零部件供应库存。

下面将要演示四个用例,它们会构成本次案例研究的主题。

注意:     本书所提到的“IT系统”,都是指正在构建的这个系统或应用程序,而本书所提到的“系统”,也应视为“IT系统”的同义词。此外,在进行案例研究时,机器与设备指的是同一个概念,因此,这两种说法可以交替使用。

1.1.3 在机器运转过程中进行实时处理与监控

系统应该能够处理从机器的仪表中所传进来的数据流,并实时地计算出关键性能与监测指标,也就是说,当数据从机器中的数码传感器等仪器内产生出来时,系统就要对其进行实时的处理与监控。许多项指标可以合起来形成有足够分量的信息,无论是哪种类型的机器,我们都可以通过这些由实时处理与监控而得到的信息,来了解该机器的状况。

实时处理的过程,应该发生在数据写入持久化设备之前。对于任意一台机器来说,每隔几毫秒就会有一条数据从中产生出来,而且多台机器也有可能会同时产生数据。

计算出来的指标,会写入持久化存储设备中,同时也会展示在可视化的监控面板中。该面板会按照数据的计算速度和生成速度,来更新其中的信息。

在发挥并利用这项能力时,IT系统主要是与现场工作人员和监控主管进行交互的。

1.1.4 为新机器提供无缝的激活服务

这个系统应该是个随加随用的(on-board)系统,也就是说,用户要能够随时给其中添加新的机器。系统不仅要能够无缝且透明地支持新的机器,而且还必须迅速地完成这一过程。

客户购买了某台新机器之后,这台机器应该能够自动激活。也就是说,当客户初次使用机器,并且有数据从机器中的仪表里产生出来时,该机器就应该自动地向IT系统进行注册,以激活相关的服务。

此处所谓的无缝,意思是说:IT系统在几乎不需要由用户来干预的情况下,即可处理好与新机器的添加有关的各方面问题。这包括收集工作现场的机器数据,将监测到的仪表读数实时展现出来,进行前瞻式的诊断,以及自动生成后续的工作定单(以应对机器中有可能出现的异常状况)。

在发挥这项能力时,IT系统主要是和超级用户(Power User)进行交互的。

1.1.5 生成工作定单

系统应该能够提前判定并生成维护所需的工作定单(work order)。它应该要能察觉到机器在运作过程中所出现的错误,并且要能在机器本身或其中的某个部件即将发生故障或崩溃时,提前将这一情况预测出来。

系统要能够智能地评估出机器所遭遇的状况到底有多严重,并且要判断出有没有可能把维护过程放在下一个维护周期中执行。在进行判断时,它需要决定是应该生成并立刻执行相关的工作定单,还是应该等到下一个维护周期再去进行维护。如果决定采用后一种办法,那么系统还要给相关人员发出警示信息。

整个这套流程都应该是自动化的,然而到了最终的验证环节时,维护人员可以决定是否真的要把系统所生成的工作定单中的指令,运用到机器上。

在发挥这项能力时,IT系统主要是和维修主管进行交互的。

1.1.6 尽量减少在为全球客户提供服务时所产生的延迟

系统不应该给用户留下一种运作较为缓慢的印象。用户与系统之间的交互,以及系统所给出的响应,都应该比常见的企业级系统更加迅速,以防用户失去耐心。

系统要把分布在全球各地的用户全都覆盖到,但这并不应该增加系统的延迟时间,也不应该使系统的吞吐量变低。

系统要根据时间方面的敏感度和关键度,来对各项特性进行归类,并且优先保证那些较为敏感且较为关键的特性,可以具有最小的延迟时间和最大的吞吐量。比如,“在机器运转过程中进行实时处理与监控”,就是一项对时间要求比较严格的特性,因此,系统不应该给用户留下响应速度比较慢的印象,也就是说,系统要能够迅速展示机器的性能和监测到的指标等信息,以便给用户呈现出一种实时刷新的感觉。

无论什么人与系统相交互,这项特性都应该得到体现。

本章提到的这四个用例,应该视为IT系统所必须体现出的一些重要能力。这些能力,通常都是用上面所展示的业务用例来进行描述的。

此外大家还要注意,业务用例(business use case)与系统用例(system use case)是两个不同的概念。在进行用例分析时,我们固然不能陷入其中而无法自拔,但同时,却也必须意识到业务用例与系统用例之间的区别。前者说的是系统应该提供“什么样的”能力,而后者说的则是系统应该“怎样”来实现这些能力。用例的定义,本身就是一门学问,我们要把它放在整个软件开发生命期的第一个阶段,也就是需求收集(Requirements Gathering)阶段中来完成。

时间: 2024-10-26 00:56:01

《实用软件架构:从系统环境到软件部署 》——第1章 案例研究1.1 业务问题的相关文章

《实用软件架构:从系统环境到软件部署 》——第3章 恰到好处地把握架构中的重要方面3.1 软件架构中需要关注的一些方面

第3章 恰到好处地把握架构中的重要方面 你把边界定好,看我怎么在里面大显身手. 第2章强调了一些理由,那些使我们确信:凡是要开发具有一定规模的系统,就必须要重视该系统的软件架构工作.看完该章之后,读者可能会去详细地了解各种架构视图和架构视点,或是去阅读不同的软件架构学派就软件架构中的其他一些方面所写的文章.现在,你可能会想:"架构中最需要关注的是哪些方面呢?我应该从哪里入手呢?面对下一次架构工作,我是否能有充足的准备呢?"能够想到这些问题,那是相当自然的事情. 这是一本注重实效的书,笔

《实用软件架构:从系统环境到软件部署 》——导读

        前言  软件架构这个学科已经有半个世纪的历史了.此概念于20世纪60年代引入,它的灵感来源于建筑物的架构,其中涉及在开始盖楼之前拟定的一些蓝图,这些蓝图描述了建筑师对建筑物的结构所制定的设计方案与规格说明.建筑物的蓝图给出了建筑物在功能方面的设计方案,也就是楼层的空间布局示意图,以及每个建筑工件(例如门.窗.房间.浴室.楼梯等)的尺寸.在使建筑物得以运作的那些方面,蓝图也提供了详细的设计方案,例如承载建筑结构的地基.电线.水管和输气管道的设计,以及下水道系统等,要想使建筑物的功能

《实用软件架构:从系统环境到软件部署 》——1.2 小结

1.2 小结 要想把软件开发的各个部分全都维系起来,IT系统的架构可以说是至关重要的一个元素. 在解决当前的问题时,我们经常容易采用过于庞大.过于宽泛的理论来描述它,即便是专业的软件架构师和系统开发者,也有可能会陷入这种状况中.因此,软件架构师在解决问题时,通常应该先缓一步,仔细想一想:我是不是把这个问题解释得太复杂了?我是不是把这个问题推广得过于宽泛了?我是不是对IT系统的架构做了过多的处理? 通过进行案例研究,我们可以为待解决的问题创造一种环境,并为其划定边界,这样做使得我们能够专注于目前所

《实用软件架构:从系统环境到软件部署 》——2.4 架构视图与架构视点

2.4 架构视图与架构视点 以软件架构为论题的书籍.文章.研究项目及相关刊物,都会带有各自的观点.不同的流派对架构有不同的看法,他们会按照各自的看法来做架构,并会将各自的做法加以推广.就本书的主题来说,笔者并不打算专门用一个章节把与软件架构有关的各种观点全都讲解一遍,而是只想展示下面的这种观点,因为笔者觉得它比较务实,而且运用起来较为流畅. 视图和视点 Philippe Kruchten (1995.11)率先开始使用视图(view)与视点(viewpoint)这两个概念,来表达业界对软件架构的

《实用软件架构:从系统环境到软件部署 》——第2章 软件架构是什么?为什么需要做软件架构2.1 背景知识

第2章 软件架构是什么?为什么需要做软件架构 除非我信它,否则不可能全身心地投入其中. 如果你已经读到了这里,那么你应该是真心想要成为一名"务实的软件架构师".我们不能仅仅把这个名号挂在嘴边,而是要在实际的软件与系统开发工作中运用这套理念做出优秀的产品. 软件架构师的做事风格多种多样,而且通常都很有意思.有的架构师喜欢做宏观的思考,喜欢随便拿一张纸画上几笔,或是在白板上画一些方框和线条,而且那些方框看上去好像长得都不太一样.有的架构师不先把宏观的架构情况了解清楚,就急着去研究细节问题.

《实用软件架构:从系统环境到软件部署 》——2.3 为什么需要做软件架构

2.3 为什么需要做软件架构 笔者是这样一种人:除非我能确信自己真的需要去做某件事,并且了解它的重要性和价值,否则,我就很难全身心地投入其中.如果读者也是这样的人,而且你也想了解软件架构的价值到底体现在哪里,那么就请继续往下看吧. 本节将会给出一些理据,来说明软件架构的重要意义.笔者之所以会极其热衷地从事架构工作,正是由于这些理据能够使我感到信服. 2.3.1 把架构视为交流工具 软件架构是一张蓝图,IT系统的设计.构建.部署.维护及管理,都要依照这张蓝图来进行.很多利益相关者都想对系统架构有一

《实用软件架构:从系统环境到软件部署 》—— 3.2 小结

3.2 小结 做事恰到好处,是一种极其难得的境界,很多行业的工作者都缺乏这种智慧. 笔者在本章只是确定并(非常简短地)描述了架构中的某些方面,它们是软件架构开发工作得以成功的必要和充分条件. 首先我们要从系统环境方面来考虑,把IT系统当成一个黑盒,并且只描绘出这个黑盒与外部的其他应用程序及系统之间的连接和信息交换情况.架构概述可以展示出系统架构中的构建块(ABB),并使架构师可以由此对系统的内部情况有一个初步的了解.功能模型使得架构师可以看到架构的子系统视图,该视图不仅能够对各项功能进行系统化的

《实用软件架构:从系统环境到软件部署 》——2.2 软件架构是什么

2.2 软件架构是什么 系统工程领域中的很多研究团体和个人,都对软件架构给出了自己的解读,他们从不同的视角阐述了怎样才能把软件系统的架构较好地表示出来.这些解读方式或视角,都有其合理的地方,它们本身并没有问题.笔者认为,Bass.Clements和Kazman (2012)给出的解释抓住了软件架构的本质: 程序或计算机系统的软件架构,指的就是系统的结构,该结构由软件组件.外部可见的组件属性,以及它们之间的关系而构成. 那么,这个定义意味着什么呢? 这个定义想要强调的意思,是说软件架构由粗粒度的构

《实用软件架构:从系统环境到软件部署 》——2.5 小结

2.5 小结 人类必须首先确信自己所从事的工作是有价值的,然后才能全身心地投入其中,我们必须首先确信自己所做的工作会有成效,然后才有热情去做好这份工作. 笔者在本章中向大家阐述了自己的想法与信念,笔者认为软件架构是有价值的.因为软件架构是否明确,与软件系统能否成功之间是有着一定关系的.于是,笔者就给出了软件架构的定义(软件架构是什么?),并且强调了它的价值(为什么需要做软件架构?) 本章还介绍了架构视图与架构视点这两个概念,并且简要地描述了一套笔者经常会参考的视点库. 第3章将要强调软件架构中的