An All-Services Approach to Modeling Business

Comments: 1
Rate this:
Total votes: 0

“Man is the model-making organism par excellence … Myths, philosophical systems, and science represent different types of models of what social scientists call cognitive systems. The purpose of the model is to enable the user to do a better job in handling the enormous complexity of life. By using models, we see and test how things work and can even predict how things will go in the future. The effectiveness of a model can be judged by how well it works, as well as how consistent it is as a mechanical or philosophical system.” Edward T. Hall – Beyond Culture

Introduction

The ability to explore business issues through models lies at the heart of the business architecture discipline. Business architecture models capture the essence of the business, how the parts relate to one another, and how the business interacts with external entities and forces.

Here I’ll present a powerful, unifying, all-service focused modeling method, viewpoint, and architectural style. The perspective here is that everything done in a business consists of services. I have explained the rationale for this single-minded focus on services in (McDavid 2015). Here it’s enough to know that service exchanges form the focal point of this model. In its simplest possible form, service exchanges bring providers together with recipients, in order to satisfy human desires. There is a simple, basic pattern of this method, which features services, service-roles and role-players. A simplifying feature of this pattern is that the same structures can be used to represent people, groups of people, and with artifacts (tools, apps, buildings, vehicles, and resources of all kinds) as providers of services. Let’s look at services first.

Services

Here’s a look into the heart of the method – a service. As shown by Figure 1, the basic pattern of a service includes a provider and a recipient, interacting to try to satisfy some need, want or desire.

Mcdavid Services Image 1

                                        Figure 1 – A Service

A service allows provider and receiver service-roles to interact. Here they co-create certain valued results. Value is thus co-produced between the provider and the recipient.

A simplistic protocol for exchange might include:

  • alignment (understanding) about desires and the ability to satisfy them
  • agreement that one party should provide the service
  • actual enactment of providing the service itself
  • acknowledgement of the service as enacted

That basic protocol may be elaborated in many ways, through negotiation, extended performance, meeting any number of conditions of satisfaction, complex payment and feedback arrangements, etc.

Roles

Service roles are similar to roles played by actors in stage and film. The interactions among service roles are like small, focused plays, which may be more or less scripted. What stories does the business enact during the course of doing business, and what are the interactions among the participants in those stories?

Mcdavid Services Image 2

                               Figure 2

Another simplifying feature of this model is the symmetry of two-sided role structures. As Lusch and Vargo put it, “actors in an exchange are both service providers and service beneficiaries.” (Lusch, 2014)

  • Every service role aims at fulfilling the desires its recipients.
  • Every role also has its own intrinsic needs, which can themselves all be modeled as service requirements.
  • Every role can both make and receive offers, and can produce and receive delivery of services, and is expected to evaluate and acknowledge enactment or performance of services.
  • Qualifications for performing each role include abilities, but also motivations for performance.
  • Performance capabilities and service offerings are developed to satisfy needs, wants, and requirements, both inside and outside an organization.
  • Basic steps for a services-role-player modeling method might include:
    o Specify the results desired from a proposed change in the way things are done
    o Articulate the nature of the services, service-roles and role-players that will be needed to produce those results
    o Discover or design the service-roles and the characteristics of the service-role-players that can perform to the specification
    o Repeat within nested and peer level services, performed by both humans and artifacts 
  • Both receiving and providing sides of this service role provide for compensation and reaction to their providers.
  • Compensation can be made in any of many forms of currency.
  • Some role-players are able to add value, beyond payments, by providing evaluations and feedback.

Defined by Service Offered

A further simplifying aspect of this method is that a service role is defined by the service it offers. In other words, serving needs produces results that provide value. The role is identified by what it does. This is a case where a few simple rules and structures can model situations of immense complexity. Specification of a service offering can be arbitrarily complex, and theoretically role definitions can match that complexity.

Mcdavid Services Image 3

                                                      Figure 3

Keeping a balance between under- and over-specification is the key to achieve compliance with the Law of Requisite Variety. Assuring that specifications and capabilities remain aligned to the needs and desires of recipients helps achieve compliance to the Law of Keepin’ It Real.

Recipient

An engagement between providing and receiving service-roles creates whatever results and whatever level of value occurs. Value is co-produced between the provider and the recipient. Abilities and needs are matched by aligning offers and demands.

Provider

The providing side of a service produces and transfers what will satisfy a need while the recipient only gains value through the use of the result of the service.

Mcdavid Services Image 4

                                                     Figure 4

The role specification for any service offering should model the desired characteristics of performers (role-players) to be involved in delivering this offering. The specification might address the integration of needed capabilities, the creation of the offering, and instruction of other role-players. This says that a service is not complete until the recipient has engaged and has been fulfilled to some extent. Fulfillment can actually be to a negative extent. We’re beginning to see an important (even predictive) pattern based on the fact that needs fulfilled by one service often turns provide into service-offering abilities for the recipient. In other words, one service is used to enhance the ability of the recipients to fulfill their service offering commitments to their downstream recipients.

Role-Players

Roles and actual performers are connected through the many-to-many relationship ‘role-player’. This service-role-player pattern can be seen as a fundamental representation and design structure that permeates the enterprise from top to bottom, and end to end. “An organization might almost be defined as a structure of roles tied together with lines of communication. The cellular units of organization are not [people], but, as it were, parts of [people] … acting in a certain role.” (Boulding, 1961)

Mcdavid Services Image 5

                                         Figure 5

There are specific qualifications that are required of a valid player of any service-role. Qualifications are indicated in terms of both abilities and motivations. From a human perspective, abilities include native talent and learnings, from both experience and classroom. The set of meaningful characteristics of a performer are revealed or passed through, by the role-player construct.

We have mentioned earlier that there are three general classes of entity that can be identified as legitimate service-role-players. These three are 1) an individual person 2) a group of people and 3) an artifact.

Individual

Both sides of the provider/recipient relationship require individual role-players who match profiles of characteristics, including qualifications and motivations.

Organizational

The potential role-player at the organizational level may be an existing organization (taking on a new service-role), or an organization can be created instantly to play a newly defined role. Unlike individuals, organizations are relatively expandable in capacity, but clearly trading off cost of additional staff, training, and paying a premium for skills that are in demand. Artifact Part of the usefulness of this model derives from the view that artifacts of all kinds can be treated as role-players in service relationships. Artifacts (including software, but also other assets of the business, such as buildings, vehicles, etc.) all can be seen as providing specific services. So the service-role profile for an artifact include its abilities, as well as availability, etc.).

Interestingly, when we think of artifacts as supplying services, issues of payment and accountability get recast in a new light. There are several key affiliated individual or organizational role-players that share accountability for the performance and effectiveness of the artifact role-player (technology, tool, etc.). Let’s look at this through an example, such as an automated teller machine (ATM):

  • Creators – Who designed the machine, and might be responsible for design features and flaws?
  • Distributors – Who sold and provided the machine to a bank?
  • Owners – Who owns the machine?
  • Renters – Who is paying for the machine to be installed and operational within the bank?
  • Installers – Who deployed the machine into position to perform its designated services?
  • Maintainers – Who keeps the machine in good working order?

At this time we’re moving inexorably into the era of the Internet of Things, where almost anything and everything will have status reporting and other software capabilities. That makes the distinguishing of all the types of artifact supporters more complex, and more urgent.

It probably goes without saying the interaction of artifacts and people poses an increasing challenge on the business architect. It makes it easier to assimilate the complexity if we keep in mind that it’s all just a network of service providers and recipients.

BA Work

The service-role-player pattern can be used in a top-down mode, a bottom-up mode, an inside-out mode and/or an outside-in mode within and beyond the enterprise. At any level or scale, the pattern prevails: services are pervasive and require service-role qualifications and specification, counterpart service-roles for co-production of value. Role-player linkages to entities in the universe of people, organizations, and artifacts clarify the necessary characteristics match the qualifications needed by service-roles.

As business architecture becomes more attuned to patterns of services, the more the power of this pattern begins to emerge. Figure 6 depicts the beginnings of a network of services, service-roles, and service-role-players. The articulation of the relationships between needs and abilities has the potential to create an essentially endless web of services.

Mcdavid Services Image 6

                                                    Figure 6

We see services being co-created by service roles who, in turn are involved with providing services themselves. Service roles are generally playing as both provider and recipient of services.

The path of logic draws us out toward the edge, by asking the following questions with respect to each service identified:

  • Who benefits?
  • How do they benefit?
  • What are they doing?
  • Repeat 

Business Functions and Processes

The business architect needs to be aware of the various areas within any business where services occur and explore each domain to show how they interrelate to form the whole enterprise organization. A natural way to think about this is that every internal and external organization performs services, as their very reason for being. It’s easy to see that services provide an architectural interface between functions and processes.

 

  • Develop and manage products and services - Research and development of offerings to the market both provide services that any viable enterprise absolutely needs.
  • Market products and services – The marketing function or organization provides the service of education about the organization.
  • Sell products and service - Sales is pretty much a standard service, in the eyes of the market.
  • Deliver products and services – Sometimes called fulfillment (getting a service to a recipient in a useable and value-producing state) constitutes an absolutely vital link in the web of business services.
  • Develop vision and strategy – People may not generally think of top executives as service-providers. That’s more of a particular view of services than a statement about the executives, and the unique services they provide as leaders of the organization.

Benefits of this consistent and simple viewpoint can be applied to many standard service areas, such as managing information technology, managing financial resources, managing the acquisition, construction, and management of assets, and managing enterprise risk, compliance, and resiliency.

Relation to Other Viewpoints

Adopting a modeling perspective focused on the service-role-player pattern does open up many directions to link to other architectural perspectives approaches and methods.

 

  • A service-role perspective provides a new view into business processes. Interfaces can depict the point where boundary objects document the working relationships among internal organizations, and provide clear targets for automation. The Service Exchange Protocol provides a readymade pattern to enhance and explore business processes of all kinds.
  • Data and information models can be easily based on the definition of services that change hands between providers and recipients. As a result, the importance of data can be more easily seen because it can be directly tied to the value created and captured at these interfaces.
  • Interfaces between providers and recipients also form natural boundaries for use case models, again hopefully noting any requisite value consideration.
  • The business model canvas (BMC) has become very common in the startup world (Osterwalder, 2010). The statements in a business model canvas can be phrased as services, especially in the sections for Key Activities, Value Propositions, and Customer Relations.

Diagnosing Business Issues

When we think of an enterprise as a complex system like a living organism, it becomes natural to realize that these living things may become unhealthy. We know that an inordinate number of them die every year. This creates an opportunity to use business architecture as a diagnostic tool, and the viewpoint we’re describing is ideal for that. Here are a few pointers for using service-based architecture to diagnose business pathology:

  • Service-roles that are occupied by overloaded role-players.
  • Role-player structures that have become too deeply nested.
  • Provider roles competing for access to the same receiver role.
  • Conflicting networks of co-production, vs. value-capture, vs. stability maintenance - such as:
    o If the enterprise is too focused on its own networks of reward, the customer is likely to feel exploited.
    o If cautious stability is too dominant, the enterprise is likely to fall behind in situations that demand innovation. o Micro-governance (systemic micro-management).
    o Overly lax governance anywhere within the enterprise
    o If the co-production is too dominant the enterprise may lose money on every transaction, while hoping to make it up on volume.
  • Failure to unplug services that no longer offer value, or have become obsolete due to ineffective sunsetting processes.

The willingness and ability for business architecture to step up to this kind of analysis would signal a new level of maturity for architectural thinking at the enterprise level.

Conclusions

Let’s emphasize two conclusions from this brief review of a service-dominant architectural viewpoint for business architects.

1. A service viewpoint is a powerful tool, which builds on a few simple patterns, and yet has tremendous explanatory and design power.

2. This approach has potential to greatly increase the effectiveness of business architecture as a vital business service.

References

Boulding, Kenneth, The Image, Ann Arbor, University of Michigan Press, 1956

Lusch, Robert F. and Stephen L. Vargo, Service Dominant Logic: Premises, Perspectives, Possibilities, NY, Cambridge, 2014

McDavid, Doug, All Services, All the Time: How Business Services Serve Your Business, Business Experts Press, 2015

Comments

Ankit Tara
,
posted 7 years 6 weeks ago

I agree with the service

I agree with the service model. It appears to take the Service Component Architecture of IT to the business level. Your terms are different, but you may want to take a look at the REA (resource, events, agents) model.

Join the Discussion

Remind me later

If you wish to make a purchase today and experience an error with the shopping cart, you can place your order over the phone. Please contact us at (508) 475 0475 x15 or toll-free within the U.S. at (855) 300-2686 x15.