ThoughtWorks
  • 联系我们
  • Español
  • Português
  • Deutsch
  • English
概况
  • 工匠精神和科技思维

    采用现代的软件开发方法,更快地交付价值

    智能驱动的决策机制

    利用数据资产解锁新价值来源

  • 低摩擦的运营模式

    提升组织的变革响应力

    企业级平台战略

    创建与经营战略发展同步的灵活的技术平台

  • 客户洞察和数字化产品能力

    快速设计、交付及演进优质产品和卓越体验

    合作伙伴

    利用我们可靠的合作商网络来扩大我们为客户提供的成果

概况
  • 汽车企业
  • 清洁技术,能源与公用事业
  • 金融和保险企业
  • 医疗企业
  • 媒体和出版业
  • 非盈利性组织
  • 公共服务机构
  • 零售业和电商
  • 旅游业和运输业
概况

特色

  • 技术

    深入探索企业技术与卓越工程管理

  • 商业

    及时了解数字领导者的最新业务和行业见解

  • 文化

    分享职业发展心得,以及我们对社会公正和包容性的见解

数字出版物和工具

  • 技术雷达

    对前沿技术提供意见和指引

  • 视野

    服务数字读者的出版物

  • 数字化流畅度模型

    可以将应对不确定性所需的数字能力进行优先级划分的模型

  • 解码器

    业务主管的A-Z技术指南

所有洞见

  • 文章

    助力商业的专业洞见

  • 博客

    ThoughtWorks 全球员工的洞见及观点

  • 书籍

    浏览更多我们的书籍

  • 播客

    分析商业和技术最新趋势的精彩对话

概况
  • 申请流程

    面试准备

  • 毕业生和变换职业者

    正确开启技术生涯

  • 搜索工作

    在您所在的区域寻找正在招聘的岗位

  • 保持联系

    订阅我们的月度新闻简报

概况
  • 会议与活动
  • 多元与包容
  • 新闻
  • 开源
  • 领导层
  • 社会影响力
  • Español
  • Português
  • Deutsch
  • English
ThoughtWorks菜单
  • 关闭   ✕
  • 产品及服务
  • 合作伙伴
  • 洞见
  • 加入我们
  • 关于我们
  • 联系我们
  • 返回
  • 关闭   ✕
  • 概况
  • 工匠精神和科技思维

    采用现代的软件开发方法,更快地交付价值

  • 客户洞察和数字化产品能力

    快速设计、交付及演进优质产品和卓越体验

  • 低摩擦的运营模式

    提升组织的变革响应力

  • 智能驱动的决策机制

    利用数据资产解锁新价值来源

  • 合作伙伴

    利用我们可靠的合作商网络来扩大我们为客户提供的成果

  • 企业级平台战略

    创建与经营战略发展同步的灵活的技术平台

  • 返回
  • 关闭   ✕
  • 概况
  • 汽车企业
  • 清洁技术,能源与公用事业
  • 金融和保险企业
  • 医疗企业
  • 媒体和出版业
  • 非盈利性组织
  • 公共服务机构
  • 零售业和电商
  • 旅游业和运输业
  • 返回
  • 关闭   ✕
  • 概况
  • 特色

  • 技术

    深入探索企业技术与卓越工程管理

  • 商业

    及时了解数字领导者的最新业务和行业见解

  • 文化

    分享职业发展心得,以及我们对社会公正和包容性的见解

  • 数字出版物和工具

  • 技术雷达

    对前沿技术提供意见和指引

  • 视野

    服务数字读者的出版物

  • 数字化流畅度模型

    可以将应对不确定性所需的数字能力进行优先级划分的模型

  • 解码器

    业务主管的A-Z技术指南

  • 所有洞见

  • 文章

    助力商业的专业洞见

  • 博客

    ThoughtWorks 全球员工的洞见及观点

  • 书籍

    浏览更多我们的书籍

  • 播客

    分析商业和技术最新趋势的精彩对话

  • 返回
  • 关闭   ✕
  • 概况
  • 申请流程

    面试准备

  • 毕业生和变换职业者

    正确开启技术生涯

  • 搜索工作

    在您所在的区域寻找正在招聘的岗位

  • 保持联系

    订阅我们的月度新闻简报

  • 返回
  • 关闭   ✕
  • 概况
  • 会议与活动
  • 多元与包容
  • 新闻
  • 开源
  • 领导层
  • 社会影响力
博客
选择主题
查看所有话题关闭
技术 
敏捷项目管理 云 持续交付 数据科学与工程 捍卫网络自由 演进式架构 体验设计 物联网 语言、工具与框架 遗留资产现代化 Machine Learning & Artificial Intelligence 微服务 平台 安全 软件测试 技术策略 
商业 
金融服务 全球医疗 创新 零售行业 转型 
招聘 
职业心得 多元与融合 社会改变 
博客

话题

选择主题
  • 技术
    技术
  • 技术 概观
  • 敏捷项目管理
  • 云
  • 持续交付
  • 数据科学与工程
  • 捍卫网络自由
  • 演进式架构
  • 体验设计
  • 物联网
  • 语言、工具与框架
  • 遗留资产现代化
  • Machine Learning & Artificial Intelligence
  • 微服务
  • 平台
  • 安全
  • 软件测试
  • 技术策略
  • 商业
    商业
  • 商业 概观
  • 金融服务
  • 全球医疗
  • 创新
  • 零售行业
  • 转型
  • 招聘
    招聘
  • 招聘 概观
  • 职业心得
  • 多元与融合
  • 社会改变
转型San Francisco技术商业

The well-factored approach to securing ROI on your service investment: Part 1

Praful Todkar Praful Todkar
Ryan Murray Ryan Murray

Published: Apr 9, 2017

This article is the first in a three-part series examining how we can achieve ROI from our service-oriented architecture initiatives and deliver on the promise of building business capabilities quickly. We believe the key to success is well-factored service architecture. These articles will provide high-level guidance on building a well-factored service architecture. A lot of our thinking has been influenced by Domain Driven Design (DDD) and our experience applying DDD at large, enterprise clients.

Service-oriented architectures haven’t delivered quick results

Today’s businesses face a challenge. They are not able to deliver customer-focused capabilities quickly to a market that is globally distributed and changing fast. Customers expect these capabilities to be delivered via their channel of choice, be it physical store, call center, website, mobile or voice-activated device. Many businesses have made significant investment in IT. Few are getting the returns they expect.

One particular area of investment has been around building a service-oriented architecture (SOA) that promises to connect various information silos in the company to create new business capabilities.

But there are a couple of reasons why this hasn’t succeeded. Often, the services are built to serve one-off business cases, which makes them hard to reuse and bloats the service portfolio. In some cases, service interfaces are overly generic—disconnected from the realities of the business—so fail to deliver business value effectively. Essentially, organizations lack a coherent service strategy that delivers business value incrementally, while building a strong platform of business capabilities.

Typical issues due to lack of a coherent service strategy include:
  • No strategy to support the delivery of existing business capabilities over new channels, such as mobile, TV, voice activated devices. This stymies attempts to reach new customers or enhance the experience for existing ones.
  • Business capabilities are duplicated across the organization, introducing inefficiencies. For example, at one of our previous clients, the purchase order creation process was duplicated across multiple locations, making it harder to optimize the global supply chain.
  • Key assets like customer information, purchase history and inventory information are spread throughout the organization. This makes it very difficult to get a single view of these assets, which is needed to create new offerings and drive cross-sales and up-sales to existing customers.

Well-factored service architecture is the missing ingredient in realizing the ROI on service investment

We believe well-factored services is the key to securing ROI on service investment. Let’s take an example to see how services are built in practice.

We recently built Reserve in Store capability for a client’s eCommerce application. The capability was dependent on core services such as catalog, inventory and store services. But the business capability was deeply entangled with the online channel’s presentation logic and the dependent core services. What’s more, because the boundaries of the core services were not well understood the logic for those core services lacked cohesion.

As a result, the business found it hard and expensive to make simple changes because of the number of touchpoints involved. Offering the same business capability over new channels like mobile would mean rebuilding the capability. From a development standpoint, this complexity resulted in bugs in production—and it was hard to pinpoint their origin. It made the developers lives difficult because of the cognitive load and having to maintain code that was not core to their domain. In a later section, we will revisit the Reserve in Store capability to see what a well factored service architecture looks like.

In our work with clients, we’ve encountered many instances where organizations have experienced difficulties in creating service abstractions. These can be summarized as:
  • Missing abstractions. For instance, a business capability that lacks a clear definition of where the business capability logic belongs. The Reserve in Store capability mentioned earlier would be an example of this.
  • Leaky abstractions. This is where service logic leaks out to consumers. An example is where the internals of a legacy system such as legacy system identifiers leaks into the consuming services.
  • Wrong abstractions. Here, a service is either too fine grained or too coarse grained. So services built to satisfy one-off business cases end up being too fine grained, that leads to chatty interactions between services. As a result, unrelated services get clubbed together to improve performance.

Business-truthful abstractions are the key to well-factored service architecture

A well-factored service architecture breaks services into ‘business-truthful’ abstractions. Business-truthful abstractions model the business as close to reality as possible. They hide complexity and model the business intentions rather than the mechanics of the solution. They reduce cognitive load for teams consuming the services. They also allow teams building the service to evolve them independently.

Let's take an example. For the inventory service, we had been providing inventory to our clients in two parts. The first part would be the base number of units available and then the ‘offset’, the number that represents the units that could be potentially unavailable due to theft, misplacement or damage. If the client application wants to be absolutely sure about the inventory availability, they would use the base units minus the offset to get the inventory number. But if they were about to lose a sale and do not mind taking a chance, then they would use just the base inventory number.

This approach exposes too much of the mechanics, rather than the higher order business intention of expressing inventory ‘reliability’ as a first-class concept. If the service were to be modeled in a business-truthful fashion, it would expose inventory number along with its reliability. So a sample response would be 10 units available with 100% reliability, with an additional five units at 50% reliability. This approach hides the complexity of the inventory management in the service, including the ability to further improve the reliability of the inventory. Each existing client of the service would then instantly benefit from any improvement in the reliability calculation.

Well-factored service architecture in action

Let us take a concrete example of a well-factored service architecture. We are part of a eCommerce company tasked with creating a service architecture to support omnichannel capabilities, such as Reserve in Store which should be familiar from our earlier example.

This clearly needs to support the web and mobile channels. For a well-factored service architecture, we start with foundational capability services that represent core organizational assets like catalog, inventory and store. These serve as a single source of identity, lifecycle and related logic for those assets.

Then we build business capability services, such as Reserve in Store, that encapsulate the business rules for those capabilities and provide a seamless experience across all the channels.

Finally, we build client experience services that are responsible for tailoring the business capabilities to the channels—thereby providing the best possible customer experience.
A well-factored Reserve in Store service.
Figure 1: A well-factored Reserve in Store service.
Having a well-factored service architecture is a key to rapidly enabling new and innovative customer experiences. It allows you to compose or stack various organizational assets—technical or business—enhancing your ability to deliver business capabilities. In this example, the Reserve in Store capability builds upon the Find in Store business capability  which hides the complexity of dealing with unreliable store inventory. The key is in recognizing capabilities such as Find in Store as a first class business capability and not having it built inside the Reserve in Store capability. This makes the Find in Store capability easily available to other capabilities as well such as Order in Store and hence avoid having to solve the problem of dealing with unreliable store inventory again.

In the above example, it would be quite straight forward to expose the Reserve in Store capability over a voice-operated agent such as Siri. Simply write a new service to manage the conversational experience for Siri and hook it up to the business capability.

It’s also quite easy to build new business offerings, such as sending the Reserve in Store customer promotions that are available in-store.

We believe that well-factored services enable your organization to hide complexity, deliver business capabilities quickly and enable independent evolution of individual services.

In Part Two, we’ll provide high level guidance on building a well-factored service architecture. In Part Three  we'll provide general guidelines for defining service boundaries — whether it’s decomposing an existing monolith or building a brand new set of services.

We would like to thank Bill Codding, Brandon Byars, Damian Knoop, Evan Bottcher, James Lewis, Jeroen Soeters, Joel Parker Henderson, Kyle Hodgson, Martin Fowler, Patrick Turley, Scott Davis, Steven Lowe, Zhamak Dehghani for providing feedback on the article.Visit our Digital Platform Strategy homepage for more.
相关博客
微服务

Domain Driven Design for Services Architecture

Berke Sokhan
了解更多
演进式架构

Microservices as an Evolutionary Architecture

Neal Ford
Rebecca Parsons
了解更多
技术策略

​The CxO Guide to Microservices

Jim Highsmith
Neal Ford
了解更多
  • 产品及服务
  • 合作伙伴
  • 洞见
  • 加入我们
  • 关于我们
  • 联系我们

WeChat

×
QR code to ThoughtWorks China WeChat subscription account

媒体与第三方机构垂询 | 政策声明 | Modern Slavery statement ThoughtWorks| 辅助功能 | © 2021 ThoughtWorks, Inc.