Artifacts, Events, Capabilities and Resources
the four components of any service
Everything that is important within a service can be sorted into one of four buckets: Artifacts, Events, Capabilities and Resources. The demand for any service can be expressed in terms of Artifacts and the Events provided for, while everything needed to fulfill the demand can be expressed in terms of Capabilities and Resources.
This four term taxonomy of services lays down a foundation for the language of services.
Four Components of any Service
Our first pass at understanding a service is in terms of affordance and performance. Affordance represents demand, what the business needs. Performance equates with supply of capabilities and resources to meet demand.
Consider the example of an enterprise IT organization. We might find demand in the form of a SOW and requirements, along with a statements of desired outcomes. We might find supply in the form of a vendor who, for a price, undertakes to make these hopes and dreams of the business come true.
Misalignment between the SOW the actual underlying services can result in significant inefficiency. This could be in the form of increased collaboration costs when components of a service are funded outside the SOW, or increased transaction costs when service boundaries are undefined or ambiguous. The opportunities for loss are everywhere.
For improvements a fighting chance to stick, we need unambiguous language to talk about the components of services. Every service is unique, but there needs to be a standard language that we use when working out service design, to aid in arriving at a common understanding. Words are tools in crafting a solution, and it won’t do to use just any word, when the right one is needed.
The demand concept of affordance can be broken down into two components: Artifacts and Events.
Artifacts are things with shortcomings, realized by Tasks.
Events are things with shortfalls, which are realized by Access.
The supply concept of performance can also be broken down into two components: Capabilities and Resources.
Capabilities are things with skills, which are realized by Activity.
Resources are things with surpluses, realized by Availability.
Thus, each of the above service components have a reciprocal: Tasks, Access, Activity and Availability, keywords which extend the the base vocabulary introduced above.
The terms shortcomings and shortfalls are clues that indicate demand, or affordance. The terms skills and surpluses are clues that indicate supply, or performance.
Artifacts and Events are needed to express demand. Capabilities and Resources are needed to perform the activities needed to make the magic happen.
Think of it this way: a SOW implies
- Artifacts which express their needs as Tasks to be performed.
- Events which express their need to be Accessed as the performance of tasks changes the state of the service.
A contract to fulfill a SOW implies
- Capabilities to fix shortcomings thru Activities that perform Tasks
- Resources to fill shortfalls through Availabilities.
We can reverse the expressions:
User Stories are artifacts, and putting a story into work is an event. The business creates demand for service by specifying the stories.
- The performance of Tasks is governed by artifacts.
- Access governs the initiation of events.
Vendors supply talent who make themselves available to pick up user stories, to transform the intent into something deliverable.
- The performance of Activities depend on having the right capabilities.
- Availability governs the consumption of resources.
The language of affordance and performance is abstract, and we need to put it into domain specific context to develop the ideas, but if we go too far in this direction, we risk loosing the kind of generality we need to preserve at this early stage in the discussion.
At this point, we now have eight keywords in our vocabulary. We’ll need shore up our shared understanding of this taxonomy with additional detail later, but first, we need to extend the taxonomy to include gives us the means to encode strategy.
Patrick Hendry — "patrick-hendry-SD6IsqeAAjw-unsplash"
Alex Conrath — "Niagra Falls"
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.