Home Page for APConnsulting
Home
Your needs
What We Do
• Insights & Ideas
About Us
Contact Us
What is Usage Architecture and how does it relate to
Solution Architecture?

The rapidly changing marketplace for technology-based products and services can be daunting for the consumer and challenging for those who attempt to design and deliver these products and services. The array of features, specifications, attributes, and prices present a confusing arena in which to make decisions. How does the consumer determine what is essential and what is a frill—what set of capabilities will be good enough? How does the vendor or service provider determine what options to offer, what packages to configure, which stakeholders “count”?

According to Clayton Christensen, products or services are most successful when they directly address the "job to be done"1; that is, when they focus on the true needs of individuals in specific roles and contexts. They tend to fail when they concentrate too much on attributes that should be of interest to the customer rather than analyzing the real target context needs of these customers.

We believe that we are moving from an information technology era (where the focus was on computers and the technological possibilities of computer-based components) into a post IT era in which whole solutions to a particular need are becoming possible with advanced technology. In this emerging area, computers are so deeply embedded into the technology that the average person no longer even realizes that they are in fact interacting with computers. For example, drivers who know about trip computers are generally totally unaware of the local area network of computers that is so common in today’s vehicles. Indeed, the term “control unit” very effectively masks the presence of the embedded computer for many consumers.

Similarly, manufacturers of digital cameras—which are not imaginable without embedded computers—market them based on attributes such as megapixels, LCD screen size, optical zoom range, and other features. Yet, the primary cause for missed pictures—the annoying shutter lag—is a direct result of the speed of embedded computer that must grind through complex digital imaging algorithms. Information about this embedded processor is almost impossible to obtain.

As we move away from the preoccupation with computers, we also find that individual components, once exciting by themselves, are now more highly valued when they function together to address a particular need. For example, few would argue that the Apple iPod competes not only due to its attractive design, but also because of the integrated iTunes application that facilitates organizing and downloading of music and the Apple Music Store that provides a simple way to purchase and incorporate music into the system. Add to that Podcasts and radio and the appeal of this integrated architecture is quite obvious.

We call this integrated system a usage architecture because the entire development is focused on the “job to be done”—the context, the functions and features, the ease of use, compatibility with existing systems, procedures, values, models, etc. all within an acceptable cost. Whereas usage2 focuses on a particular paradigm and the stakeholders within that target context, usage architecture focuses on the scope of the integrated whole needed to realize that paradigm.

Usage architecture addresses and formalizes those aspects of products and services that define:

  • Capability, which includes:
    • Classes or groups of users supported (operational and support as well as end users)
    • Roles and associated policies for filling and carrying out each role
    • Contexts in which the specified roles are expected to exist
    • Essential use cases3 for each role and context
    • Clear identification of the operations, functions, features, displays, information, data, etc. that matter to each class of users in each context
  • Conformability,4 which includes :
    • Ability to adapt the product or services to the way a business or customer already organizes and operates resources, minimizing the disruption and/or need for additional training
    • Ability to connect and interoperate with existing technology and information systems with minimal loss of control, flexibility, or information "richness"
    • Ability of individuals to customize products and services to their preferred way of working, and to save and maintain these settings across upgrades and personnel changes
    • Ability to modify the product or service in terms of the user’s value system (background on PC or phone, spoiler on a car, choice of a Toyota Camry hybrid, etc.)
    • Ability to use the same adaptors and replacement parts, such as easily available batteries, cartridges, etc., or to use easily available standard ones.
    • How physical attributes, such as weight, size, capacity, location, portability, signage, and operating characteristics fit the deployment environment.
    • For each key usage role: usability or ease of use, including issues such affordances5 and perceived affordances, as well as consistency, comprehensibility, and simplicity
    • System quality attributes may be key system capabilities. But many are less obvious characteristics that determine how well the system conforms to its target environment. Scalability, or security, or privacy, safety, or other attributes can dramatically influence whether a product or service appears to be appropriate or effective.
    • Assumed attributes that are often mandated by legislation, such as safety; accessibility; and compliance with emission, radiation and other requirements.
  • Cost or price sensitivity:
    • Customers pay a premium for products that are clearly more effective in one or more dimensions, especially if there is no apparent competition. Complex one-of-a-kind products and solution command higher prices than volume offerings.
    • As products and services mature, prices customers are willing to pay are based on competition and price wars rather than specific categories of effectiveness or mixes of features. In some cases, a simpler, less feature-laden interface will actually be more costly.
    • If cost arises early in the discussion, the customer is likely to already consider available products to be over-serving them6, or at least, they are looking at a market in which enough options already exist that they need convenience and conformability at a specific price point.

Usage architecture is a subset of solution architecture because it focuses on the aspects that directly affect the solution as perceived by stakeholders carrying out their work in the target context. These are the areas that matter and are most visible to the customer—it is important to get them right. They are the customer's "hot buttons."

Other characteristics of any solution (evolvability and compatibility with future product directions, technology details such as network topology, build versus buy component decisions, open versus proprietary platforms, protocol choice, staging, deployment etc.) can all impact the usage, but, when done well, are details of the solution that need not be visible to the stakeholders in the deployment context. Stated in a different way, usage architecture is a necessary and important component of solution architecture but it is not sufficient to ensure a successful solution.

1 This phrase is fully described in Seeing What's Next, by Christensen. Anthony, and Roth, 2004, Harvard Business School Press.

2 See related articles Are “Usage-Centered” and “Usable” Really the Same Thing? and Works with quirks is OK! To understand our definition of usage better. See other articles on the Insights & Ideas page.

3 Essential use cases are an abstraction of use cases; they focus more on the concept than the implementation. For example, when defining authentication to an ATM machine, a use case may describe inserting a card with a magnetic stripe and entering a PIN whereas an essential use case just lists authentication. The concept of essential use cases was first introduced by Constantine and Lockwood (see http://www.foruse.com/about/conditions.htm)

4 Christensen introduced the general concepts of convenience (or simplicity, speed, foolproof design, ease of use), customizability (the ability to do an individual customer’s idiosyncratic jobs), and price in The Innovator’s Solution and in Seeing What’s Next. To make the concepts easier to remember, we standardized on Conformability (a new term we have coined) and Cost Sensitivity for disruptive (over-served) contexts. There are 3 Cs (the 3rd is capability) in the overall model. We rejected Christensen's “customizability” as too limited in its implied meaning, and "convenience" was never correctly interpreted by those to whom we have presented these ideas. We believe conformability more completely expresses the need both to be customizable and to fit in with the business rules, existing systems, and values of an enterprise. Since "convenient" usually implies "no need to adapt or change the way I want to do things," we believe it is subsumed by conformability as well. The end consumer also has a context and values against which any offering can be evaluated.

5 Affordances and perceived affordances are visual cues about how things are supposed to be used or operated (or how they are operating) assisting the user’s cognition about the entity and minimizing the likelihood of mistakes. See our early paper on Time Affordances in CHI '95 Conference on Human Factors in Computing Systems proceedings (note this shows the correct Figure 1, which is wrong in the ACM online version). See also paper on on Diagnostic Affordances.

6 This is another Clayton Christensen term. Customers become over-served if the attributes of a product or service go beyond the point at which their needs are satisfied. It is already “good enough” and additional bells and whistles are greeted with skepticism about the resulting price.

 


 up arrow Return to link