Information about customer needs, the technical composition of services, and service performance are fundamental to effective service management.  Service modelling is a structured approach to utilizing this information to improve the way services are delivered.  Consistent application of service modelling provides the automation of processes and timely access to information.

Service Modelling: Principles and Applications

Service Modelling presents a comprehensive, up-to-date overview of the topic, presented in the context both of business processes, and of requirements stemming from the need to manage network resources. Vilho Räisänen delivers a justification for service modelling, and explains state-of-the-art concepts, frameworks and standards in detail.

Service Modelling:

• Provides a complete and illustrated overview of state-of-the-art concepts for service modelling, covering requirements and frameworks.
• Includes industry initiatives, conceptual frameworks, and the work of standardisation bodies.
• Discusses different modelling approaches, and the positioning of modelling of services in service management and in the wider operational context.
• Sets the modelling framework in the context of business drivers and modelling paradigms.
• Illustrates principles with real-world use cases, providing both fixed Internet and mobile network examples.
• Relates concepts to the work of TeleManagement Forum, giving practical examples throughout.

Service Modelling: Principles and Applications is an invaluable guide to service modelling for telecommunications and data communications professionals, including vendors, operators, consultants, training organizations, service and content providers, system architects and engineers for IP-based services.  Educational organizations, advanced undergraduate and graduate students on telecommunications and networking courses will also find this text invaluable.

本书的已经翻译为中文版本，本书中包含了针对电信行业的实例模型和介绍，图书内容介绍如下：

《服务建模:原理与应用》主要内容简介：服务技术的发展，不仅彻底改变了人们原有的生活方式，更从本质上促进了当代社会经济发展方式的转变。《服务建模: 原理与应用》以服务建模为主题，共分4部分：第1部分介绍了服务建模所需解决的问题，第2部分分析了实际应用中的服务建模框架，第3部分列举了使用服务建模的案例，第4部分则对《服务建模:原理与应用》的中心内容进行了总结，并提出了未来服务建模值得研究的一些领域。
《服务建模:原理与应用》可作为高校信息技术、管理和经济类相关学科电子服务方向的教学用书。也可以作为现代服务企业进行服务建模方面研究的工具书或参考书。

Related posts:

1. ITIL V3 Study Notes (2)
2. Stop to build CMDB for your IT – CMS是怎样炼成的？
3. 资产CI的一生

For as long as there have been computers, operating systems and business critical applications, there has been monitoring of these items to make sure they were working (available) and performing well for their constituents. In the early days of the computer industry (through about 1982) computer systems were vertical monoliths where a customer would buy “an accounting system” and that purchase would include hardware, systems software, and applications software. All of this usually came from one vendor so there was one throat to choke when it did not work.

Starting with the delivery of the PC, then Ethernet LAN’s and Novel Netware, and finally Windows Servers and the Internet, the industry reorganized along horizontal dimensions. A computer system was now a multi-layer cake and you could buy each cake from one of many vendors whose products were largely interchangeable with each other, and compatible with adjacent layers. So you could buy an Intel based server from one of N vendors, put either Linux or Windows on it, but a Java applications server from one of N vendors on that and then buy applications from thousands of different vendors.

This horizontal layering of the industry was heavily promoted by Microsoft and Intel (who “owned” two key layers of the cake), and also ushered in the tremendous innovation and price competition that continues to drive our industry today. Moore’s Law says that microprocessor performance doubles roughly every 18 months or so, and with those increases in price/performance come the more for less mentality that we have all become accustomed to.

With this freedom of choice at every layer of the cake however came problems. The first problem was complexity. There were now too many cooks in the kitchen which meant that there were both too many and not one single throat for the CIO to choke when something went wrong. The management software industry reacted to this by inventing a marketecture, Business Service Management (BSM). The idea behind BSM was to identify the key business services that applications or combinations of applications delivered to users (the ability to enter and order and ship the resulting product is a business service as is the ability of a consumer to transfer funds from one banking account to another), and to then map all of the software and hardware infrastructure that this business service depended upon and to manage that collection of linked resources as an entity.

While Business Service Management sounded like a great idea, it in fact ended up as a miserable failure. The reasons were:

• There were many applications for which it was just too hard to measure their performance (in response time terms). Web applications turned out to be pretty easy, but fat client Win32 applications written to proprietary client/server protocols turned out to be very hard. It turned out that for most enterprises, more than half of the business critical applications were in the hard pile (fat client/Win32) and less than half were the easy web applications.
• Many BSM frameworks relied upon scripts and synthetic transactions to measure response time and end user experience. However this approach failed for many enterprises due to the large number of applications that comprised a business service and how rapidly these applications were changing. For example if synthetic transactions were used to measure the performance of a set of transactions, and a company had 500 business critical applications (not a very high number – some companies have thousands), and each application was updated once a year, then that would translate into 10 updates a week for the monitoring scripts.
• The same is true for most passive monitoring approaches that rely upon templates to identify transactions in applications protocols. There are many products that can measure the response time of transactions from the perspective of the web server by attaching physical or virtual appliance to a span port on the switch that services the web server. However all such products require configuration to understand what set of granular http request/responses combine to create a transaction of interest. Maintaining these configurations across hundreds of applications and thousands of transactions proved to be a major impediment to instrumenting their service level in any kind of a broad and systematic manner.
• It turned out to be a nightmare to identify the hardware and software that supported each business service. This gave rise to the need for Configuration Management Databases (CMDB’s) that were supposed to get populated with the hardware and software assets and their relationships to each other. The effort to put in place a CMDB and to maintain it turned out to doom the CMDB projects and the associated BSM projects at many companies.
• The BSM vendors were unable to evolve their products at the same rate as the innovation of the vendors who contributed products to the layers in the cake. New devices (laptops that were not always connected), new protocols (ICA, VOIP), new operating systems (Linux), new languages (Java, C#), and new user interfaces (first the browser and then rich Internet applications) all occurred at a pace that no one vendor could keep up with.
• When the BSM vendors got overwhelmed by innovation, vendors of point monitoring solutions stepped in to monitor the newest layer or item in a layer.  This lead to a proliferation of monitoring tools which were not integrated with each other.
• When a problem occurred even if one had a BSM product and a CMDB it still horribly difficult to know exactly what path the failed transaction took through the entire hardware and software infrastructure. The BSM tools were rarely aware of every element of the stack and the tactical monitors that had been bought to fill in the cracks were not integrated with the BSM tools nor each other.

In summary we entered the age of virtualization and the cloud with both BSM and their supporting CMDB’s having failed at monitoring and managing a static infrastructure where applications and services largely stayed on dedicated hardware. In other words, before virtualization and the dynamic data center it was impossible for anyone in IT to see a problem and get told in a deterministic manner exactly where the problem was and how to fix it.

The Impact of Virtualization and the Cloud

Since holistic end-to-end monitoring of business services was essentially broken (or not attainable) before virtualization, it is reasonable to assume that virtualization and the cloud will only make this problem worse. This will occur for the following reasons:

1. Virtualization increases workload density and the dynamic operation of workloads. This will require both continuous mapping of application to infrastructure dependencies and more more frequent (near real time) collection of performance data. Just the requirements for real time mapping and real time data completely overwhelm existing monitoring systems. Hyperic has a good blog on this point here.
2. Inferring application performance from resource utilization statistics becomes impossible. This was possible on physical hardware, but on hardware that is shared via virtualization it no longers works. Hence the need for Infrastructure Performance Management solutions that measure Infrastructure Response Time. We expect Infrastructure Performance Management solutions from vendors like Akorri, CA Technologies (CA Virtual Assurance), Virtual Instruments, and Xangati to form the foundation layer of whatever will replace BSM.
3. Application will now get moved from cluster to cluster and ultimately from data center to data center (private cloud – hybrid cloud – public cloud). APM solutions will need to track the applications no matter where they go, and seamlessly work across different IP networks. Leading virtualization aware APM solutions like those from AppDynamics, BlueStripe, and New Relic meet these needs today and will likely form the APM layer of whatever replaces BSM.

All of the above together combine to create one new result for Systems Management. That new result is that in the general case it will be impossible to deterministically do root cause in a dynamic environment. This was explored in detail in this post.

The Significance of the Integrien Acquisition

The Integrien acquisition by VMware is significant because it means that VMware has recognized that only a dynamic, statistical, self-configuring,  and self-learning approach can keep up with the rate of change in these new dynamic IT environments. The self-learning approach simply means that you feed the system the metrics that get collected about the system and it figures out which ones are important, how the metrics are related to each other, and lets you know when anomalies have occurred.

This acquisition is all the more significant because this is not garden variety technology. There have only ever been three companies this this space. ProactiveNet was acquired by BMC a few years ago. Netuitive has been around since the late 1990′s and it took the company until the mid 2000′s before the product had matured into something that really just worked when you plugged it in. Integrien is a fairly recent entry in this field and is now part of VMware – which leaves Netuitive as the only remaining independent player.

The New Dynamic BSM – Service Assurance

Since the old BSM is dead due to a brittle and difficult to update technology approach it is reasonable to ask what will replace it. The answer is most likely a set of Infrastructure Performance Management tools (Akorri, CA Virtual Assurance, Virtual Instruments, Xangati) integrated with a set of next generation APM tools (AppDynamics, BlueStripe, New Relic) vis these self learning technologies. When this occurs, we will have a system that adapts on its own to changing conditions in the environment leaving IT staff available to interpret results (and not raw monitoring data). We will also have taken an important step towards dynamic service assurance which was discussed in detail in this post.

Understanding and Evaluating these Technologies

For most IT professionals either they or someone on their staff can digg in and understand how the technologies that they use work. However unless you have an advanced degree in statistics and/or mathematics you are not going to be able to dig an and decide for yourself based upon how these products work which one you should choose. Rather what you should do is apply the following criteria in making your selection:

1. Decide exactly what you want the product to do for you. These products are extremely flexible. You can feed them every alarm that is generated by all of your monitoring solutions and let them sort out the good ones from the bad ones. Or you can feed them revenue per minute for one key business application and let them figure what causes degradations in revenue per minute.
2. Make sure that the product has connectors to what you already use to collect metrics from your systems. These products are not in the data collection business (with some exceptions). They rely upon other products to collect data from them. They must therefore be interfaced with your existing monitoring solutions.
3. How hands off and plug and play will the product be in practice? This is the key criteria to the long term value of such a solution to your enterprise. Previous attempts at statistical approaches (neural nets) failed because the product had to be “retrained” every time conditions changed. Make sure that the product you select can automatically select and weight the inputs that it bases decisions off of and these these decisions are automatically updated over time. Self-learning needs to be a continuous thing, not just a one time or periodic thing.
4. Make sure that the product can handle time based (time series) as well as event based data. Performance metrics tend to be time based, but many performance problems are caused by configuration changes which are events. Make sure that the product can cross-correlate configuration change events with performance degradations.
5. Carefully assess the scale of the solution. This means how many inputs can the solution take per unit of time. Right now most of these solutions operate at 15 minute or 5 minute intervals. Monitoring a dynamic system may require intervals of 10 or even 5 seconds (or perhaps even real time continuous streams of monitoring data).

Summary

Self-learning performance management solutions like Integrien and Netuitive are going to be absolutely an essential part of the migration to dynamic data centers and IT as a Service. Once these dynamic data centers scale out to the thousands of applications in a typical enterprise, and scale up to address the most performance critical applications, the rate of change in the environment will be too high for legacy tools and manual administration to be able to keep. up. These automated self-learning approaches will be the only way in which IT Operations will be able to stay on top of these new environments while staying within staffing and budget constraints.

Related posts:

1. 图书推荐《服务建模：原理与应用》
2. 让Remedy飞一会
3. 老美真的很扯，一个职位的帖子被顶了22次

使用一个具有单一的、全知的、万能的和自维护功能的工具，来管理IT基础架的方方面面信息，是否是最好的方案呢？使用一个能做所有工作的全集成平台，来替换您积累下来的所有管理工具是否是最佳方式？现实情况是，大多数组织都已经实施了几十种应用程序、工具、实用程序、数据存储、硬件平台和管理框架，它们一起运行着一个或更多的IT服务管理功能。它们中的每一个应用都有自己的数据库，对当前环境中的一些关键管理功能提供信息支持。在CMDB应用场景中，这些工具相关的数据库中，其实也包含了大量关键的CI属性，这些属性可以用于识别CI之间的关系。重要的问题是，如何利用现有的投资和资源来建立一个底层共享的数据库，比如一个CMDB。

一种方法是“集中存储和管理”，从这些数据源中导出CI的唯一标识、属性、以及关系，然后都整合到一个数据库中。但在经过了一段很长的时间后，这种方案所产生的数据将很难维护，因为伴随着数据源数量的增长，整套系统的维护会变的愈来愈复杂。

另一种方法是“建立联邦的CMDB”，建立一个核心CMDB，用来整合所有配置项的唯一标识、核心属性和关系数据，为所有需要它的IT流程随时提供配置数据，而不需要对所有数据进行集中式地复制。用联邦的模式，让CMDB持有所有CI及其核心属性数据，然后再连接到其他相关的数据源；如服务台事件单、服务水平协议、甚至其他监控的管理控制台界面。通过正确地部署，联邦模式可以使得企业的CMDB能横跨所有的个IT组织，如果需要的话可以对既有的相关系统进行分阶段的实施，这样不仅可以让IT组织能够继续日常业务，还不会带来什么干扰。

摘自BMC软件公司公布的VIEWPOINT “CMDB的潜力—驾驭新的IT现实”，CMDB为主题的文章。

No related posts.

CMDB的价值点分为两类：硬收益和软收益。从硬收益的角度，CMDB的用户可能会让你来描述CMDB对他们的价值点。下面的几个轶事可以作为收集CMDB可能为你的企业带来价值点的几个方向：

• 把IT环境的可视化带到更高程度 –一领先的制热和冷却系统供应商指出，他们始终无法很好的理解一个计划外停机时间对用户所造成影响。例如，当只有25个用户受到了网络中断问题的影响，IT部门必须通知用户群中的全部100个用户。这会导致一个客户满意度低的反馈。CMDB使该公司能够理解配置项之间的关系，并确切地知道在任何确定时刻什么用户会受到影响。现在用户间可信的沟通能够来自于各个IT部门，并且使IT成为业务不可分割的一部分。
• 按业务目标来安排系统变更的优先度–大型设备制造商不得不关闭了其所有的系统，后来发现不知道哪些服务器应该先启动。CMDB使公司能区分关键业务元素的优先度，确保减少计划外的停机时间，无形中降低了收入损失的风险。
• 减少软件许可证的费用的同时确保用户和服务器能整体的满足许可证遵从性 — -的半导体制造商开展了一个审计，结果另他们感到震惊：该公司支持在为大量已经报废的服务器支付支持和维护费用。实际上，该公司关于报废资产的数量已经长期和实际不符了。CMDB有助于该公司发现这一问题，并重新分配预算资金，以更好地支持现有的基础设施。
• 为加快服务器整合提供更深层次的资产和关系信息 — 一大型的金融服务提供商注意到，在其行业的公司通常在一个较短的时间内，会进行几次成功并购和整合。对于如何整合所有的IT部门是一个重大挑战（有时是次要的），他们往往是停留在相互隔离的工作状态下。然而，使用CMDB的公司就能够有效地集成新的收购，从而节省资金和为公司内部建立统一的IT业务形象。

IT要实现CMDB的硬收益，一般通过降低以下对象的相关成本来实现：人、第三方服务、软件、硬件和设施。这些方面的价值点可以通过财务方面的分析报表来反映出来。

CMDB能够实现的价值还包括哪些很难衡量的方面，例如下面的例子解释了这些软价值：

• 服务台 — CMDB可以从提高事件和问题处理和解决效率和效果的方面来体现出硬利益的成效。还可以认为，CMDB使这种改善更可行，往往服务台技术员从尖锐的客户那里来收集信息是一项非常不快的工作，CMDB可能会提高支持人员支持客户的效率，提高客户满意度。另外，通过为服务团队提供更好的信息，你可能使用较低技术水平的工作人员来完成的相同水平的服务工作，降低在工资成本上的成本。
• 变更管理 — 通过CMDB这个流程得到了很大的提升，更完善的风险评估，提供更多的信息来评价类似类型CI在过去时间里的变更成功率，并能更好的理解变更CI与其上游和下游其他基础设施组件的依存关系。其结果可能是使企业用户对IT所提供给他们的服务感到更满意，但这是难以像硬效益一样的量化的。
• 连续性管理 — CMDB的变成了持续管理的记录源泉。拥有了能准确的、更新的描述IT环境状况的信息后，灾难恢复被大大地简化了，这提高了整个组织的信心。这是一个明确的好处，但也不是那么容易量化。
• 与业务的影响与和谐 — CMDB使CI依赖关系能被更深入的了解。这种理解大大简化了连接CI到依赖于IT基础设施的业务流程或者服务的过程。使IT与业务更紧密的和谐是至关重要的，例如提升响应速度和让业务具有更好的竞争优势，但对比硬利益它也可能是难以量化。

以上内容参考了BMC出版的<<step by step to build a cmdb>>;以上软效益对于不同的企业而言可能是不同的，总的来说前两条是显而易见的，你也可能有更好的关于硬效益和软效益的总结和期望。如果有的话一定需要在项目建设前，或者初期阶段中，与CMDB项目相关的利益人和用户做细致的价值点讨论和确认是非常关键的。更进一步价值点的确认也更进一步的指导了CMDB项目实施的方案。BMC Atrium CMDB通过其完备的功能，以及那些以CMDB为核心而建立的ITSM流程应用，能很好的为企业用户实现以上的相关效益。

Related posts:

1. 如何导入CI和关系到Atrium CMDB
2. Stop to build CMDB for your IT – CMS是怎样炼成的？
3. CMS/CMDB 配置管理系统和发现工具