In our Learning pages we provide the knowledge that is needed to understand our core research. The goal of this material is not be exhaustive in that area but to provide more information and knowledge than would be provided by a glossary. It will also provide the view of the subject that we use and therefore provide more guidance and clarity than may be gained by simply searching on that term.
In some of the advanced areas we will utilize the case-study approach because research has shown it to be more effective for long term understanding and retention.
Gartner defines customer experience management (CEM) as "the practice of designing and reacting to customer interactions to meet or exceed customer expectations and, thus, increase customer satisfaction, loyalty, and advocacy." Customer experience management is sometimes also known as CxM.
Customer service is "the assistance and advice provided by a company to those people who buy or use its products or services" (Oxford Dictionaries). Customer service is one part customer experience management.
Information security and cybersecurity are becoming both increasing important and increasingly difficult. While information security is concerned with the integrity, confidentiality, and availability of the information cybersecurity extends these concerns to connected computing devices, personnel, infrastructure, applications, services, and telecommunications systems.
The Open Group defines an individual microservice as “a service that is implemented with a single purpose, that is self-contained, and that is independent of other instances and services.” Adrian Cockcroft defines a microservices architecture as a service-oriented architecture composed of loosely coupled elements that have bounded contexts. Domain driven design deals with large models by dividing them into different bounded contexts and being explicit about their interrelationships.
Microservices are used to decompose monolithic applications into independent functional components. These components can then be used to assemble applications in an agile and flexible manner. Microservices are more of an aggregation of several contemporary practices and patterns than a technology or a standard. Martin Fowler identified the following key characteristics of microservices:
- Componentization via services
- Organized around business capabilities
- Products not Projects
- Smart endpoints and dumb pipes
- Decentralized Governance
- Decentralized Data Management
- Infrastructure Automation
- Design for failure
- Evolutionary Design
Once applications are decomposed into microservices integration between them is simply a matter of one application calling a microservice exposed by the other application.
A common theme in “Domain-driven Design: Tackling Complexity in the Heart of Software” by Eric Evans (2004), “Software Fortresses: Modeling Enterprise Architectures” by Roger Sessions (2003), and “Designing IT for business” by Jurgen Laartz, et.al. (2003) is the decomposition of large IT systems, applications, teams, and models into domains to reduce complexity and gain business capability alignment. In microservices “2) organized around business capabilities” also strongly promotes the grouping of microservices into business capability based domains. Logically, a business capability based domain approximates a single product. Examples of business capability based domains are member, provider, payer, utilization management, etc.
Applications within a domain are business capability product based. They are managed and governed by a single DevOps team. The microservices within the domain are decomposed and structured to best serve the needs of that domain. Although microservices are “independent of other instances and services” they are coupled within a domain because they are part of the same product. You can see this example in the hexagons within the Member domain in the diagram below.
However, applications and microservices must remain loosely coupled across domains. An application or microservice in one domain should never directly call a microservice in another domain. Each domain has its own operations and governance, and because of this, disrupting changes may occur to services in one domain without prior notification to consumers in another domain if the services are directly linked.
In the modern digital economy APIs expose internal data and business logic over a Web oriented architecture to API consumers.
Kristin R. Moyer, vice president and distinguished analyst at Gartner, says that “the API economy is an enabler for turning a business or organization into a platform.” Christy Pettey, also from Gartner, further explains the API economy as “a set of business models and channels based on secure access of functionality and exchange of data. APIs make it easier to integrate and connect people, places, systems, data, things and algorithms, create new user experiences, share data and information, authenticate people and things, enable transactions and algorithms, leverage third-party algorithms, and create new product/services and business models.”
Analyst Craig Burton postulated the following “Five Axioms of the API Economy”:
- Everything and everyone will be API enabled.
- APIs are core to every cloud, social and mobile computing strategy.
- APIs are an economic imperative.
- Organizations must provide their core competence through APIs.
- Organizations must consume core competences of others through APIs.
The Fast Healthcare Interoperability Resources (FHIR) specification, from HL7 International, is a standard for exchanging healthcare information electronically.