Designing communication for a system of systems
By Rob Pierce | IBM Corporation
The system of systems provides a challenging and interesting area in the design, development, and delivery of technical communication.
Systems can be extremely complex, and contain many subsystems and components. The presentation of a system of systems adds layers of complexity both to the basic concepts of the system and all the details required for each area of the system that may be applicable to a type of user or role, function, or operation. It becomes more critical and yet more difficult to provide clear and comprehensive overviews and details of a system and its subsystems and components, as the complexity increases.
The Watson computer that won the game show Jeopardy is a good example of a complex system that is made up of many subsystems and components. There are subsystems for natural language processing, deep question and answering technology, and machine learning to name just some of the broad areas it covers. Each of these subsystems has many components.
This discussion connects to the topics presented by one of the keynote speakers at the 2010 SIGDOC conference, held in Sao Carlos, Claudio Pinhanez, IBM Research – Brazil.
The title of his talk was “Designing the Interaction and the Communication with Service Systems.”
In his presentation, Dr. Pinhanez discussed complex systems and touched on the design of communication for them. He also discussed many aspects of design of communication in complex systems where a solution is actually a system of systems, such as in Watson.
He talked about a design focus moving from human-computer interaction (HCI) to systems human interfaces (SHI) and explained that services in SHI have some basic characteristics such as:
- Inseparability: Services are produced and consumed at the same time.
- Heterogeneity: Service processes are highly tailored and quite unique to each customer.
- Intangibility: Most services create outputs which have highly intangible aspects.
- Perishability: The capacity to produce a service is lost when there is no request for it.
- Coproduction: The customer performs part of the production process.
- Customer as Input: The customer is a significant part of the input.
But where does design of communication (DOC) fit into this picture? Service systems and systems of systems represent an area for design of communication that requires much thought and planning for audience type, purpose definition, and context of use.
Dr. Pinhanez went on to explain that:
- Service systems have intent.
- Services systems are anthropomorphized.
- Service systems are in permanent and dynamic conflict with their users.
- Models of service systems must model human beings.
“The human facet of a service system is the set and configuration of elements that create and control the perception of and the interaction with its human characteristics,” he wrote.
If service science is the systematic study of service and service systems, then how do we define the DOC of service and service systems? The answer will be applicable to the DOC for a system of systems.
Careful thought in the DOC around your audience in many different contexts will yield a much more usable system, in part through better communication or user assistance.
For example, in addition to the work in designing interfaces for online services, what is the technical content and how do we make it available to developers, administrators, and third parties for industry or customer specific solutions or offerings and then, finally, the managers, team leads, and various other administrators, as well as analysts and other users of a solution?
Perhaps one of the key aspects to all design is in determining and defining what is to be visible and what is to remain transparent in a system of systems and services SHI. From this perspective, the DOC can then support optimal usability of the system with a solution design that provides the appropriate information and exposes different systems, components, services or functions in different scenarios, that is, to different user types, roles or contexts.
If a service is performed automatically, is there a need for the user to see it? Well, yes, if they need to be notified or do something when the service completes.
Should users only see a service if they need to perform some action? One answer will not cover all scenarios.
There are services where the user scenario remains passive versus interactive or where they trigger actions by making selections versus need to provide user input as parameters to services or operations.
Will it always be most helpful to have the user assistance directly in the user interfaces so they have the help where they need it while they need it?
It is probably more than ever true for a personalized or industry or customer specific service or solution where “knowing your audience” and structuring communication or user assistance accordingly can be an opportunity to enhance a product offering and help support users of all types and contexts.
The users in a system of systems may first include developers and administrators and testers of a system. Testers may be the first reviewers and consumers of user assistance who are trying to follow the tasks with the same goals in mind as customers or consumers of the system after it is deployed and made available.
Other critical users will be the people who need to figure out how to install, configure, deploy, monitor, and administer both individual systems and services, and the integration of all of them into the complete “solution” or collection of solutions.
So, in a system of systems, there may be an audience for installing and configuring a lot of hardware and software. System testing will be important before developers and testers begin using it and working on new and existing services in the system.
Who needs to know about which pieces of the system? Does everyone need to see the overall architecture of the system and if so, why?
If consumers of the system will only see a few of the services through a user interface such as a web browser or remote device, then they only need user assistance on how to perform the tasks available through those UIs, right? But the developers, administrators, implementors and deployers of those services need to see the much more complex picture or all the services that drive or have an effect on the services made visible to end users.
For the audience that will be responsible for handling data sources in the system, there may be issues around specific databases, such as format of the data or database connections. Data sources may include unstructured data through company email, wikis, notes in a corporate system for customer relationship management (CRM) or change management, or other social media applications and resources.
The way that the system operates and interacts through requests and responses or user input and system output may be highly complex and needing to be clearly described both conceptual and in detail for configuring it.
More details will need to be considered if this system is going to search a large amount of data in a very short time or allow a large number of users concurrently.
If the system can be customized, then how is data ingested into the system or made available for the searching. How are the searching mechanisms customized for improved results depending upon the data sources? How do you monitor and modify the results for better performance? What do you do to resolve errors when they occur? These topics are all critical areas of required user assistance.
But again, how best to make this technical communication available?
In thinking of a system of systems, perhaps context-based user assistance has never been more important. Since we cannot know in advance who does what, and what tasks and contexts apply to which types of users in all scenarios, perhaps user assistance that applies to specific contexts must be tied to the actual product interfaces so that help is there when the user is using the product and performing whatever tasks they must perform.
However, there still needs to be a more comprehensive structure of information, especially if or when a system of systems has different components that may not all be directly tied or bound together. A help system such as an online information center (for example, http://publib.boulder.ibm.com/infocenter/ramhelp/v7r5m1/index.jsp) provides this level of coverage.
An example of a services system
For the core technology that enabled the Watson computer to be compete in a game show, and rapidly and effectively answer questions with a high level of accuracy, there’s a front end, a back end and a pipeline between them that manages the complexity and performs most of the processing between questions and answers as requests and responses.
In this grossly oversimplified perspective, what portions of the system needs to be explained? The ones that some kind of user can do something with – configure it, tune it, and test it.
Some of the topics to document might include:
- Getting a system installed and configured – that is, ready for it to have data imported into it
- Getting the data into the system
- Training the system – machine learning and testing – algorithms for the deep q and a searches and results/answers – through testing and tuning the results for better results
- Monitoring the system – to manage and improve the performance and resolve any issues
- Designing how to surface the system into an offering
- Deploying the system and making it available
But the final design, development, and delivery will evolve based on the ongoing work.
For the design of communication of such a system of systems, that is, to make the underlying technology available for other solutions, let’s consider some of the systems in that solution and how to design the communication around them.
How would you determine which services needed to be documented and how would you describe them? The answer will be different depending on your audience. For example, would you try to explain the overall system and the role of the services that are made visible to users and then provide details on what you can do and how to it for each service? Or does the audience need to be able to set it up? Test it? Extend it to other applications? And if yes then how do they do that?
For an overall conceptual coverage, you may first describe what the overall system does and how it works. Then, you could present a view into the subsystems – or at least the concepts around some of those subsystems do.
If the system is based on user input and system responses, then what are the requirements and details for making the system ready to handle that environment?
Setting up the system is necessary and, similar to most solutions, the system will often represent a combination of hardware and software. Data storage considerations will need to be articulated.
The amount of data stored and the amount of analytics performed on the data, the algorithms used to search, retrieve, measure, and deliver a “best response” requires a massive amount of processing and data storage much of which will need to be described for server and database administrators who may be able to monitor and tune for performance.
If this system is made available for different applications of the technology, such as for health care diagnoses and treatments or financial planning, which services would the consumer of the information need to know about and configure?
I listened to one doctor tell me recently that he thinks medical records are notoriously poor in terms of clarity for future reference. He thought it would be great if some kind of search capability or machine learning solution could build a health record based on the inputs (such as natural language requests for diagnoses and treatments for a patient) and responses (the answers the system returned) could help build records.
What information would the doctor need to know to help build up such a record based on questions and answers?
If I am a doctor and want to use a Watson health care application, I only want to know how to use the system and what I can do with the available services. If I am the healthcare organization making the system available to doctors, the picture is not so simple.
Service characteristics and online interfaces C. Pinhanez. A Service Science Perspective on Human-Computer Interface Issues of Online Service Applications. International Journal of Information Systems in the Service Sector, 1(2): 1735, 2009.
Defining service systems C. Pinhanez. “Humans Inside” as the Key Characteristic of Service Systems. In: Proc. of International Research Symposium on Service Excellence in Management (QUIS’11). Wolfsburg, Germany. June 11-14, 2009