Preamble
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.
User Interface
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 for EA THESAURUSES
To be of any use at the enterprise level, conceptual thesauruses have to support iterative as well as phased transformations combining conceptual, organizational, and technical changes. That implies use cases aligned with :
- Business environment and objectives: identification, classification, and description of business entities and activities at the enterprise level.
- Business processes and organization: how business units collaborate.
- Systems capabilities: functional architecture of supporting system.
- Systems implementation: technical architecture of supporting system.
EA employ of conceptual thesauruses can thus be typified through six basic use cases: one at the business level, one at the application level, and four at the architecture level.
New Application Requirement
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 engineering options. To mention a frequent issue, nouns in requirements may be associated with agents (environments), their roles (enterprise), actors (processes), or the records (systems), possibly distinct for the persons and their roles. Similarly, verbs may refer to activities (business logic), states (execution), or events (accomplishment). These distinctions may be superfluous for applications set at the system level, not so at the enterprise level.
Actor: business analyst.
Input: requirement items.
Outcome: nouns and verbs are accounted for as concepts and mapped to corresponding entries depending on semantics, some of them already represented in models, and/or identified in blueprints, other only consolidated in thesauruses.
Example: the term “mechanics” is registered as a domain specific concept Mechanic, and its features are documented.
New Business
In contrast to applications, defined concretely from users’ perspective, new business objectives are introduced from a broader business perspective. Assuming a clean slate approach, introducing new business objectives should begin with the comparison of the new concepts with the existing ones. When overlaps are identified, decisions have to be made regarding their realization in descriptive models.
Actor: business stakeholder, product owner, business analyst.
Input: concepts, business models, requirement items.
Outcome: concepts are checked against existing business entities and activities and possibly consolidated together with associated capabilities.
Example: customer vs client, stakeholder vs shareholder.
New Business Object
Assuming that new business objects don’t necessarily come with self-contained domains, they have to be compared to existing ones. When overlaps are observed, decisions have to be made regarding the specialization or generalization of business entities already identified in descriptive models.
Actor: product owner, business analyst.
Input: concepts, business and descriptive models, requirement item.
Outcome: new business objects with structural and functional aspects, or extension of existing ones.
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).
New Business activity
While the definition of business objects is governed by architecture sustainability, business processes are driven by business value; hence the benefits of managing them separately.
To that effect new business activities are initially defined in relation with business objects already identified in descriptive models. The mapping of new activities is then carried out for structural and functional aspects.
Structural aspects are features (properties or operations) whose semantics is tied to business objects; functional ones are features with semantics set by activities. As for objects, when activities or facets overlap, decisions have to be made regarding the specialization or generalization.
Actor: business analyst.
Input: descriptive models, requirement item, from requirements capture or directly.
Outcome: new activities, with functional aspects set anew or as extensions of existing ones.
Example: Nurse can inherits identification from Person (structural), or through Staff (functional).
New Business Function
Compared to business requirements, which are meant to focus on business objects and logic independently of the role played by supporting systems, the specification of business of business functions is to define 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); as far as thesauruses are concerned, both approaches can be supported by the same use case.
Actor: business analysts and system architects.
Input: prescriptive models.
Outcome: services.
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).
New Platform
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: enterprise and system architects.
Input: prescriptive models and quality of service requirements.
Outcome: technical and operational models.
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.
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).
