Service Architecture

This article is part of our randomised, post-structural Let’s Build a Bank series of articles.

In this article, we discuss some core principles behind and practical steps towards developing a Service Architecture and how it sits alongside the other articles in this series, with particular reference to Service Alignment. This article briefly describes how the concept of Service fits into the constructs of Service Aligned organisations, and focuses primarily on how to arrange services as a Service Architecture (or Ecosystem) both within and beyond your organisation.

What is a Service?

A Service is the value you provide to your customers; it’s why your customers choose you and not somebody else to achieve their outcomes.  At the heart of your service model must lie the questions, “What does the customer need from us?” and “Why would they choose us?”

How is a service different from a product?  The obvious answer to this is, that a service is more than just the product; it’s the support around that product, the delivery mechanism, the value chain around it, etc.  Of course, all of those things are involved in delivering a service, and you will need to design those elements (see below) – that’s the “what” of “what’s a service?”  But that doesn’t get to the conceptual core of the difference, which is that a service is meeting customer needs with your offering, rather than levering your products into their lives.

Haier, the Chinese washing manufacturer, offer a good example – their products (washing machines) are pretty standardised in the West, but they have chosen to take a different approach; responding to the needs of the customer.  When a complaint came through that their machine was clogging when a farmer washed his potatoes in it before taking them to market, another manufacturer would have told him to stop washing his potatoes in it – after all, it’s for clothes, not potatoes, right?  That’s the organisation dictating how the customer uses their product.  Haier instead designed a model that can wash both clothes and potatoes.  They offer another line coated in plastic to avoid rusting, based on the large number of customers who place their washing machine outside the house, and others that can operate at sub-zero temperatures.  This is putting the customer’s needs at the heart of your service, rather than telling the customer how to use your product.

When thinking about services, I find it helpful to abstract as far away from the product as possible, and think instead in terms of customer results.  Lie Haier, this means that you don’t suffer from being constrained by what the product can do, or how you as an organisation think of the product.  When you’re building a service architecture, it also helps to think in terms of customer needs and customer outcomes, rather than products, although there is a relationship and you will need to develop and deliver products to support the service architecture, but this step should come after you have decided which needs you are supporting, so throughout this article we assume product development is an outcome of the service design process.

In technical terms, a Service is a configuration of Capabilities that delivers value to the customer.  OK, that’s a sentence that raises more questions than it answers, and needs to be taken in context of the other articles in this series to fully explain, and in this article we first demonstrate the relationship between services, processes, capabilities and organisation, how service architecture works from a governance perspective, and how to go about designing it, at a holistic level, although all of these topics are covered in more detail by other articles.  Let’s have another look at our Operating Model abstract to put this in context.

Figure BFB-BF-SA-1: Operating Model for Services

At first glance, it’s clear that a Service has all the same elements of a Capability or an organisation.  That doesn’t mean it’s the same as either of those things, though.  What it does mean is that it can, and usually does, include all of the same elements.  Which makes sense, when you consider that a service is a Configuration of one or more Capabilities – i.e. it delivers value to the customer via delivering certain elements of that or those Capabilities in a way designed to support that customer’s needs.  And of course, organisationally, it will be drawing on many parts of the organisation, or several organisations, which support those capabilities and again, all have these elements.  But that doesn’t help to define what we mean by a Service.

Services, processes and capabilities

Services, processes and capabilities have a lot of things in common: they are all organisationally agnostic, i.e. exist across organisational structures and may reach outside the organisation; they all require many elements of the Operating Model elements (although Processes have fewer than either Capabilities or Services).  It is therefore common for organisations to be confused about what is a Process vs. what is a Service vs. what is a Capability, so we’ll offer a comparison here:

• A Capability is a purpose of the organisation, that can encapsulate people, process and technology; it’s what the organisation does.
• A Service is a configuration of capabilities, that delivers value to the customer
• A Process is a predetermined set of activities and decision points, that is performed in a predictable way, with any given set of inputs resulting in a predictable set of outputs

NB a Case Managed Process is a special type of process that meets the above conditions but with so many potential variations that these are usually not captured in a traditional end-to-end Process view.  Many BPM tools will now support case managed processes as well as traditional linear processes.  See Case Managed and Core Standardised for more details.

NB: Service, in this context, has some parallels with, but is not directly analogous to, the IT Service definition embedded in BAIN, TOGAF and other Architectural models.  That doesn’t mean it subsumes the IT Service definition, and when building full Service Aligned organisations, it’s important to maintain the distinction, as IT Services in Architectural terms form an important component and shouldn’t be confused with the Service Aligned service concept, which is broader and applicable to full customer service delivery.

Beyond these broad distinctions, the nesting of definitions can be confusing.  Processes will often sit within capabilities and services, but may also flow across capabilities and support multiple services.  Capabilities are likely to support multiple services and processes, while also encapsulating other capabilities and processes.

As services configure many capabilities, processes may draw on many capabilities, and capabilities will themselves encapsulate both sub-capabilities and processes, the picture is not simple, but it’s important to be familiar with the different definitions as we expand on the topic.

Service Model vs Capability Map

Your organisation’s service model is the representation of how services provided by your business to its customers, internal and external, supports the full range of customer outcomes that deliver your organisation’s service objectives.  Typically, as with Capabilities, you will develop a number of views and layers depending on the audience and information needs.  As a whole, you should be able to test your service model against the service objectives to identify any gaps and any services that are superfluous.  It also helps you to identify which of your capabilities are supporting your services, and how any modification of those services or development of new services will require changes to your capabilities.  While your capability map as a standalone artefact supports decisions about which capabilities to standardise/centralise/offshore/outsource and how to prioritise development of capabilities, your service model in addition is a bridge between your strategy and the capabilities that support the services, which further supports decision making about capability development and prioritisation.

The service model is also in constant dialogue with your strategy and in particular with strategy changes driven by changing customer needs.  How do strategic changes impact your service model, and where are there opportunities in your service model that might translate into strategic opportunities?

For example, my strategy might be to build a USP in supporting small businesses in the catering industry, so my service model would include things like helping customers with all the usual business banking services in that sector, such as employee lifecycle support, revenue management support, supplier management support, and so forth.  So I would need to ensure I have capabilities that can provide payroll, cash management, supply chain management, accounting advisory, etc.  But I might also want to differentiate my business by supplying services to that customer segment that gives them a unique reason to choose me, over another bank, because I understand their business and the challenges they face.  So as part of my supply chain management, for example, I might also provide some additional capabilities useful to businesses dealing with a variety of suppliers of short life goods, such as fresh ingredients, which could be parameterised to support their more complex supply chains, or one that supports tip management.  Acknowledging that many small restaurants are owner-run, I might create configurations of my channel offerings that are more intuitive to people working with food and kitchen hardware than to somebody sitting at a desk all day.

This service model, then, will tell me what I want to offer via my services to the customers.  I can then overlay it on my capability map and identify whether the current capabilities support it, or whether there’s a need or an opportunity to evolve, change, or create new capabilities.  Building on that example and those capabilities:

Service: Employee Lifecycle Support

Selected Capabilities configured by the service:

• Employee management
  • Employee selection and onboarding
  • Performance management
  • Career management
  • Employee offboarding
• Payroll
  • Payroll
  • Tip reconciliation and allocation
  • Pensions administration
• Cash management
  • Cash pooling and booking
  • Tip pooling

Service: Supplier Management

Selected Capabilities configured by the service:

• Transfer of value management
  • Payments
  • Cash management
• Supply chain management
  • Balance sheet management
  • Supplier scoring
  • Inventory control management
  • Cold room order manager

In this example, you’re not making any money directly from every one of the extras you supply and you shouldn’t try to!  These are loss leaders – the cold room order manager is something you’ve partnered with a Fintech to provide, and the tip pooling and allocation system may be something you developed in-house, which don’t offer any direct financial return to you – but they are part of the service ecosystem you offer, and distinguish your lifecycle service as one with the customer at the heart.  They are also the things that create customer stickiness in the non-traditional world; your customers have quickly become accustomed to these aspects of your service, and to lose them would create a negative experience for your customers’ staff and suppliers.  The same cannot be said if they switch mortgages.

As discussed elsewhere, it’s not enough trying to think on behalf of your customers, although sometimes you may have great and important insights on how you can support them based on your better understanding of your organisation’s capabilities and how they can be configured differently to provide more useful services – think Henry Ford’s faster horse – but it’s also critical to engage with the customer and understand their behaviours, to come up with these insights in a way that really supports their business or personal needs.

This is why any view of the Service Architecture will usually be aligned to a particular customer (internal or external), and based on these views you can then build up an aggregate view of your services, aligned to capabilities, which allows you to make decisions about business model, capability development, outsourcing, partnerships, etc.

Here are some examples of service models in traditional and non-traditional banks.

Traditional Retail Bank Service Architecture

In the traditional banking model, services are product related and triggered by interaction between the Bank and the Customer, usually initiated by the customer:  There is a clear delineation between the bank as an entity and the customer as an entity.

In this model, there are a variety of organisationally agnostic services which support the customer’s needs.  While these are largely driven or triggered by customer requests, the sequencing and interaction of services is well understood and in some cases, one will lead to another.  Customer facing staff delivering the service can anticipate the customer’s needs and offer additional services accordingly, and there is an interaction between certain services across service families which can be predicted – for example, bereavement account closure can link to insurance payout services.  However, while there’s a sequence of likely events, there’s also flexibility in this model, allowing customer facing staff to flex their conversations and the way the service is offered, depending on the customer’s needs.  See Case Managed vs Core Standardised for further details of how this model works.

The benefit of this model is that it offers familiarity, while allowing you to adopt a capability based operating model, so that you can continue to offer customers traditional services and products which are familiar to them, while adopting more effective ways of working and a more personalised experience for the customer.  It works well as a model for segment specific banks with a clear limit to the service offering they want to expose to their customers.  It also works well as an interim state towards offering a wider service model with more tight integration with customers and less clear divisions, as in the ecosystem model.

As you evolve your Service Architecture, another key benefit is, of course, identifying gaps, synergies and the opportunity to evolve the supporting capabilities.  While mapping capabilities gives you a great opportunity to identify core utilities, opportunities for consolidation and outsourcing, as well as gaps, the service view also adds the dimension of identifying further gaps, and superfluous capabilities, and to prioritise change based on your customer needs.

It’s important to note that while Service Architecture can look superficially a lot like a capability model or a customer journey, it both contains different information and gives you different opportunities for decision making to both of those very important artefacts, so it’s critical you don’t try to lever one into the other.

Ecosystem Small Business Bank Service Architecture

In the Ecosystem service architecture, the distinction between customer and bank or customer and supplier becomes deliberately blurred.  As well as supporting the customer’s traditional banking requirements, the bank is also supporting the business (or personal) goals of the customer beyond those services, and supporting partner organisations in providing services to their customers via their ecosystem.  The customer also helps the bank to evolve its thinking, as it, too, learns and grows based on the support offered by the bank and partner services.  The strength of this model is both its flexibility and that it offers symbiotic opportunities to the customer and partner organisations alike – and of course, the partner organisations are likely to be customers too, and have their own ecosystem service architecture view of the bank.

Key differences of this model to the traditional bank model are:

• Not request driven; many services are integrated and/or triggered by the ecosystem rather than by a request from the customer directly; for example, in this illustration, the cold storage and stock control system interacts with the menu planning system, data from customers, broader data analysis and supplier data, to tell the management team which ingredients or dishes are out of stock, going end of life, fashionable/written about externally, popular with their customers, or cheap, which offers the customer the opportunity to design menus and pricing.  This then interacts with the order management and cold storage systems, which in turn manage orders, while the order management system interacts with Payments, and services such as Distributed Ledger and Supply Chain Management as needed.  Managed through digital identity authentication, the Internet of Things and an ecosystem of apps, checks and balances are in place to alert humans of any suspicious conditions and invite direction in creative decisions, but otherwise things run smoothly without significant human intervention or the need for requests.  Of course, customers can, and probably do, choose to select some but not all of these services, leaving manual or alternative flows in between, but the decision about how much to manage by request versus how much is integrated is in their hands.
• Services are not clearly “captive” or “outsourced”; some are jointly managed (the teal boxes), others are partnership (the red boxes), others managed internally to the organisations involved, but in most cases it’s not really important who provides the technology or service element; they key differentiator is how these add up to support the customer in managing their business.  On the whole, organisations will “own” the services core to their USP and partner with other services which are core to other organisations, and key to this model is the bank supporting the small business in becoming part of, and enabling their integration with, this ecosystem, to maximise their own growth potential.
• Note that, in this model, the bank offers both payments services and core banking supported by third party providers.  This is because both those services are managed as Core Standardised capabilities by third party providers; the bank’s core USP, which doesn’t even feature on this customer centric model example, is in designing and maintaining these ecosystems, applying banking know-how to support customer operations and growth, thereby providing the scaled services you do see; including the Business Model Development advisory which is an offshoot of this USP.  See New Standard Models for Banking for more details of this.

The margin for the bank comes from a number of sources – obvious ones like Payments and account management, plus small but useful margins on scale services that wouldn’t otherwise be available to the business.  So while, for example, the bank may facilitate the integration of IoT to the ordering system for free, there are opportunities in the value chain to inject reasonable margins, which will grow as the customer’s business grows.

In this model, the blue boxes are services run by the bank, the green ones those run by the client, the red ones by partner organisations/ecosystems and the teal ones bank/client partnerships.  We don’t key the model because it’s supposed to be obvious.  But the point is, the distinction of who does what becomes less important in this model.

Services and Customer Journeys

As referred to in the narrative for the first Service Architecture model for traditional banks, there’s a strong relationship between Services and Customer Journeys, and the same is true of the second example, although it’s harder to see (and draw) in the Ecosystem model because of the integrated nature of the ecosystem.  You could equate the little buttons in the service element on the traditional model to customer touchpoints (or “moments of truth”) on the customer journey.  That doesn’t mean that services equate to customer journeys, however: a customer journey will detail the instance of a use of a service, rather than the whole service, and may also include multiple services.  A customer journey, while an abstraction, is essentially ephemeral, while a service, although mutable over time, is a static part of your service architecture, embedded in your operating model, and carries all the potential states needed by the customer journeys that might apply to it.

Why is this useful?

We’re presenting a lot of models and ideas, and this may seem one too far.  Why is your service architecture important and why can’t you just stick with the purpose of what your organisation is trying to achieve via a capability model?

Thinking about services reminds you why you are in business; it allows you to identify the capabilities that are supporting your customers, and reflect their needs in terms of capabilities that you can then develop to deliver a great customer experience.  More usefully, it’s also an evolution of the ability to identify which capabilities should be consolidated / outsourced / offshored / removed; it helps you to identify capabilities that may not be core to your perception of your business, but in which you can provide expertise which will support your customers.  The development of partnerships and business models is a good example of capabilities that banks usually have, but don’t use to support their customers.  When working for one big bank, as a Change person with expertise in setting up banks, I was outsourced to support both startup banks and NGOs that were customers of theirs and who were going through the process of building and executing complex business models – the customers benefitted hugely from my experience, and while the bank made nothing but goodwill from it initially, they indirectly realised the value of my services as a lever for securing long-term customer loyalty and lucrative payments services for the new banks and a lot of good publicity in the business community via the NGOs.  The success of these organisations under their new business models also created continued revenue for the bank, as they thrived and grew.  This model allows you to optimise the offering to your customers by really thinking about the services you can offer them and, in a coordinated fashion, to benefit both parties.

The ecosystem approach takes this one step further, treating both customer and supplier as business partners, and offering a model where, acting as a partner and intermediary, the bank can support growth in both so that all benefit, directly and indirectly, not just from the expertise of the bank, but also from the services they offer to each other.  Central to this is the concept that expertise gained by banks can help other organisations to develop more effective business models, just as when I was being offered as a free commodity by that traditional bank.

Of course, the ecosystem model is much more reliant on service architecture, partly because the scope is more complex, but also because it is much more based on multiple entities rather than captive services.  In the ecosystem model, if there is a central entity, it is is the customer and the bank is very much part of the wider support system; the challenge in visualising it is not so much that the delineation between customer and bank is not well defined, but in that it’s difficult to define where the “edges” of the ecosystem lie; this means that in ecosystem organisations, any view really has to start with a single customer entity, as this allows the focus to identify what is part of that particular ecosystem and what’s excluded.

As we hope is clear from the example, this makes it much easier to make decisions about where you want to play, additional services you want to include or exclude, and how you plan to present your service offering to customers.  It doesn’t make it any easier to identify which services should include outsourced or insourced capabilities, and indeed, this is really a question to address to your capability model, as covered elsewhere.  It does, however, provide focus and ideas for where to look for partners to support the ecosystem model further, and help to identify any capability gaps to be addressed.

To identify capabilities you don’t need or want to develop, you will have to compile the results of multiple capability analyses against your service models.  This will help you to identify which common capabilities are critical to supporting the models, which ones you want to keep captive, and which ones you may want to outsource, as well as which ones you want to retire or merge with more useful capabilities.

Both flavours of service model also allow you to associate cost and organisational structures supporting those capabilities with the market revenues generated from the customer segment, based on volume and cost of management. The advantage of applying a service view to the ecosystem business model is that you can analyse services holistically rather than piecemeal, without having to separately account for loss leaders and, to a large extent, reducing the need for ringfencing of innovation costs, as the direct needs of your ecosystem model clearly articulate where the capability gaps are and the business benefits of developing capabilities and services to fill those gaps.

These models also support your ability to identify key marketing and sales generation ideas, as they take you to the heart of the customer need – whether in the traditional or ecosystem model, so you are less likely to blunder into focusing on trying to sell the things important to your bank, rather than the things important to your customer, or into wildly inappropriate advertising that looked like a great idea at the time.  They help you to keep the customer clearly in focus at all times, and in all decisions.

For the same reason, they are also useful tools to communicate to your workforce and partners where everyone sits in the ecosystem, how they can add value, and get some great ideas for how they could change things to add even further value.  I would recommend keeping your service models on the walls of your office, many times over the typical motivational posters and empowerment bullshit we see in most corps –“it’s all about the customer” is much less effective than a visual that effectively says, “X marks the spot” for both customer and whichever capability to which that department delivers.

But service models aren’t a silver bullet, any more than capability models or process architecture are.  Your service architecture needs to be firmly rooted in your business strategy, and closely analysed for achievability, ROI, cultural fit, and all the usual drivers.  Of course, they also enrich all these aspects of your organisation and build understanding from strategists and financiers through to the front line – and beyond, in the ecosystem model – of the value they are adding, and thus enabling them to participate in the improvement dialogue.

Service Architecture and organisational structures

The service view of your offering, whether traditional or ecosystem, while still an abstraction of your offering, can also help you to structure your organisation much more directly than capability models can.  Where capability models are fantastic for identifying capabilities you want to consolidate or outsource, and are critical to getting your support service architecture right, your service model gives you the ability to make decisions about organisation structure at the customer facing edge of your organisation.  Of course, this also applies to internal service and the organisational design supporting these, but the smart organisation will focus primarily on how best to align its services to its external customers; in nearly every case, this makes your internal services easier to organise as well.  Organisational considerations are covered in the articles on Service Alignment, Case Managed vs Core Standardised and Communities of Practice.

When building your broader organisation with Service Architecture at the core, it is also critical to align your communication governance to the service model.  This can be achieved by comparing how your services map to your capabilities, and overlaying the governance structure between capabilities against this comparison.  If there are governance structures enforcing alignment across capabilities that don’t support related services, there may be good reasons, but it’s worth considering whether this governance will help or hinder your ability to support customer services; conversely, you will quickly see where there are communication gaps between capabilities supporting the same service.

Conclusion

In this article we have described the core concepts of Service in contrast to Capability and Process; we’ve described two contrasting service architecture approaches, together with the benefits and approaches recommended for each approach.  We’ve discussed why it’s important to have a service architecture and the central role your customers play as you build your service catalogue and align your organisation to the services.  Key points are:

• Services need to start with the customer – they’re the only reason you’re providing the service

• Your services should be the starting point for how you structure your organisation – the organisation should be structured around the service and your customer, rather than expecting your customer to navigate your organisation
• Service architecture helps you identify both where you need to focus, and where you don’t want to focus
• Service architecture should reach beyond your organisation to understand your customer’s needs holistically and how your partner organisations impact the customer experience
• Services, Processes and Capabilities have different focus and drivers; all are needed to build an effective service aligned organisation

Please also read the other articles in this series to understand the details of how to do this.  Your investment will be rewarded.