What is an enterprise system domain?

• A collection of current and future enterprise system (software) applications that share a set of common characteristics.
• A well-defined set of characteristics that accurately, narrowly, and completely describe a family of problems for which enterprise application system solutions are being, and will be sought.
• Example: open information sharing systems is a domain of enterprise systems
• Another example: open global file sharing systems is a domain of enterprise systems

• Identify opportunities for creating or recognizing reusable system requirements, specifications, designs, implementations, test plans, and user documentation.
• Characterize a family of related application systems that conform to a common solution framework for a well-defined problem domain.
• Example: Napster, Gnutella, FreeNet and Scour Exchange are each a global file sharing application system, where the application centers about Internet-based sharing of music or multi-media (e.g., music video) files.

Figure 1. (SADT^tm) Model of Domain Analysis (after Arango and Prieto-Diaz, 1989)

• Common and Variable properties (components, dependencies, error conditions, etc.) of an enterprise system in the domain
• Semantics of the system properties
• also known as a conceptual system model
• an configuration of system entities/objects, components, user roles, control schemes, etc. that constitute the system data model
• Dependencies (i.e., relations) or links between system properties that establish the conceptual model, workflow (data flow), and business process flow (control flow)
• A vocabulary or lexicon (i.e., a data dictionary) that identifies common objects, attributes, values, relations, constraints or computational processes that collectively constitute a language for the domain
• Also called a domain-specific language
• Examples and counter-examples of application systems that are respectively in and not in the domain
• Napster, Gnutella, FreeNet, Scour Exchange and Free Haven are application systems in the domain of global file sharing systems
• The World Wide Web is not in the domain of global file sharing systems. However to many users, it is a global file system that provides access to files on (de)centrally managed Web servers.
• Reusable requirements: requirements that account for system features found in members of the system's product family
• Generic and taxonomic classification of the elements and dependencies that bound the scope of application systems within the domain.
• Sometimes called a system meta-model (a model of models, or a model of a family of interrelated models)

• This is a business decision, since a domain analysis is never exhaustively complete.
• Domains tend to evolve more slowly than the enterprise systems that support them.

Moving from System Requirements to System Specification

• Use Cases and Rich Pictures identify many system elements and dependencies
• Use Cases help identify user-system interactions, transactions or processes
• Rich Pictures help identify different roles people play, their concerns, overall process flow dependencies, and scope of overall problem domain.
• Specifications require identification of:
• enterprise system components,
• user-system interfaces,
• user processes for interacting with the system,
• information processes performed within the information system (technology),
• both user activities (e.g., storing, sharing and retrieving business model assets) and computational services (e.g., "file serving") may provide inter-firm service offerings, intra-firm capabilities, or core competencies
• user inputs and system outputs,
• outputs may be information resources or products for enterprise use
• internal system inputs and outputs between system components,
• process control guidance or decision-making constraints,
• human roles or automated mechanisms that enables processing steps,
• error conditions, error handling/signaling
• erroneous user input
• erroneous system output
• erroneous internal system inputs/outputs
• boundary values or anomalous values in inputs or outputs that require special handling
• patterns that configure and bundle inputs, actions/function steps, outputs into workflows (flow of data objects) and processes (flow of control according to business rules).
• Specified elements and dependencies need to be organized as abstractions:
• Hierarchical abstraction:
• Top-level: the Big picture of the system
• Middle-levels: sub-systems (a configured collection of components or internal sub-systems), sub-sub-systems, etc.
• Lowest-level: where system/software mechanisms operate
• Two kinds of hierarchical system abstractions of interest:
• Generic: from most general (domain-independent) to most specific (domain-specific)
• Taxonomic: from whole to part
• Each is orthogonal to the other
• Generic and domain-specific component abstraction:
• Components are to be parts of the implemented information system
• Components have interfaces through which inputs and outputs pass
• User-system interface
• Sub-system to sub-system interface
• Component to component
• Taxonomic classification:
• System to sub-system, sub-system to sub-sub-system, etc. to component.
• How the parts compose the whole; how the whole is decomposed into parts

• Enterprise system meta-model for the focal problem domain
• System components (coarse-grain): e.g., a database management system; a Web server; a Web browser; an electronic billing and payment system; a corporate accounting system.
• Inputs
• Objects (entities) or data containers (e.g., text files; mp3 files; video stream; database; directory)
• Objects have attributes (e.g., length; format; data encoding)
• Attributes have values (e.g., length is 64Kbytes; format is ASCII; data encoding follows MPEG3 standard)
• Values have ranges (good data values vs. erroneous data values)
• Boundary and anomalous values
• Information artifacts (e.g., enterprise data model; bar chart; UML design diagram; data entry record)
• May be contained within a single object (data type)
• May incorporate and compose multiple objects (complex data type)
• Other object types
• Documents (formatted in HTML, PDF or .DOC)
• MIME objects ("registered" objects types that are associated with specific application programs -- .mp3 objects require an "mp3" player application)
• Temporal and Spatial identifiers (e.g., timestamps; GPS coordinates; URL addresses)
• Namespaces and Universal (Unique) Resource Identifiers
• Etc.
• Outputs
• Includes same types as Inputs
• Reports (for printing), Displays (for browsing or reading), and Forms (for subsequent data entry).
• Objects or artifacts that include data specifying how to layout and present according to an implicit/explicit style guide or data exchange standard
• User Roles
• Control, guidance or decision-making constraints
• Business or application data exchange protocols
• Business processes
• Business rules

• Entity-Relation (ER) Data Modeling
• Object-Oriented (OO) Modeling
• Component-Based Modeling