The crumbling of traditional fences between enterprises and their environment as well as between actual and digital realms brings up the need of models encompassing the whole of business flows, whatever scope and nature. Given the open-ended diversity of semantics domains potentially involved, a conceptual thesaurus is arguably the order of the day.
But thesaurus are just tools and will be of little use without a modeling paradigm. As already noted, the core issue is to find some common concepts to be shared across business entities without curbing their specificity and their ability to innovate. That objective is to govern a thesaurus’ user interface and typical use cases.
Typically, the UI of a conceptual thesaurus should distinguish between textual requirements (bottom left), concepts (bottom center), and the system capabilities meant to support concepts actualization (bottom right and top).
With regard to concepts, a distinction should be made between domain-specific concepts and the ones open to shared semantics and realization.
With regard to capabilities, a thesaurus should prevent any confusion between actual (top left) and symbolic ones (top right).
For instance Patient inherits from Person and appears as a physical object (e.g for geo-localization purposes), role (actor in UML parlance) and business entity.
Concepts and capabilities can then be combined in models (middle) describing enterprise, systems (functional architecture), and platforms (technical architecture). Structures are defined uniformly using Boolean operators (middle right)
Typical Use Cases
A conceptual thesaurus is meant to support declarative and iterative as well as procedural and phased development models. That can only be achieved if use cases are defined with regard to artifacts’ status and users needs:
- New concept (business requirements): identification, classification, and description of business entities and activities.
- Conceptual analysis: validation of business requirements and consolidation across domains.
- New capability (functional requirements): specification of supporting system.
- Functional analysis: consolidation of supporting system functionalities.
It must be noted again that use cases are not to be confused with tasks, even if they sometimes coincides: the former are defined with regard to the status of artifacts, the latter are defined as steps within procedures.
UC: Business Requirement Capture
Whatever the domain or methodology, requirements are to be captured through language, formal, specific, or natural. A preliminary objective is therefore to eliminate linguistic ambiguities and list the options without preempting analysis decisions. To mention a frequent issue, nouns in requirements may denote agents, their roles (aka actors), or the records, possibly distinct for the persons and their roles. Similarly, verbs may refer to activities (business logic), states (execution), or events (accomplishment).
Actor: business analyst
Input: requirement item.
Outcome: nouns and verbs are accounted for as concepts and mapped to corresponding capabilities depending on semantics. Capabilities can be defined manually or based on blueprints.
Example: the term “mechanics” is registered as a domain specific concept Mechanic, and its features are documented (screenshot below).
Depending on methodology the corresponding UC can be performed iteratively (e.g users’ stories) or independently (e.g use cases & activities).
UC: Business Requirement Conceptual Analysis
Since it’s safe to assume that new business processes doesn’t necessarily come with self-contained domains, new identified objects and activities have to be compared to existing ones. When shared features are observed, decisions have to be made with regard to specialization and generalization.
Actor: business analyst
Input: requirement item, from requirements capture or directly.
Outcome: concepts are checked against existing open concepts and possibly consolidated together with associated capabilities. Capabilities can be defined manually or based on blueprints.
Example: domain-specific concept Patient inherits its structure and identification mechanism from the Person open concept, and functional aspects from Customer. Capabilities include authentication of physical agent (from Person), actor, and Nurse entity. Links are suggested to symbolic containers (HMO, Hospital, etc).
Assuming that the primary intent of conceptual analysis is to factor out the footprint of concepts defined externally (e.g Person), the responsibility of these concepts (aka open concepts) should be given to thesaurus administrators.
UC: Domain Conceptual Validation
Before considering the part played by supporting systems, business analysts must check for the continuity and consistency of overlapping business domains (aka bounded contexts).
Actor: business analyst or thesaurus administrator
Input: domain, from requirements capture or directly.
Outcome: structural and functional inheritance by the targeted domain (or context) have been checked for consistency.
Example: Nurse can directly inherits identification from one and only one source: either it comes directly from Person, or indirectly through Staff.
It must be noted that the formal constraints set for open concepts open the door to a wide range of rigorous tests for models.
UC: Functional Requirement Capture
Compared to business requirements, which are meant to focus on business objects and logic independently of the role played by supporting systems, the purpose of functional requirements is to specify what happens between business processes and systems. Depending on projects and methodologies, business and functional requirements may be carried out separately (phased project management) or jointly (agile project management); both approaches can be supported by the same use case.
Actor: functional or business analyst.
Input: requirements item, possibly checked for conceptual analysis.
Outcome: concepts and associated features are consistently mapped to capabilities.
Example: the relevant features of the Patient concept are to be mapped to system capabilities according to their functional justification, e.g: bio-metric (physical boundary capability) or logical (recorded features) authentication, staff authorizations and confidentiality (actors), and management (business entity).
UC: Functional Requirement Analysis
As for business processes with regard to domains, new functional requirements often rely on existing systems functionalities. When potential overlapping is observed, decisions have to be made with regard to specialization and generalization.
Actor: functional analyst and architect.
Input: functional requirements item, checked for conceptual analysis.
Outcome: new capabilities are fully documented, checked against current functional architecture, and possibly consolidated. That can be done manually or in line with functional patterns.
Example: bio-metric authentication requires specific capabilities for system boundaries that may or may not be already supported, and when they are some extensions may be necessary.
Set within a phased project the use case will typically produce a functional specifications document. When applied iteratively by agile teams it will help to mark out functional features from backlog items.
UC: Functional Validation
Just like business domains, systems capabilities cannot be assessed independently as cross dependencies may cripple capabilities of a system as a whole despite attested local feasibility.
Actor: functional analyst, system architect, and quality manager.
Input: functional requirements and architecture capabilities.
Outcome: expected individual capabilities are checked as a whole, both for functional and non functional requirements.
Example: apart from specific capabilities of a number of system boundaries, bio-metric authentication may also requires encryption and real-time capabilities at system level.
Set within a phased project the use case will typically finalize a detailed feasibility study. When applied iteratively by agile teams it will help to prioritize backlog items with regard to system features. In the broader perspective of a scaled approach, the use case will further incremental development of system features.
ANNEXE: Ontological blueprints
Basic templates for identification (#), updates (+) and references (:) can be introduced to support thesaurus editors:
- New concept represented by a new entity with possible updates to domains and partitions.
- Business domains, with possible updates to events, activities (business functions), and partitions.
- Application domains, with possible updates to roles, events, activities, entities, and functional partitions.
- Business processes, with possible updates to domains, entities, roles, events, activities (business functions), and partitions.
- User stories, identified as activities, with possible updates to roles (as defined by organization), events, entities, and partitions (branches).
- Use cases, identified as activities, with possible updates to locations, domains, entities, roles (as UML actors), events, activities (business functions), and partitions (extension points).
- Business (external) events, as represented by entities, with possible updates to roles (as UML actors), processes, and partitions.
- Business roles, as represented by entities, with possible updates to agents, events, activities, processes, and partitions.
- Real time applications, as processes with possible updates to active objects and agents.
Basic thesaurus blueprints
A workbench built with OWL 2 is available for comments on the Stanford/Protégé portal using the link: Caminao Ontological Kernel (CaKe_WIP).