Transparency of services

After Cardoso, J, R Lopes, and G Poels – Service systems: Concepts, modeling, and programming – Ch 1 White-box service systems – 2014

Where this is going (in terms of the family of USDL specifications):

The USDL specification proved too complex, and had little up take in the field. Linked USDL was developed to be simpler, and to incorporate Linked Data principles (e.g. URIs) and the Web of Data (e.g. reusable vocabularies). The Linked USDL specification continues to be viable, but it's a "black box" model of service, i.e. it doesn't model the "internals" of the service, but stops at the user interface. So Cardoso et al developed the Linked Service Systems USDL (LSS-USdL) as a "white box" model that allows the user to see and modify the "internals" of the service (also note: a "gray box" model allows the user to see and modify "some" of the internals, which is probably best, so as not to overwhelm the user with too many details).

Why does an effort to model "Service Systems" lead to the development of a "white box" model like LSS-USDL? Cardoso et al focus on the fact that the "upfront" Service in a Service System (i.e. the Service requested by the User) may engage another Service to provide some "internal component" in a manner that's best exposed to the User.

Service modeling approaches can be described and classified according to the degree to which the internal and external elements of a service system are visible to and modifiable by consumers in the outside world.The visibility of a service system can be studied from an external and internal perspective. The modifiability of a service system can be studied from an internal perspective. These two important variables, visibility and modifiability, have their origin in software engineering.

Example

Imagine that a consumer needs to interact with a particular service. For example, a service that calculates and prepares a tax return form for the fiscal year. The service is housed in a black box and has an interface with buttons, form fields, and status fields on the outside that allow consumers to download forms, upload forms, pay for the use of the service, and to check the status of the forms submitted. Consumers can only interact with the service without opening the black box and cannot see beyond its surface. It is only possible to see how the service works by pressing the buttons (inputs), filling form fields (inputs), and seeing what happens to the status fields (outputs or outcomes). The service takes certain inputs and produces outputs in response to the inputs. Perhaps because we do not know, or are not interested, or cannot afford extra time to understand, we make a deliberate decision not to consider what happens inside the black box that presents the system. The internal structure, in this case, is not considered or analyzed. A service that exhibits this behavior is termed a black-box service (Figure 1).

On the other hand, a service can also enable consumers to see and modify its internal elements. Consumers can potentially explore a service internally and also explore its subparts. Internal elements can be composed of business process models, people, business rules, infrastructure, IT, and security aspects, which are involved during service provision. By analogy, services that exhibit this behavior are called white-box service. In this situation, it is possible to look inside the white box and try to identify some of the elements that occur in the service, analyze them, and represent them with a series of models.

It should be noted, though, that it may happen that white-box services are composed at some point by black boxes. It is never possible to describe all the details of all the elements of a service. It is possible to go gradually into further depth in the service (which can be seen as having an element tree structure), providing more detail about its elements. As a greater level of detail is achieved, it is possible to find certain black boxes which we do not wish to, or cannot, consider in more detail. If that were not the case, the models of the service under study would end up being as complex as the original real-world service, and therefore would deliver little value for the purposes of service modeling.

The transparency of service

Figure 1. The transparency of service.

Classification of transparency

With respect to visibility and modifiability, four main types of service modeling approaches can be identified: black box, glass box, grey box, and white box. For all these types, interfaces are visible externally. If a service is a black box, it is not possible to modify or see its internal elements: it is used as-is. White-box service internal elements can be modified, even though this does not need to always happen. The term glass-box service means that a service has a white-box visibility but a black-box modifiability. A grey box derives from a white box for which only partial elements are visible and modifiable.

  • Black-box service
    • access to external interface
    • consumers have no knowledge of internal structures and processes
    • consumers cannot modify internal elements
    • external visibility from a consumers point of view
    • “as-is” service
  • White-box service (aka Clear-box service)
    • access to external interface
    • consumers have full knowledge of internal structures and processes
    • consumers can modify internal elements
  • Glass-box service
    • access to external interface
    • consumers have full knowledge of internal structures and processes
    • consumers cannot modify internal elements
    • functionalities can be discovered by inspecting internal structures
    • “as-is” service
  • Grey-box service
    • access to external interface
    • consumers have some knowledge on visible internal elements
    • compromise between black- and white-box services
    • services have a degree of “greyness”
    • consumers can modify visible internal elements

Black-Box Service A black-box approach allows describing a service with interface information that is externally visible to consumers. Nonetheless, the internal details of services are hidden. The black box implies that a service is used without seeing, knowing, or being able to modify any of its internal elements. The service provides an interface that contains all the information needed for its utilization. Therefore, it is not possible to make any assumptions about the internal behavior, governing rules, business processes, or state of a service. The implementation is hidden and cannot be modified by the consumer. On the other hand, the implementation of its internal elements can be changed by the provider without any effects on consumers.

White-Box Service A white-box approach is at the opposite extreme of a black-box one. It allows to completely expose service internal elements to consumers, beside exposing its external interface. With respect to the interface, white-box services have the same characteristics as black-box services. On the other hand, with white-box services, consumers are allowed to “peek” inside the service and modify internal structures and processes. The term “clear box” is also used in the field of software testing to describe this behavior.

Glass-Box Service The term glass-box service classifies services that are used “as-is”, like black-box services, but with internal elements that can be seen from the outside. Nonetheless, internal elements cannot be modified. This gives consumers information about how a service works without the ability to modify it. This internal visibility can be crucial for understanding how certain operations are carried out and finding the rules that govern a service.

Grey-Box Service When a service is viewed as a grey box, consumers have access to information that describes only part of its internals. Depending on the incidence degree of the “greyness”, a grey-box service can provide different levels of exposure of the service internal elements to consumers. They can see and modify the internal parts which were explicitly exposed by providers.

Benefits and limitations

Since the black-box view has limitations when it is necessary to discuss aspects of a service that do not appear in the interface description (for example, aspects related to the behavior of a service), this approach may not be always suitable for service system modeling, especially when consumers need to fully understand services. The approach falls down when a service needs to interact with third parties during execution since these interactions are not made visible to consumers. For example, when a front-end service has a back-end process representing its execution, the interactions with third parties expressed in the process are an integral part of the service. However, the black-box approach has positive aspects since it allows developing highly modular services and service compositions (i.e., business process models). As a consequence, any original service can be replaced with an alternative service as long as it has an equivalent interface.

White-box and glass-box services may in some cases be undesirable approaches since a consumer should be able to understand a service without being overwhelmed with the full complexity of services’ internal structures, processes, and implementations. This high degree of internal visibility may lead to dependencies on certain implementation details which become fatal when the internal elements of services are changed. Unfortunately, giving consumers detailed information about a service’s internal elements is often a compensation of nonexistent or insufficient documentation. While white and glass boxes enable defining exactly what a service does, and how it does it, they may in some cases be over-specified. On the other hand, this internal visibility can be crucial for understanding how certain operations are carried out. It may also give consumers confidence from being able to see inside a service and capture how it works. The observable internal elements may, for example, be state variables or interaction patterns. A suitable description should provide to consumers only the required information to understand a service, but no more than needed.

White-box modeling

One of the goals of the Linked USDL and USDL family was to provide service description languages for managers to formalize their organization’s services in a common, uniform format. However, USDL is limited to the description of a service from a black-box perspective, so a complete service system representation is not possible. Figure 2 illustrates this limitation. In other words, USDL views a service as a black-box and internal details are not modeled. For example, while the characterization of the provider, the technical interfaces to access the system, and the price of the service are all defined, no information is given about the roles and skills of the people which need to be involved, the physical and information resources required, or the physical location where activities occur. A white-box approach would enable to model in detail the information describing how a service works internally.

Relationships between business models, service systems, service models, service instances, and service descriptions

Figure 2. Relationships between business models, service systems, service models, service instances, and service descriptions.

A model that could formalize and describe a service system’s operations would result in many benefits, such as:

Transparency. A white-box description lets stakeholders to better understand how service systems work. In many situations, transparency increases organizations’ credibility, sustainability, and enables governments to clarify how taxpayers’ money is spent. Recent movements such as Open Data [20] and Open Innovation [21] claim for a greater level of transparency. Business regulations, such as Basel and Sarbanes-Oxley, which define a “pillar” for how a business should function, can also benefit from making their services more transparent to managers.

Analysis. Only after modeling a complete service system it is possible to get an overall picture while also being able to look at all the details. Using techniques for analysis, it is possible to identify potential drawbacks such as bottlenecks and fail points, and study solutions to overcome them. By using computer-understandable languages, it is possible to conduct simulations of interactions and behavior of service systems to aid managerial and operational decisions. Methods similar to process mining [22] can be used to obtain insights on how services are provisioned.

Multi-perspective. A white-box service system modeling tool can generate different service description views based on the stakeholder accessing the model and its objective. In other words, service systems can have multi-perspectives. Hence, customers may obtain a service description such as the one provided by Linked USDL; staff can obtain a description view depicting internal operations; and so forth. Those are all different views of the same service system.

Automation. The use of computer-understandable languages also enables to increase the level of automation of tasks, e.g., the automated generation of service documentation for customers and staff to better understand services. Documentation facilitates staff training and customers knowledge about service offerings. It is also possible to read service models, schedule and dispatch workers, and assign resources to complete service provisioning.

These benefits can foster the development of theories, methods, and tools to enable organizations and societies to converge towards economies which are truly service-based and service-driven.

[Additional from R Lopes, LaNDLESS: Integrating Linked Data with Linked Services, 2013:

One of the original goals of USDL was to address this issue and provide a service description language for managers to formalize their organization’s services in a standardized format. However, USDL is limited to the description of the service’s customer interactions, so a complete service system description is still not possible. In other words, USDL treats a service as a blackbox where internal details are not known.

A model that could formalize and describe the whole service system operations would thus facilitate managers’ transition from the currently chaotic service management to a formalized one. This would result in many bene fits, such as:

  • Documentation: Service systems would be modeled in a machine-readable language, which would make it possible to generate service descriptions for people to analyze and better understand it. This documentation generation facilitates staff formation, customers knowledge about the service off erings and so forth.
  • Transparency: A whitebox service system description would let stakeholders better understand what is happening. This would prove organizations’ credibility and sustainability and would let foundations and governments clarify where is people’s money being spent and justify potential decisions.
  • Bottlenecks and fail points identi fication: Only after modeling a complete service system it is possible to get a big picture view while also being able to look at all the details. If a service is well described, it should be possible to identify potential drawbacks such as bottlenecks and fail points and study solutions to overcome it.
  • Automation: If a service system is fully modeled in a machine-readable language, then all requirements are met for an automation tool to read that model and dispatch worker processes for certain inputs.
  • Simulation: Since we can model the full length of a service system in a machine-readable language, it is possible to conduct service system behavior simulations to aid managerial and operational decisions. Such simulations could be executed using the principles of System Dynamics.
  • Integration: USDL may already have some of the aforementioned bene ts, but lacks good integration of services with data and external services. Linked USDL tries to solve that problem by using Semantic Web technologies and integration with Linked Data, but it cannot fully address that problem because it still describes the service system as a blackbox. A whitebox service model, however, would be able to fully integrate with other data and services because it can provide the description of all its components.
  • Discovery: One of the goals of the Internet of Services (IoS) and USDL is to be able to describe services in such a standardized way that it might be possible to browse them in a generic online services marketplace. However, USDL can only provide a single service description, since it only models customer interactions. In other words, one service system generates only one service description, and thus it is not possible to generate a view or description for a manager with specifi c skills and another for an engineer with a di fferent set of skills and interests. A complete service system model would be able to generate dynamic service descriptions depending on what is relevant to display. Those service descriptions could then be aggregated in service marketplaces for easier discovery and comparisons.

Finally, a whitebox service system modeling tool could be able to generate diff erent service descriptions based on who is accessing it and what goals is the description trying to address at that moment. As such, customers could interact with a service description of customer interactions (such as USDL), staff could interact with a service description for internal operations and so forth. Those would be di fferent views of the same service system. Such an achievement might prove to be a very important advancement in the fi eld, potentially putting previous service models that generate a single service description to obsolesce.]

Previous: Linked Service System USDL (LSS-USDL) – Introduction
Next: Linked Service System USDL (LSS-USDL) – Perspectives, Definitions and Objectives

References

  1. Robert Glushko and Lindsay Tabas. Designing service systems by bridging the front stage andback stage. Information Systems and e-Business Management, 7:407–427, 2009.
  2. Jim Spohrer, Paul Maglio, John Bailey, and Daniel Gruhl. Steps toward a science of servicesystems. Computer, 40(1):71–77, January 2007.
  3. Holger Luczak, Christian Gill, and Bernhard Sander. Architecture for Service Engineering TheDesignandDevelopmentofIndustrialServiceWork.InDieterSpathandKlaus-PeterFähnrich, editors, Advances in Services Innovations, pages 47–63. Springer, Berlin Heidelberg, 2007.
  4. Henry Chesbrough and Jim Spohrer. A research manifesto for services science. Communications of the ACM, 49(7):35–40, 2006.
  5. Paul Maglio, Savitha Srinivasan, Jeffrey Kreulen, and Jim Spohrer. Service systems, servicescientists, SSME, and innovation. Communications of the ACM, 49(7):81–85, 2006.
  6. Stephen Vargo and Robert Lusch. Evolving to a new marketing dominant logic for marketing.Journal of Marketing, 68(1):1–17, 2004.
  7. Andreas Zolnowski, Martin Semmann, and Tilo Böhmann. Introducing a Co-Creation Perspective to Service Business Models. In Enterprise Modelling and Information Systems Architectures (EMISA), page 243, 2011.
  8. Thomas Erl. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice HallPTR, Upper Saddle River, NJ, USA, 2005.
  9. Carlos Pedrinaci, John Domingue, and Amit Sheth. Handbook on Semantic Web Technologies,volume Semantic Web Applications, chapter Semantic Web Services. Springer, 2010.
  10. Service oriented architecture Modeling Language (SoaML) Specification, 2012.
  11. Matthew MacKenzie, Ken Laskey, Francis McCabe, Peter Brown, and Rebekah Metz. Reference Model for Service Oriented Architecture 1.0.
  12. The Open Group. Service-Oriented Architecture Ontology, 2010.
  13. John Domingue, Michal Zaremba, Barry Norton, Mick Kerrigan, Adrian Mocan, AlessioCarenini,EmiliaCimpian,MarcHaines,andJamesScicluna.ReferenceOntologyforSemantic Service Oriented Architectures Version 1.0, 2008.
  14. Mike Papazoglou. Web Services: Principles and Technology. Prentice Hall, 2012.
  15. Hans Akkermans, Ziv Baida, Jaap Gordijn, Nieves Pena, Ander Altuna, and Inaki Laresgoiti. Value webs: Using ontologies to bundle real-world services. IEEE Intelligent Systems, 19(4):57–66, July 2004.
  16. Martin Hepp. GoodRelations Language Reference, 2011.
  17. Carlos Pedrinaci, Jorge Cardoso, and Torsten Leidig. Linked USDL: A Vocabulary for Webscale Service Trading. In 11th Extended Semantic Web Conference, Crete, Greece, May 2014.
  18. Jorge Cardoso, Alistair Barros, Norman May, and Uwe Kylau. Towards a unified servicedescription language for the internet of services: Requirements and first developments. In Services Computing (SCC), 2010 IEEE International Conference on, pages 602–609. IEEE, 2010.
  19. Jorge Cardoso, Konrad Voigt, and Matthias Winkler. Service Engineering for The Internet ofServices. In Enterprise Information Systems X, volume 19, pages 17–25. Springer, 2008.
  20. ChristianBizer,TomHeath,andTimBerners-Lee.LinkedData-TheStorySoFar.InternationalJournal on Semantic Web and Information Systems, 5(3):1–22, 2009.
  21. Henry Chesbrough. Open innovation: The new imperative for creating and profiting fromtechnology. Harvard Business Press, 2003.
  22. Wil van der Aalst. Process Mining: Discovery, Conformance and Enhancement of BusinessProcesses. Springer Publishing Company, Incorporated, 1st edition, 2011.
  23. Roberta Ferrario, Nicola Guarino, Christian Janiesch, Tom Kiemes, Daniel Oberle, and FlorianProbst. Towards an ontological foundation of services science: The general service model. Wirtschaftsinformatik, Switzerland, pages 16–18, 2011.
  24. The Official Introduction to the ITIL Service Lifecycle. ITIL Series. Stationery Office,2007.
  25. Web services glossary, 2004.
  26. Peter Hill. On Goods and Services. Review of Income and Wealth, 23(4):315–38, 1977.
  27. Steven Alter. Service system fundamentals: Work system, value chain, and life cycle. IBMSystems Journal, 47(1):71–85, 2008.
  28. Roberta Ferrario and Nicola Guarino. Towards an ontological foundation for services science.Future Internet-FIS 2008, pages 152–169, 2009.
  29. Paul Maglio, Stephen Vargo, Nathan Caswell, and Jim Spohrer. The service system is the basicabstraction of service science. Information Systems and e-business Management, 7(4):395– 406, 2009.
  30. Manuel Mora, Rory O’Connor, Mahesh Raisinghani, Jorge Macías-Luévano, and Ovsei Gelman. An it service engineering and management framework (its-emf). International Journal of Service Science, Management, Engineering, and Technology (IJSSMET), 2(2):1–15, 2011.
  31. Ketki Dhanesha, Alan Hartman, and Anshu Jain. A model for designing generic services. InServices Computing, 2009. SCC’09. IEEE International Conference on, pages 435–442. IEEE, 2009.
  32. Manuel Mora, Mahesh Raisinghani, Ovsei Gelman, and Miguel-Angel Sicilia. Onto-servsys: A service system ontology. The Science of Service Systems, pages 151–173, 2011.
  33. Robert Glushko. Seven contexts for service system design. Handbook of service science, pages219–249, 2010.
  34. Introduction to OMG’s Unified Modeling Language (UML), 2012.
  35. Bran Selic. UML 2.0: Exploiting Abstration and Automation, 2004.
  36. Eva Söderström, Birger Andersson, Paul Johannesson, Erik Perjons, and Benkt Wangler.Towards a framework for comparing process modelling languages. In Advanced Information Systems Engineering, pages 600–611. Springer, 2006.
  37. Jang-Eui Hong and Doo-Hwan Bae. Software modeling and analysis using a hierarchicalobject-oriented Petri net. Information Sciences, 130(1):133–164, 2000.
  38. Jorge Cardoso, Carlos Pedrinaci, Torsten Leidig, Paulo Rupino, and Peter De Leenheer. Opensemantic service networks. In International Symposium on Services Science (ISSS), Leipzig, Germany, 2012.
  39. Paul Timmers. Business models for electronic markets. Electronic markets, 8(2):3–8, 1998.
  40. Alexander Osterwalder and Yves Pigneur. Business model generation: a handbook for visionaries, game changers, and challengers. Wiley, 2010.
  41. MutazAl-Debei.Thedesignandengineeringofinnovativemobiledataservices:AnontologicalFramework founded on business model thinking. School of Information Systems, Computing and Mathematics, 2010.
  42. Edward Faber, Pieter Ballon, Harry Bouwman, Timber Haaker, Oscar Rietkerk, and MarcSteen. Designing business models for mobile ict services. In Workshop on concepts, metrics & visualization, at the 16th Bled Electronic Commerce Conference eTransformation, Bled, Slovenia, 2003.
  43. Joan Magretta. Why business models matter. Harvard business review, 80(5):86–93, 2002.
  44. Alexander Osterwalder, Yves Pigneur, and Christopher Tucci. Clarifying business models: Origins, present, and future of the concept. Communications of the association for Information Systems, 16(1):1–25, 2005.
  45. Rainer Alt and Hans-Dieter Zimmermann. Preface: introduction to special section-businessmodels. Electronic Markets, 11(1):3–9, 2001.
  46. Erwin Fielt. An Extended Business Model Canvas for Co-Creation and Partnering. http:// blogspot.pt/2010/12/extended-business-model-canvas-for-co.html, 2010
  47. Jim Spohrer and Paul Maglio. Service science: Toward a smarter planet. Introduction to serviceengineering, pages 3–30, 2009.
  48. Reuven Karni and Maya Kaner. An engineering tool for the conceptual design of servicesystems. Advances in Services Innovations, pages 65–83, 2007.
  49. Reasoningaboutsubstitutechoicesandpreferenceorderingin e-services. In Advanced Information Systems Engineering, pages 390–404. Springer, 2008. 50. Tim Berners-Lee. Linked Data – Design Issues, 2006.
  50. Sebastian Speiser and Andreas Harth. Towards linked data services. In Proceedings of the 9th International Semantic Web Conference (ISWC), 2010.