This viewpoint includes terms specific to the concerns of Enterprise Information Technology Architecture or EITA (the technical subset of Enterprise Architecture). Many of the terms relevant to EITA are also shared with other viewpoints and can be found in the Shared Terms area of this ontology.
The Enterprise Information Technology Architecture (EITA) viewpoint specifically answers questions for stakeholders concerned about the appropriate, optimal, and most cost effective use of Information Technology in an enterprise.
Application
A business tool composed of one or more software components that, together, serve a business purpose. Applications are able to create or use the data objects that make up a business transaction. They may use one or more software platforms. To be used, they must be deployed on a host.
Business Information Model
A model illustrating the groupings and relationships between the data elements that make up business documents. Since a business document is a special case of a data object that represents a business transaction, the business information model is a proxy, at the information level, for modelling the relationships between the business transactions themselves.
Business or Information Tool
Any device, tool, system, machine, or other reusable asset that is needed by an actor in the performance of a business process. A computer application is one type of tool.
Business Requirement
A condition or capability that must be met or possessed by an application to satisfy the stated or implicit needs of a business process.
Host
A technical system where an application can be deployed. A Host may be a physical or virtual unit of hardware, or may be an instance of a virtual machine located in a “cloud” configuration (public or private).
Platform
A platform is a stable set of abstractions in technology on which a wide array of different types of software can be constructed. Normally composed of one or more commercial or open-source products, a platform may be expressed as a composition of both hardware and software, or may be software only (wherein it is often called a “stack”). Platforms may be built on other platforms (just as packaged ERP systems are able to run on multiple different operating systems).
Service Level Agreement
A service level agreement is a contract made between two business units, where one business unit provides a service to another. The contract describes specific measures by which the service provider’s performance will be measured, as well as acceptable ranges of those measures that the consumer would find acceptable.
Software Component
A discrete part of a software application. A component may be deployed one or more times, on one or more hosts, as part of a distributed system.
System Interaction Point
A system interaction point is a specific point in a business process where contact occurs between people and systems. In some methods, a survey of use cases would start with the list of system interaction points that apply to a particular system.
System Quality Requirement
A required measurable attribute of software that describes a desired level of quality for a system. These are requirements to meet performance levels of Availability, Efficiency, Flexibility, Integrity, Interoperability, Maintainability, Portability, Reliability, Reusability, Robustness, Testability, and Usability. These attributes are known as System Quality Attributes by the SEI ATAM method.
Selecting the relative priority of measurable attributes for a single system often requires tradeoffs. These priorities are best set by the system’s customer.
Tool Feature
A tool feature is an abstract representation of the ability of a tool to meet the specific needs of a business process at a system interaction point. Features are describable, testable, and perceivable by the users of the tool. Application features tend to be information-oriented while physical tools (like machines, vehicles, or even furniture) tends to be oriented to the physical measurement, management, manipulation, or manufacturing of an item.
Use Case / User Story
A use case is an artifact of system analysis that defines a sequence of actions and events that a solution is expected to perform, yielding an observable result of value to a particular actor.
The use case contains main, alternative, and exception flows of events. The functionality of a system is defined by different use cases, each of which represents a specific flow of events. The description of a use case defines what happens in the system when the use case is performed.
A user story is a similar term but refers to a simpler flow. It is a single discrete set of actions and events produced during an agile software development process.