issn 1745–1884 cbdijournal · and business design that facilitates a managed level of agility. by...

CBDIJournal2 Editorial

SOA and Multi-Channel

3 SOA Best Practice ReportSOA and Multi-Channel Business

SOA is widely recognized as a facilitator of multi-channel architecture in a wide range of industry sectors spanning

retail to government. The service concept provides an opportunity to implement common services supporting

multiple delivery channels which often use very different technology. At the same time there is often the opportunity to introduce business process behaviors that cross channel,

providing enhanced business process support. But cross channel business processes are likely to create even more

demand for change than single channel processes. In this report we introduce a structured approach to architecture

and business design that facilitates a managed level of agility.By David Sprott

15 SOA Best Practice ReportBusiness Value of SOA

An Analysis of the Dell Multi-Channel Case

For many years, Dell has operated a direct sales business over many different communication channels – phone, internet and retail kiosks – but all under its own control. Over the

past couple of years, Dell has extended this business model to include multiple business channels. SOA has been a key

element of support for this multi-channel strategy, and in this case study, based purely on published sources, we analyze the

business value of SOA for Dell.By Richard Veryard

21 Q & AHuman component of heightened fear and uncertainty

inhibits SOA strategy?

23 Book ReviewSOA Governance by Todd Biske

This book has the power of a novel–that transports me straight into the small, anonymous meeting room where I

am in the thick of an argument with my peers about how to balance architectural necessities with project imperatives.

Reviewed by David SprottIndependent Guidance for Service Architecture and Engineering

ISSN 1745–1884

novemBer 2008

Editorial

www.cbdiforum.com

SOA and Multi-Channel

I continue to observe examples where SOA is deployed primarily as a technology strategy which worries me a lot. Yes SOA technologies will provide loose coupling but they won’t address abstraction, reuse, standardization etc. in my experience the areas of maximum business value.

One application area that is very commonly linked to SOA is multi channel. SOA seems a natural fit – enabling common services for concurrent use in multiple technology channels such as ATM, branch and kiosk, or Web, call center and mobile. Of course channels are very often technology enabled opportunities and the justification for the investment in the new channel is precisely because of the technology viability.

But the technology layer is essentially about providing a delivery mechanism or interface to the “consumer”. In addition there will be business model components that further define the channel that need similar consideration so that a) new or altered channel capability can be introduced as rapidly and cheaply as possible and b) business processes are designed such that cross channel interaction makes the channel as effective as possible for the “consumers” and “providers”.

In developing a general framework for multi-channel, we identified a number of these business model components as having the same architectural consequences as technology. In addition to the delivery or interface these include Product Class/Consumer, Commercial Channel, Pricing Type and Product Delivery Technology. We don’t pretend this list is exhaustive, rather a starter for your thought processes.

The same thinking can also apply to merger and acquisition, which when you think about it often introduces new channels, either temporarily or permanently. For example Royal Bank of Scotland (RBS), running the two retail banking brands RBS and NatWest as two “channels” with consolidated support systems and cross channel selling.

As an organization extends into more ambitious multi-channel arrangements, the potential value it can get from SOA is increased and it occurs to us that sophisticated multi-channel architecture and business models are indications of very mature SOA capability. Talking of which I note this month reports from the 5th Telco 2.0 Executive Brainstorm where the Telco 2.0 model1 was under the spotlight. This emerging concept is a shift in business model referred to as a ‘two-sided’ telecoms market structure; where telcos facilitate improved interactions and transactions between people and organizations. While telcos must continue to attract retail consumers they will extend the capabilities of traditional consumer products to support enterprise business processes by creating open and standardized platforms that third party organizations can plug their enterprise IT and communications systems into – just as they plug into the telephone and Internet networks today. Sounds like a multi-channel world.

For all these reasons we have decided to focus this month’s CBDI Journal on the multi-channel topic. In addition to a significant report on a framework for multi-channel business and communications, we look in some depth at how Dell has utilized SOA multi-channel for business value. Also this month we have a Q & A following up on last month’s editorial and a book review on a “business fable” approach to explaining SOA governance.

David Sprott, Everware-CBDI, November 2008

Notes 1Telco 2.0 Manifesto http://www.telc02.net/manifesto/

Sophisticated multi-channel

architecture and business models

are indications of very mature SOA

capability

Best Practice Report

cbdi journal © Everware–CBDI Inc, November 2008 �

By David Sprott

SOA and Multi-Channel Business

SOA is widely recognized as a facilitator of multi-channel architecture in a wide range of industry sectors spanning retail to government. The service concept provides an opportunity to implement common services supporting multiple delivery channels which often use very different technology. At the same time there is often the opportunity to introduce business process behaviors that cross channel, providing enhanced business process support. But cross channel business processes are likely to create even more demand for change than single channel processes. In this report we introduce a structured approach to architecture and business design that facilitates a managed level of agility.

IntroductionMulti-channel architecture is widely understood as a key benefit from SOA. But like many buzz words multi-channel is neither new nor well defined. Predictably it is a heavily overloaded term.

I recall Dell combining its Web and call center order operations a good few years ago as one of the early examples of multi-channel architecture at work. This was a classic example of two separate ordering processes which were combined into one common process. In the early stages the benefits were primarily about consistency of business systems and processes, plus common price and customer data.

In 2003 Dell reported considerable further progress1. It focused on common services for three key business areas pre-purchase, configuration and pricing, real time accuracy in pricing and shipping costs to facilitate buyer decisions and post purchase tracking and shipping status. It created three strategic services – Third Party Pricing Configuration, Taxes and Shipping and Order Status. These services created the platform for reuse of common capabilities across the eCommerce site, other Dell business units and also partners, suppliers and business customers.

A little more recently in 2004, Dell moved beyond its direct marketing model and started selling certain products through selected retail stores enabling customers to order using an in-store kiosk or it’s regular Web ordering system. In parallel with this report we are publishing a case study report that looks in some depth at the business justification of multi-channel architecture based on the Dell case.

� cbdi journal © Everware–CBDI Inc, November 2008

SOA and Multi-Channel Business continued . . .

In all of the early work at Dell the term multi-channel didn’t occur. I guess the marketing hype hadn’t hit at that stage. However this is clearly an excellent if early example of how service architecture can enable multi-channel technology and business.

Today the term multi-channel is used pervasively, if somewhat loosely. In this article we will attempt to provide some structure and methodology around SOA and multi-channel.

Scoping and Classification

Multi-Channel ClassificationMulti-channel is often viewed as mostly a technology issue where gradual and unplanned introduction of new customer facing technologies has led to disparate solutions, business processes and supporting information data. The separate development of call center and eCommerce channels everywhere is a good example. We can see widespread evidence of the results from personal experience with different information and prices between one company’s call center and eCommerce site. Or manifestly different processes and charges between branch, ATM, and kiosk systems.

But it can be helpful to scope multi-channel more broadly than purely technology channels because the same issues can occur in many different contexts. In Table 1 we suggest a number of channel types that all follow the same pattern of channel specific behaviors, together with common behaviors that cross channel and in many cases provide opportunity to enhance business models with inter channel coordination or switching. Developing a clear understanding of these for a specific enterprise or ecosystem is a prerequisite for effective multi-channel architecture.

The Delivery or Interface is always going to be the most obvious driver, usually driven by technology. However channel is also

likely to be characterized by class of consumer or product class such as enterprise, SME, retail consumer etc. But channel thinking shouldn’t be restricted to enterprise systems, it’s also useful in government where citizen or intra government processes will exhibit all the same issues and opportunities.

Commercial channel is obvious. In the Dell based case study this is clearly a major consideration, and Dell reported the business value of a specialized third party partner channel that achieved considerable pull through business by facilitating real time integration with partner bid and deal processes.

While type of pricing mechanism is not a channel per se, it has a lot of the same structural characteristics that need to be managed like a channel. For example the design of an eCommerce pricing structure cannot be undertaken in isolation of other pricing mechanisms.

Product delivery technology will often have a big impact on channels. The current uptake of SaaS and On Demand services will inevitably create new demand for channel support systems. With the emergence of new concepts it’s normal to see specific management systems developed for the new delivery systems, and only after the fact is consideration given to integration into the wider ecosystem. This is particularly true of SaaS, and we can expect that enterprise uptake of SaaS will be cautious and slow until the SaaS delivery channel is properly integrated with service management, help desk and support and security systems. The very same process happened with the introduction of Web services.

Triggers and Issues Driving Multi-Channel InitiativesChannels usually emerge in a standalone manner. Whether driven by new technology or business strategy it’s par for the course. Typically it’s only after the channel has developed and become a significant part of the business model that there is a realization that the new channels are not actually as standalone

Channel Types Examples

Delivery / Interface eCommerce, Web, Call Center, Kiosk, SMS,

Product Class/Consumer Enterprise, SME, Retail Consumer, Citizen, Intra-government

Organizational Brand integration, mergers & acquisitions

Commercial Channel Wholesale, Retail, Corporate, Partner, Direct

Pricing Type Credit, eCommerce, Cash, Direct Debit

Product Delivery Technology Managed Service, DVD, SaaS

CD, DVD, Video on Demand

Table 1: Classes of Channel


as was originally thought. This realization often occurs as a raft of inconsistency and duplication related issues surface.

Data inconsistency – core data is maintained differently by two or more applications and processes. Inability to provide common view of key data, e.g customer. Highly variable data quality.

Duplicate processes – Two or more processes support activities that are effectively doing the same thing.

Silo processes – Duplicate processes operate in isolation, or use different data and rules and therefore cannot effectively support cross channel switching. The duplicate processes are often technology and legacy application specific.

Inefficiency – Newly introduced channel processes are inadequately engineered requiring extensive workarounds or exceptional case handling. Also data quality issues require heavy manual effort to both rectify erroneous transactions and correct information.

•

•

•

•

Multi-Channel Business PatternsAs discussed, channels will usually be defined by a combination of business model and delivery technology. Channels occur in all industry sectors and opportunities for multi channel interactions are legion. In many cases the technology channel will provide little or no business competitive differentiation, whereas channel business model and particularly cross channel interaction may be a significant competitive differentiator.

In the case of Dell the ability to provide common, real time capabilities were seen as crucial for the eCommerce channel in order to turn browsers into buyers. The harmonization of eCommerce and Call Center channels pricing and configuration was deemed early on to be a key capability.

Pattern – Consistent Business Across ChannelA very common cross channel pattern is providing cross channel business consistency. A common example, and a high priority for many enterprises is establishing common views 1) of and 2) for customers.

As shown in Figure 1, the common view of customer provides consistency of various types of customer information, not merely static descriptive data, regardless of whether the customer interaction is occurring via the call center, CRM portal or eCommerce channel.

The common view “for” customer is equally important providing consistent product behaviors for a customer regardless of method of interaction. This is also the pattern used by Dell to provide consistent, cross channel behaviors for third party pricing configuration, taxes and shipping and order status processes.

Figure 1: Single Customer Views

� cbdi journal © Everware–CBDI Inc, November 2008


Pattern – Cross Channel SwitchingThe cross channel switching pattern is very commonly used in the retail business whereby interactions between Catalog, eCommerce and Store channels are managed effectively to increase sales and facilitate the customer experience. Catalog browsers are seamlessly transferred to either or both the eCommerce site for ordering and physical store for buying and pickup. Retail industry experience is that integrated catalog, stock and delivery processes provide an efficient and flexible customer buying experience.

The same pattern can be applicable to all manner of industry sectors. For example:

Combining technologies to suit “consumer” preferences – enabling Web ordering and providing delivery, confirmation of alert information by SMS

•

Providing seamless switching between Web and call center for almost any application can be highly effective. Perhaps prompted by a rules engine that detects the consumer requiring assistance or a sales opportunity that is better facilitated by human contact.

A common Web based case handling process for citizen interaction with switching between multiple government departments.

A seamless healthcare process which spans general practitioner and specialists providing coordinated appointment booking, shared medical records and consistent governance over the provided service.

Table 2 illustrates a number of channel and channel interaction examples for some of the major industry sectors.

•

•

•

Industry Sector Example Business Services

Delivery / Interface Channel Interactions Patterns

Government Law enforcement

Health services

Disaster management

Community and social services

Government Office

Call centre

Web

SMS

Communications switching

Consistent data

Case interaction

Joined up government

Citizen centric processes

Single citizen view

Retail Ordering

Pricing

Delivery

eCommerce

Store PoS

Call Center/ Catalog

Partner channel e.g eBay

Promotion and Price coordination

Order to delivery

Return to different channel/store

Stock control

Browse/Order from catalog or Web, buy/collect/deliver from Store

Single customer view

Single product/stock view

Financial Payment Platform ATM as general-purpose kiosk

Single Customer view

Healthcare Sales

Appointment scheduling/booking

Medical records

Test results

Call Center

Email

SMS

Remote laptop

Wearable sensors

Reseller channel

Cross provider records

Direct-to-patient marketing

Single patient view

High Technology Ordering

Product Assembly

Shipping

Order Status

Call Center

Web

Store Kiosk

Third party platforms

Browse Web, buy call center

Buy Store, return Web

Cross channel configuration

Single customer view

Table 2: Channel Business Model Examples


Multi-Channel Strategy DevelopmentWe have commented previously that there is a logical service stack in which the lower levels – the underlying systems, utility and core business services are inherently stable and undergo change relatively slowly. In contrast at the higher levels of the stack capabilities and processes are inherently fluid, responding rapidly to business strategy, market conditions and competitive actions. The delivery channel is effectively at the top of the stack, providing the interface with customers, partners and suppliers, and is therefore likely to be quite volatile.

As discussed technology is a major driver of change in channels, but the channels will also be impacted by events, channel interactions, pricing and products.

In Table 1 we introduced the idea that it is useful to classify channels in order to establish a better channel scope. But these channel classifications are even more useful in determining channel strategy and providing excellent insight into likely demand for change, and therefore a major input to architectural thinking and SOA policy and governance.

In Figure 2 we return to the idea that architectural policy should be firmly based on evolving business dynamics as they relate differently to the Core and Context business activities.

We describe this using the Business Activity Grid developed by CBDI from the ideas of Geoffrey Moore.

The Business Activity Grid separates activities by Core and Context, where Core activities are defined as impacting share price and Context as only needing to be done as well as your competitors; there is no advantage in differentiation.

This basic separation is then vertically separated into mission critical and supporting activities. Hence the grid illustrates a life cycle in which activities often commence in the bottom left hand corner as activities are innovated and then evolve in a clockwise direction to become Mission Critical where differentiation is extremely important, and then continue to evolve to become Context where standardization is highly appropriate, and finally the activities at the end of their life become supporting at which time it is quite likely they will not be undertaken by the core enterprise but by external providers in a wider ecosystem.

This method of analysis has very interesting relevance to the channel strategy and hence service architecture. As shown in the diagram the strategy is usefully decomposed to address each of the channel classifications introduced in Table 1. In this report we won’t attempt to detail all the possible permutations

Figure 2: Evolving Channel Business Strategy

8 cbdi journal © Everware–CBDI Inc, November 2008

of classification and strategies, rather we provide some examples in Table 3. We may return to this table and further analyze the patterns in a future report.

Figure 3 takes these ideas further by considering a maturity model and Figure 4 then takes the ideas further by mapping them onto a roadmap.

Strategic Life Cycle State

Business Strategy

Channel Strategy

Supporting Core Innovate Early use of new technology

Narrow focus on specific business channels and products

Narrow focus cross channel interaction – enabling critical, innovating behaviors

Use of core business services and capabilities to get to market fast and provide consistent information and behaviors

Mission Critical Core Differentiate Mature technology platforms, early to market with innovations

Specialized channels for business products and lines

High levels of channel interaction provide extensive differentiation allowing sophisticated customer / partner support

Continued and high focus on business process innovation

Mission Critical Context Standardize Mature technology platforms

Use of 3rd party channels

Channel interaction consistent with industry standard. High probability of using industry standard services

Supporting Context Ecosystem Mature and end of life technologies

Use of ecosystem platforms

Table 3: Channel Strategy by Strategic Life Cycle State



Figure 3: Example Channel Maturity Model

Figure 4: Example Channel Roadmap



SOA Principles and Multi-ChannelPrinciples are always a sensible place to start thinking about architecture2. I can’t say it often enough, that in developing a solution you need to start with the style and consider how that helps to deliver a high quality solution.

SOA Principle Technical Context Business Context

Loose coupling Technical separation spanning entire interoperability stack including messaging, security, transactionality, policy etc.

Loose coupling of business design exposing business and technical capabilities based on published contract, with no further dependencies.

Clear separation of channel solutions from technology allows highest levels of business flexibility – channel support for emerging technologies, as well as disparate and heterogeneous partner, supplier and customer environments.

Modular Smaller, highly componentized units of capability/deployment allow assembly of channel specific solutions

Multi-channel business will often be highly volatile environments and componentization will maximize response to change

Abstract Common capabilities are designed to be sufficiently abstract that they can be reused in all channels as necessary

Common data stores provide consistent cross channel information and facilitate channel interaction.

Cross channel information, process, capabilities are standardized in order to deliver key behaviors such as consistent customer perspective, consistent pricing and configuration etc

Composable Allows reuse of common capability with specialization for each channel

Channel specific business processes can be integrated with cross channel business processes.

Channel specific behaviors can extend standard behaviors. For example common pricing is extended with Web specific pricing elements.

Virtualized Channels will usually employ channel specific technology and behaviors (conversations, dialogs) and reuse common process and core business services that are entirely virtualized.

Rationalization of underlying complexity is entirely hidden from channel processes.

Common capabilities ideally implemented in scalable, channel neutral manner using shared resources.

Lower dependency on physical resources and legacy capabilities provides business scalability, and faster, cheaper introduction of new and upgraded channels.

Table 4: SOA Principles Support Multi-Channel

cbdi journal © Everware–CBDI Inc, November 2008 11

Multi-Channel SOA FrameworkThe channel strategy is an essential input into the channel service architecture. As discussed, SOA brings important principles that guide the appropriate level of flexibility to be engineered into the solution.

Figure 5 illustrates a generic channel service layered architecture3. The core SOA principles are employed to ensure an appropriate level of abstraction that allows common or standard services to be implemented once and once only, and provide a stable foundation for channel specific services and solutions to be rapidly assembled and continuously evolved where appropriate upon that base.

The layers shown are:

Underlying Service – Services that are not fully encapsulating the underlying capability, and therefore should not be exposed to the higher layers. Existing application specific. Examples: Divisional General Ledger; SAP BAPI Xxxxxx.

Core Business Service – Services that consolidate underling capabilities to provide a common service to manage a major business resource in a consistent manner. Strongly data oriented. Example: Customers, Products, Orders.

Generic Business Process – Services that orchestrate business process behaviors managing events, branches, and process state for units of business process that are required to be common across two or more channels. Examples: Core Orders Process, Product Configuration and Pricing.

Channel Specific Business Process – As per generic business process services but for a specific channel Examples: eCommerce Order Processing, Wholesale Pricing.

Cross Channel Solution Component – Solution components (possibly but not necessarily services) specific to two or more channels. Examples: Authentication, Presentation, Validation, State Management.

Channel Specific Solution – Solution components (not necessarily services) specific to a single channel. Example: Technology Specific Security.

Device Presentation – Functionality for channel specific presentation. Examples: User Interface, Navigation.

At first sight this layered architecture may look highly complex and potentially provide performance and maintenance issues

•

•

•

•

•

•

•

because of the number of layers and hence moving parts. However it should be emphasized this is a logical architecture and it should be used as a starting point against which to interpret the business channel strategy and to deliver a suitable level of flexibility. Layers are optional and should be used when they enable required levels of agility.

Similarly the number of services involved may be relatively small. In Dell’s case in the initial multi-channel architecture there were just 5 very strategic services. These might have been depicted as shown in Figure 6. Note in this model diagram, which is highly speculative, I have made the assumption that there will be significant orchestration of Orders because these will be long running in order to manage the contents of shopping baskets, and therefore there would be a requirement for a separate process service to manage the process state and sequencing that calls a core business service for Orders.

More interesting is the consideration of the requirement for cross channel business processing and whether common process services are implemented regardless of initial requirement on the basis they facilitate cross channel interaction in the future, even if this is not part of the initial requirement.

In the case of Tax and Shipping I assumed that these would be calculation services that support channel specific processes direct. For Address Verification and the Comparison Shopper I have introduced a utility service layer – services that are used ubiquitously, that would always be called directly by the channel specific business process. And finally in the interests of realism I anticipated a large number of underlying services that provided the back end processing.

The layered architecture is an important logical element of the reference architecture framework that will enable multiple channels to collaborate, regardless of technology or design approach. Remember not all the channels will necessarily be managed by the single enterprise. Other aspects of the reference framework that should be developed and formalized are attributes against each layer. These will include:

Behavioral Specification schema – each service call from layer to layer requires a formal contract. It is important that all services of the same type (layer) have the same schema type. For example the contract with underlying services is likely to be implementation specific, whereas the contract with core business services will be strongly state oriented, but completely implementation independent.

Service Level Agreement schema – with a hierarchy of this type, back to back contracts will be essential between all layers.

•

•



Architecture and Design Policy – Details such as service dependency need to be formally defined and governed so that the agility characteristics are maintained in the long term.

Patterns to be adopted (to deliver appropriate agility) – defining common patterns that a) learn and reuse good experience and b) ensure common utilities and infrastructure can be reused with minimum specialization.

•

•

Version and upgrade policy – a critical part of the broader contract that will persuade channel owners that they can rely on the common services.

•

Figure 5: Layered Architecture

cbdi journal © Everware–CBDI Inc, November 2008 1�

SummaryIn this report we have considered a structured approach to SOA multi-channel. In particular we have emphasized the need to take a combined business and technology approach and critically to consider future requirements in the architectural design as channel design is likely to be one of the most volatile areas of the overall business.

NotesDell Commits to a .NET Connected Web Services Architecture. http://download.microsoft.com/documents/customerevidence/6634_Dell_DotNET.docService Architecture & Engineering. http://www.cbdiforum.com/secure/interact/2006–07/serv_archi_eng.phpLayered Service Architecture – For detailed treatment see the Reference Architecture Framework in the CBDI SAE Knowledgebase

1.

2.

3.

Figure 6: Example Layered Architecture Based on the Dell Case

CBDI-SAETM SOAKnowledgeBase

Version 2 Now Available

CBDI Forum Service Architecture & EngineeringTM

To assist organizations to make rapid progress in strategic SOA adoption Everware-CBDI provides CBDI Service Architecture & Engineering (CBDI-SAETM), a collection of knowledge and best practice. The SAE reference framework for SOA comprises integrated concepts, reference architecture and processes in a structured approach for SOA based on sound architectural principles that can deliver flexibility, sharing, and consistency of Services.

Everware-CBDI has been developing the components of CBDI-SAETM for the last few years in its education, consulting engagements and research. This is now being made available for customer use through the CBDI-SAETM Knowledgebase which provides users detailed guidance on all aspects of the CBDI-SAETM

SOA Reference Framework, including:

A Reference Model and Reference Architecture

Detailed SOA deliverables with templates and worked examples

Extensive technique and practice guidance

Discipline and process definitions

The CBDI-SAE™ SOA Knowledgebase is continually evolving and provides leading edge practice guidance based on practical experience in very large enterprises. The Knowledgebase is available to organizations with the CBDI PLATINUM CORPORATE membership providing on-line access to a CBDI hosted version for multiple employees.

To take out a PLATINUM subscription contact CBDI.

•

•

•

•

Consistent Enterprise-wide SOA Blueprint.A common language and framework for describing and managing Services and SOA solutions. Eliminates confusion and facilitates cross enterprise collaboration and sharing.

Standards Based. Everware-CBDI is committed to working with the industry to deliver relevant standards, particularly those supporting automation and sharing.

Constantly Updated with best practice and the latest techniques.

Real World SOA Experience. CBDI-SAETM is based on real-world experience gained through consulting assignments and feedback from users.

•

•

•

•

Evolving. The Knowledgebase will continuously develop as practical experience is synthesized into best practice and new areas of guidance arise.

Open. The published reference model and meta-model enables integration of complimentary frameworks

•

•

Learn: New to Service Oriented Architecture? Then this section lays out a path through Knowledgebase materials to learn the core concepts and principles of SOA.

Explore: Explore the Knowledgebase through the following content

What: Understand the underlying frameworks and other components that provide the concepts and principles to ensure consistency in the delivery of SOA Why: Explore the motivations for applying SOA, and the triggers for specific SOA activitiesWhen: Putting the right capabilities in place at the right time is essential for the successful adoption of SOA Who: Understand the roles and responsibilities of individuals and organizational structures that must perform SOA activities

Execute: Perform SOA ActivitiesHow: SAE provides a repeatable process for SOA, now including guidance and resources for Work Packages and WorkshopsResources: Tools and templates to help you perform key activities and produce key deliverables

•

•

•

•

•

•

Con

tent

sFe

atur

es B

enefi

ts

© Everware-CBDI Inc 2008

For more information contact Everware-CBDI Inc. [email protected]

RESEARCH PORTAL: www.cbdiforum.comSERVICES: www.everware-cbdi.com


Best Practice Report

By Richard Veryard

Business Value of SOA – An Analysis of the Dell Multi-Channel Case

For many years, Dell has operated a direct sales business over many different communication channels – phone, internet and retail kiosks – but all under its own control. Over the past couple of years, Dell has extended this business model to include multiple business channels. SOA has been a key element of support for this multi-channel strategy, and in this case study, based purely on published sources, we analyze the business value of SOA for Dell.

IntroductionIn this report we develop an approach to predicting and or measuring business value in a multi-channel situation. To illustrate this we have undertaken an analysis of the experiences of Dell. We have used and referenced publicly available materials, but the analysis and conclusions are entirely CBDI derived.

Background

Original Business ConceptMichael Dell’s original business concept was selling PCs direct to the customer. He believed that this gave the company a number of advantages over its competitors.

better understanding of customers’ needs

ability to provide the most effective computing solutions to meet those needs, based on the “configure-to-order” approach to manufacturing of which Dell was a pioneer

convenience to customer – no need for self-assembly

lower inventory costs and greatly improved cashflow1

lower prices than traditional retail

To support this concept, Dell developed a direct-sales business channel, initially via telephone and subsequently via Internet. Michael Dell wrote a book called Direct from Dell, with the subtitle “Strategies That Revolutionized an Industry”.

•

•

•

•

•

1� cbdi journal © Everware–CBDI Inc, November 2008

Business Value of SOA continued . . .

Multiple Communication ChannelsDell combined its Web and call center order operations a good few years ago as one of the early examples of multi-channel architecture at work. This was a classic example of two separate ordering processes combined into one common process. In the early stages the benefits were primarily about consistency of business systems and processes, plus common price and customer data.

In 2003 Dell reported considerable further progress2, focusing on common services for three key business areas: pre-purchase, configuration and pricing, real time accuracy in pricing and shipping costs to facilitate buyer decisions, and post purchase tracking and shipping status. Dell created three strategic services Third Party Pricing Configuration, Taxes and Shipping and Order Status, which created the platform for reuse of common capabilities across the eCommerce site, other Dell business units and to partners, suppliers and business customers.

A little more recently in 2004, Dell moved beyond its direct marketing model and started selling certain products through selected retail stores, enabling customers to order using an in-store kiosk or its regular web ordering system.

From 2002, Dell started to operate kiosks in shopping malls, and in 2006, Dell opened its first full retail store.

Multiple Business ChannelsIn May 2007, faced with declining sales and other pressures (including an accounting investigation and a pending lawsuit for fraud), Dell announced a major shift in strategy. It had previously sold relatively small quantities of product through VARs (value-added resellers), but it was now going to expand these channels into a major sales thrust. And for the first time, Dell executives gave a figure for the company’s annual sales through the North American solution provider channel: $4 billion and growing faster than the overall category.

Challenges of Multi-Channel BusinessDell already had a well-established multi-channel operation covering multiple communication channels – web and call center, wholesale and retail/consumer. However, a strategic shift to selling through business partners introduces another dimension of complexity to Dell’s multi-channel operation, and the need to rapidly introduce support for these partners provides an interesting illustration of the potential value of a properly architected SOA strategy for Dell.

In order to provide full support for the VAR channel, Dell embarked on the development of a range of programs and strategies that VARs had said they needed to go to market with Dell products.

The two-tier program for Registered and Certified partners is intended to share leads with partners and take advantage of Dell strengths such as just-in-time manufacturing, sophisticated configuration options, marketing know-how, and online support assistance.3

Deal RegistrationThe purpose of deal registration is to give the channel partners confidence that their sales and marketing efforts will not be subverted by Dell’s own direct sales organization. 4

Partners submit deals to Dell for registration. Those deals enter a workflow involving Dell channel executives that will lead to approval or rejection. Sensitive customer data are protected to prevent Dell’s direct sales organization from getting anywhere near solution providers’ customer data.5

Dell has built a partner portal, known as the Wall, where partners can view opportunities, register new deals, check their performance profiles and track the approval process, as well as send emails to approval managers at Dell. The portal has many customizable views that partners can use to quickly sort and find information on active deals. Partners also can create any list views they want.

Dell has built this partner portal using partner relationship management (PRM) services from Salesforce.com. Because Salesforce.com offers a global service with internationalization features, international partners can create deal registrations that are specific to product and campaign and partner-program, without having to merge data sets from multiple locations.

Partner Deal Evaluation SystemThe system includes a feature called “Connections”, providing interoperability between Dell systems and Salesforce.com services. Partners who are Salesforce.com customers can simply select Dell as one of their vendors. Dell systems include rules allowing opportunities to be shared with these partners.6

Flexibility – From Product to ProcessPart of Michael Dell’s original business concept was the ability to offer flexible customization of computers and other products to the customers. However, as the computer market has matured, the value of this flexibility has declined.


For years, Dell had made profits by convincing customers to upgrade from its basic models by adding more memory or processing power. That strategy ultimately unraveled as customers began to place a greater emphasis on price over performance. “With the very rapid move to lower price points, flexibility has worked against us,” Mr Dell said. “We found that we were putting features into our products that customers didn’t value enough to pay for.”7

Instead of this earlier emphasis on product-oriented flexibility, Dell has had to focus on introducing greater flexibility into its delivery channels. In other words, process flexibility – so Dell’s investment in SOA should pay off here.

Pricing HarmonyAnother challenge for Dell is to create a pricing structure that won’t pit partners and its internal sales team against one another.8

Tighter MarginsThe partner channel eats into Dell’s profit margins. Furthermore, Dell’s competitors are catching up on Dell’s inventory advantage as shown in Figure 1.

Comprehensive Product RangeAt present, some of the more complex value-added services are only available to customers directly from Dell, and this is a source of friction between Dell and its partners. Dell has promised that in future all parts of Dell’s lineup will be available as solutions that can be delivered through channel partners.

Service Oriented ArchitectureAs discussed earlier in the Background, Dell was an early adopter of SOA. Back in 2003, Microsoft published a case study describing how Dell had developed five web services in order to validate the adoption of a Web service architecture across the Dell enterprise.

Web Service FunctionalityAt that time, the key business objectives were to improve the Dell customer experience, reduce product returns, and increase sell-through.

The key functionality areas of the web service pilot were as follows:

Pre-purchase configuration and pricing – both direct to customers and to third-party trading partners – this included providing this information as a real-time service to third parties

Accurate tax and shipping costs – these vary both by customer address (state taxes and delivery charges) and by the content of the order, and are progressively recalculated as the order evolves – this included obtaining costs from third-party logistics companies.

Customer visibility of tracking and shipping status – consolidating data from Dell data warehouses and third party shipping partners – this kind of information is now commonplace but was then fairly innovative

Follow-up functionality included

Data warehouse support systems

Internal sales user interface

MyAccount service, providing personalized information to customers

IT ResultsThe initial web service architecture delivered a number of business benefits to Dell.

Development speed – modular price configuration solution developed in just eight weeks

Scaleability – configuration engine used over a million times a day

“Reduced costs, greater productivity, and improved customer value”, says Michael Dell.

•

•

•

•

•

•

•

•

•

Figure 1: Competitive Inventory Comparison



Business Value from SOA

Initial Benefits (Single Channel)The business benefits fed into Dell’s financial performance in several measurable ways.

Increased willingness to buy

Increased pull-through – In a VAR context the most significant pull through is of Dell products bundled into third parties’ proposals, bids, deals, for systems integration and consulting, or platform or application partners, thanks to real time pricing and configuration

Increased customer service efficiencies.

The actual figures achieved by Dell are not published, so the following examples are purely hypothetical. In the first diagram, Figure 2, an improvement to Willingness-to-Buy affects the rate at which enquiries are converted into sales. In order to estimate the potential improvement from a given initiative, we need to know the present conversion rate, the theoretical maximum rate (in this case, we’ve set it to 100%) and the target for this initiative, Suppose we can increase the conversion rate from 25% to 30%. The difference (delta) attributable to this initiative is therefore 5%. The spreadsheet then calculates the effect of this initiative on sales.

But as Dell makes clear, a single web services initiative produces multiple benefits. So if we are increasing both willingness-to-buy and pull-through, then these two effects will be multiplied as shown in Figure 3.

•

•

•

The third extract from our spreadsheet model in Figure 4 shows the effect of these initiatives on customer service efficiency. Business improvements may improve the efficiency of a single transaction, or may improve the effectiveness of customer service transactions and so reduce the total number of transactions that are required to deliver a given customer service outcome. Thus we need to combine both of these improvements in the calculation.

Dell invests in automated service, and closes a number of end-user call centers. So it would make sense to assume that the benefits of the automated services could be measured in job cuts. However, Dell has denied that there is any correlation between these two events.9

Now we can sum the effects of the SOA initiative to produce a calculation of the aggregate value.

Follow-Up Benefits (Multi-Channel)Having developed this functionality for a single channel, a major further benefit of SOA is that this functionality is easier to make available for multi-channel. One way of figuring this into the financial model is to set a percentage indicating the effectiveness of this benefit across all channels.

Given that these benefits involve collaboration and interoperability, and the creation of new workflows based on the same core capabilities, we should expect SOA to produce a significantly higher percentage. Indeed, higher levels of SOA maturity will produce higher percentages.

Figure 2: Benefit Formula – Willingness to Buy


In David’s article this month, he explains that channel specific processes are at the top of the layered architecture and the most volatile of all the layers. The interesting question is the extent to which Dell has been able to innovate, or whether it has struggled because of business issues (not getting the channel strategy right) or whether it’s about execution.

So let’s look at a model that simulates all these alternatives – for example Dell with JBOWS versus Dell with a proper service architecture.

Each business improvement delta is modified by a percentage from the matrix in Figure 5, depending on two factors – SOA maturity and channel complexity. (Again, these are suggested

figures, which would have to be calibrated for a given organization.) The matrix can be read as follows. With single-channel operations, you can achieve 60% of the potential business benefit using JBOWS, and 90% of the potential business benefit using standardized services. However, for multi-channel operations, these percentages drop to 40% from JBOWS and 75% from standardized services. To get close to the maximum benefit, you need a fully layered service architecture, and the business case for this is significantly stronger for multi-channel than for single-channel operations. (How much stronger? If we have the business numbers, we can feed them into the spreadsheet and calculate the answer.)

Figure 3: Benefit Formula – Pull-Through

Figure 4: Benefit Formula – Customer Service



SummaryDell created key services for key capabilities. It has achieved considerable business standardization as a result, and that obviously helped it when it had to make the 2007 changes.

Clearly the full level of benefit comes from having a fully layered service architecture. We look forward to seeing how Dell manages the increased complexity of its multi-channel business going forward.

ReferencesDell Commits to a .NET-Connected Web Services Architecture, Microsoft 2003

NotesAt one time, Dell had a negative cash conversion cycle of 45 days, representing the average time difference between receiving payment from its customers and paying its suppliers. See http://www.crn.com/hardware/193300259Dell Commits to a .NET Connected Web Services Architecture. http://download.microsoft.com/documents/customerevidence/6634_Dell_DotNET.docSource: Computing 13 Feb 2008 http://www.computing.co.uk/itweek/news/2209560/dell-cosies-channel-partnersSource: ChannelWeb 22 Oct 2007 http://www.crn.com/it-channel/202600375Source: CRN 5 Dec 2007 http://www.crn.com/software/204700458Source: ChannelWeb 5 Dec 2007 http://www.crn.com/software/204700458?pgno=2Source: Financial Times 7 April 2007 http://www.ft.com/cms/s/0/b9c8e988–042d-11dd-b28b-000077b07658.html?nclick_check=1Source: Channel Register 13 Feb 2008 http://www.channelregister.co.uk/2008/02/13/dell_partnerdirect_emea/Source: ChannelRegister 27 February 2008 http://www.channelregister.co.uk/2008/02/27/dell_saas_roadmap/

1.

2.

3.

4.

5.

6.

7.

8.

9.

Figure 5: Linking Business Value to SOA Investment

cbdi journal © Everware–CBDI Inc, November 2008 21

Q & AHuman component of heightened fear and uncertainty inhibits SOA strategy?

Last month I commented that there is considerable evidence that SOA activity is under threat because of the “credit crunch” and the immense business pressure enterprises are now experiencing. In the editorial and prior blog I made the assertion that by “employing SOA principles effectively we will be addressing the key issues facing all enterprises (including governments I might add) of reducing cost and increasing flexibility, agility or whatever the term du jour is.”

I received numerous comments on this opinion both positive and negative. The following comment is particularly interesting:

“I’m responding to your recent CBDI article on SOA and the financial crisis – that now more than ever organizations need to use SOA. I agree that is an IT strategy (i.e. SOA) is fundamentally sound and should be valid under all financial conditions. But, though that’s fine logically and intellectually, I think the article misses the human component of heightened fear and uncertainty that arises. In that situation, I think, most people, even if unconsciously, avoid anything that resembles change. They hunker down, circle the wagons, etc. As you noted . . .”just get my projects done”. And regardless of its logical underpinning of well architected functionality, modularity and flexibility, SOA is perceived as new. And new is change, and change is threatening amidst chaos. Again, I believe all this “thinking” goes on as an unstated undercurrent to business arguments. I would be interested in hearing your thoughts about how to portray continued, or even accelerated, SOA adoption under the guise of: this is the safest, fastest, cheapest way to do things right now.”

First let me thank my correspondent for the question. I am very conscious that many of us are under great pressure right now, and not just those in the financial sector but also those in business and government who are faced with reduced budgets and resources and often considerable reorganization.

The question of how to portray SOA is highly relevant, and this is part of a bigger issue of how to manage more effectively in periods of crisis and considerable change.

First it’s important to characterize SOA as a set of principles. CBDI has advised for years that it’s the principles that deliver the core business value with separation of concerns, technology independence, abstraction, standardization and so

on. The deployment of the principles can be implemented on many levels and with careful thought based on good service architecture and engineering deliver huge leverage often for minor effort. It’s vital not to automatically think of SOA as a major program that must be addressed on an holistic basis; rather SOA principles can be brought to bear with the narrow focus precision of a laser on key areas of business design.

I can give you a practical example to illustrate this. As part of a series of SOA education workshops with a major UK high street bank earlier this year, we ran focus sessions for the participants getting them to apply principles to their own area of accountability. The results were really interesting because the ideas generated mostly didn’t entail grand, enterprise wide initiatives or programs, rather they could mostly be incorporated into existing projects, programs or statements of work. There were dozens of ideas generated in each workshop and we ran some 10 sessions in the series and there was little duplication.

A few examples illustrate:

Coordinating services to fix cross application data inconsistency.

Sharing of factory patterns to accelerate creation of largely common services

Introducing common schemas for utility services as a first step to standardization

Second I suggest SOA must not be viewed purely as an IT strategy. It’s absolutely vital to get business managers involved as early as possible. The “bottom up” activity referred to above is vital in order to have proof points, but driving out sanity in architecture and design is a business design issue. Only business people can provide policy direction on issues of standardization vs differentiation; the identification of core and context that will drive IT response to agility requirements.

Again I have good, recent personal experience here where mid to senior level business managers, properly briefed, can provide the essential business perspective guidance that enables effective IT strategy.

•

•

•

“I think the article misses the human component of heightened fear and uncertainty

that arises. In that situation, I think, most people, even if unconsciously, avoid anything

that resembles change.”


Q and A continued . . .

The biggest issue as I see it is getting the attention of business people. Forget trying to tell them about SOA. Instead characterize the decisions to be made in terms of business capability, cost, benefit and risk. I accept that in difficult times it can be really difficult to get heard above the noise created by crisis. However that merely increases the necessity to characterize choices in terms the stakeholder understands.

Where there is an atmosphere of heightened fear and uncertainty you might develop a top 10 “to do list” along the following lines:

Adopt SOA principles at all levels of planning, architecture and design. Identify the areas where loose coupling, abstraction and standardization particularly will deliver business value fast.

Adopt combined bottom up, top down strategy to establish confidence and trust with minimum risk.

Don’t economize on training and skills development. Make sure everyone is well briefed in general principles and key architects, designers and program managers have detailed understanding. (Checkout the CBDI eLearning modules.)

Look for narrow path quick wins that demonstrate the business value and provide proof points.

Use structured approaches such as the Critical Business Issue (CBI) technique, complemented by scorecards to develop narrow focused business relevant opportunities. Provide key business managers with relevant choices that are justified in business terms.

Discard opportunities that don’t provide clear payback in both business and IT terms.

Work with program managers to develop process improvement in project management and provisioning – that enables architecture led, evolutionary delivery with good governance.

Ensure there is adequate inhouse control over architecture. Avoid the lemming like rush to outsource or offshore absolutely everything as a pure cost saving mechanism. It might bring short term cost reduction, but medium and long term arthrosclerosis of the business. Get the balance right.

Focus on driving out benefits from separation and componentization – particularly testing.

Create a virtual community of interest (CoI) to share good and bad experience across projects. Use the CoI to coordinate the reuse of all manner of artifacts and to generate a “can do” environment.

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

Over the past year I have observed several companies in deep crisis. From this observation I conclude the quality of decision making typically deteriorates in proportion to the depth of the crisis. Examples include sweeping decisions to offshore core business functions in their entirety losing control over essential architectural decisions; firing the entire enterprise architecture function because they are perceived not to contribute to short term ROI.

My advice is that in times of crisis it’s vital that decisions are higher quality and that SOA principles and strategies provide a good yardstick (comparator) for assessment.

David Sprott


The author comments on his blog that this book is written in the style of a business fable. He mentions Lencioni; I immediately think of Goldratt, one of my own favorites with The Goal – a management text written in the format of a “love story” and the follow-up It’s Not Luck. Todd’s book has a similar although somewhat more prosaic style, interwoven with technical explanation. Notwithstanding comparisons, this book definitely has the power to transport me straight back into the small, anonymous meeting room where I am in the thick of an argument with my peers about how to balance architectural necessities with project imperatives.

Todd tells the story of how a fictitious company – Advasco, supposedly a leading financial conglomerate, went on its SOA journey. In the process Todd relates how the Advasco folk made just about every mistake in the book, stumbling from pillar to post in their efforts to embrace SOA.

They started with the seemingly simple task of providing a single customer view across a number of recently acquired companies. Taking a Web service technology led approach they predictably bumped into a whole raft of issues such as lack of coordination of delivery schedules, providing consumers with access to unstable development services, unstable service specifications leading to uncontrolled changes and the inevitable multiple concurrent versions. They go on to demonstrate the issues of project independence, lack of service ownership and many more.

The author’s conversational style makes this narrative absolutely real. For example there’s one very illuminating chapter on service versioning in which Todd develops the story of how a project decides to use an existing service and as usual makes some functional demands that extend the current specification. How it occurs to them that the impact on existing consumers is going to be tough to handle, not on technical grounds so much as cost and timescale. Eventually they figure out how to make the upgraded service backwards compatible with the existing service that would not require concurrent upgrade for all consumers, and how to manage service location and naming to minimize change.

Of course this solution required heavy, time consuming negotiation, and it dawned on them, as senior management started weighing in, that this just wasn’t a scalable model. So further debate ensued ending up with a policy around number of supported versions with reasonable time to allow existing consumers to upgrade.

It is clear the author has lived in the SOA trenches and has all the scars and wounds. The result is that Todd provides really deep insight into project practices and how project teams are destined to fail with SOA unless some radical changes are made to time honored practice. The book is very strong in this area and makes an entertaining, if somewhat worrying read – I did wonder if Todd should have put in a disclaimer that the events he describes have no bearing on what happened in his own company – Monsanto or his consulting clients! But quite honestly I enjoyed the book because it does portray what is, or has been going on in every enterprise adopting SOA. And the conversational narrative provides a real world perspective rather than a more theoretical approach.

While the book provides a thorough and entertaining coverage of SOA practices, with a particular focus on reuse, it is relatively light on other aspects of governance such as planning, architecture and design, sourcing etc. For example I thought the explanation of versioning was excellent, but in my experience even a fairly small enterprise would need more than one versioning policy, probably based on class of service. So for example utility and core business services (with a high user population) would have a very different economic profile to say capability or process services. Also I would expect a protocol for clear exceptions, such as enterprise level 360 degree services.

In conclusion, while this is not necessarily the definitive book on SOA Governance, it is a really practical introduction to SOA practices and in particular an excellent explanation of what not to do – or anti-patterns. It is worth reading purely for this insight. Recommended.

David Sprott

Reference: ISBN 978–1-847195–86–9 Packt Publishing Ltd. 2008

1.

Book ReviewSOA Governance by Todd Biske

The key to successful SOA adoption in your organization

About CBDICBDI Forum is the Everware-CBDI Inc. research capability and portal providing independent guidance on best practice in service oriented architecture and related delivery processes. Working with F1000 enterprises and governments the CBDI Forum research team is progressively developing structured methodology and reference architectures for all aspects of SOA.

CBDI ServicesA CBDI Forum Subscription provides a corporation or government department with access to a unique knowledgebase, ongoing continuous practice research guidance materials and hotline access to CBDI Forum experts. The monthly CBDI Journal provides in-depth treatment of key practice issues and guidance for architects, business analysts and managers. Members are encouraged to interact by commenting on CBDI Reports and Knowledgebase content, interacting in CBDI blogs and participating in CBDI reviews.

CBDI Forum provides:

• Gold Membership – enterprise subscription to the CBDI Journal

• Platinum Membership – enterprise subscription to the hosted SAETM Knowledgebase plus CBDI Journal

• Silver Membership – individual, independent consultant’s subscription to the CBDI Journal

• Education Workshops and Seminars – providing indepth education on architecture, process and practice. Public and In-house classes are available.

• Consulting – guidance in all aspects of SOA adoption, architecture, design, implementation and management

Contact UsFor further information on any of our services contact us at: [email protected] or +353 28 38073 (International)

IMPORTANT NOTICE: The information available in CBDI publications and services, irrespective of delivery channel or media is given in good faith and is believed to be reliable. Everware-CBDI Inc. expressly excludes any representation or warranty (express or implied) about the suitability of materials for any particular purpose and excludes to the fullest extent possible any liability in contract, tort or howsoever for implementation of, or reliance upon, the information provided. All trademarks and copyrights are recognised and acknowledged.

The CBDI Journal is published 11 times a

year and is the primary research vehicle for

Everware-CBDI developing and documenting best

practices in all aspects of Service Architecture and

Engineering..

For more details see: www.cbdiforum.com

Independent Guidance for Service Architecture and Engineering

issn 1745–1884 cbdijournal · and business design that facilitates a managed level of agility. by...

Documents