A management information system (MIS) is a system or process that provides
information needed to manage organizations effectively . Management
information systems are regarded to be a subset of the overall internal controls
procedures in a business, which cover the application of people, documents,
technologies, and procedures used by management accountants to solve
business problems such as costing a product,service or a business-wide
strategy. Management information systems are distinct from regular information
systems in that they are used to analyze other information systems applied in
operational activities in the organization. Academically, the term is commonly
used to refer to the group of information management methods tied to the
automation or support of human decision making, e.g. Decision Support
Systems/ CBIS , Expert systems, and Executive information systems.
At the start, works in businesses and other organizations, internal reporting was
made manually and only periodically, as a by-product of the accounting system
and with some additional statistic(s), and gave limited and delayed information
on management performance. Previously, data had to be separated individually
by the people as per the requirement and necessity of the organization. Later,
data was distinguished from information, and so instead of the collection of
mass of data, important and to the point data that is needed by the organization
Early on, business computers were mostly used for relatively simple operations
such as tracking sales or payroll data, often without much detail. Over time
these applications became more complex and began to store increasing
amounts of information while also interlinking with previously separate
information systems. As more and more data was stored and linked man began
to analyze this information into further detail, creating entire management
reports from the raw, stored data. The term "MIS" arose to describe these kinds
of applications, which were developed to provide managers with information
about sales, inventories, and other data that would help in managing the
enterprise. Today, the term is used broadly in a number of contexts and
includes (but is not limited to): decision support systems, resource and people
management applications, Enterprise Resource Planning (ERP), Supply Chain
Management (SCM), Customer Relationship Management (CRM), project
management and database retrieval applications.
An 'MIS' is a planned system of the collecting, processing, storing and
disseminating data in the form of information needed to carry out the functions
of management. In a way it is a documented report of the activities that were
planned and executed. According to Philip Kotler "A marketing information
system consists of people, equipment, and procedures to gather, sort, analyze,
evaluate, and distribute needed, timely, and accurate information to marketing
decision makers." 
The terms MIS and information system are often confused. Information systems
include systems that are not intended for decision making. The area of study
called MIS is sometimes referred to, in a restrictive sense, as information
technology management. That area of study should not be confused with
computer science. IT service management is a practitioner-focused discipline.
MIS has also some differences with ERP which incorporates elements that are
not necessarily focused on decision support.
Any successful MIS must support a businesses Five Year Plan or its equivalent.
It must provide for reports based upon performance analysis in areas critical to
that plan, with feedback loops that allow for titivation of every aspect of the
business, including recruitment and training regimens. In effect, MIS must not
only indicate how things are going, but why they are not going as well as
planned where that is the case. These reports would include performance
relative to cost centers and projects that drive profit or loss, and do so in such a
way that identifies individual accountability, and in virtual real-time.
Anytime a business is looking at implementing a new business system it is very
important to use a system devlopment method such as System Development
Life Cycle. The life cycle includes Analysis, Requirements, Design,
Development and Implementation.
Professor Allen S. Lee states that "...research in the information systems field
examines more than the technological system, or just the social system, or
even the two side by side; in addition, it investigates the phenomena that
emerge when the two interact." .
An Enterprise Information System is generally any kind of computing system
that is of "enterprise class". This means typically offering high quality of service,
dealing with large volumes of data and capable of supporting some large
organization ("an enterprise").
Enterprise Information Systems provide a technology platform that enables
organizations to integrate and coordinate their business processes. They
provide a single system that is central to the organization and ensure that
information can be shared across all functional levels and management
hierarchies. Enterprise systems are invaluable in eliminating the problem of
information fragmentation caused by multiple information systems in an
organization, by creating a standard data structure.
A typical Enterprise Information System would be housed in one or more Data
centers , run Enterprise software, and could include applications that typically
cross organizational borders such as Content management systems.
The word enterprise can have various connotations. Frequently the term is used
only to refer to very large organizations. However, the term may be used to
mean virtually anything, by virtue of it having become the latest corporate-
speak buzzword. (See Criticisms of Enterprise software)
Enterprise software, also known as enterprise application software (EAS), is
software used in organizations, such as in a business or government, as
opposed to software chosen by individuals (for example, retail software).
Services provided by enterprise software are typically business-oriented tools
such as online shopping and online payment processing, interactive product
catalogue, automated billing systems, security, content management, IT
service management, customer relationship management, resource planning,
business intelligence, HR management, manufacturing, application integration,
and forms automation.
While there is no single, widely accepted list of enterprise software
characteristics, this section is intended to summarize definitions from multiple
Enterprise software describes a collection of computer programs with common
business applications, tools for modeling how the entire organization works,
and development tools for building applications unique to the organization.
The software is intended to solve an enterprise-wide problem (rather than a
departmental problem) and often written using an Enterprise Software
Architecture. Enterprise level software aims to improve the enterprise's
productivity and efficiency by providing business logic support functionality.
Capterra broadly defines enterprise software in the following manner:
Targets any type of organization — corporations, partnerships, sole
proprietorships, nonprofits, government agencies — but does not
directly target consumers.
Targets any industry.
Targets both large and small organizations — from Fortune 500 to "mom
and pop" businesses.
Includes function-specific (Accounting, HR, Supply Chain, etc.) and
industry-specific (Manufacturing, Retail, Healthcare, etc.) solutions.
Due to the cost of building or buying what is often non-free proprietary software,
only large enterprises attempt to implement such enterprise software that
models the entire business enterprise and is the core IT system of governing
the enterprise and the core of communication within the enterprise.
As business enterprises have similar departments and systems in common,
enterprise software is often available as a suite of programs that have attached
enterprise development tools to customize the programs to the specific
enterprise. Generally, these tools are complex enterprise programming tools
that require specialist capabilities. Thus, one often sees job listings for a
programmer who is required to have specific knowledge of a particular set of
enterprise tools, such as "must be an SAP developer".
Characteristics of enterprise software are performance, scalability, and
robustness. Enterprise software typically has interfaces to other enterprise
software (for example LDAP to directory services) and is centrally managed (a
single admin page for example).
 Enterprise application software
Enterprise application software is application software that performs business
functions such as order processing, procurement, production scheduling,
customer information management, and accounting. It is typically hosted on
servers and provides simultaneous services to a large number of users,
typically over a computer network. This is in contrast to a single-user
application that executes on a user's personal computer and serves only one
user at a time.
Enterprise software can be designed and implemented by an
information technology (IT) group within a company.
It may also be purchased from an independent enterprise software
developer, that often installs and maintains the software for their
customers. Installation, customization, and maintenance can also be
outsourced to an IT consulting company.
Another model is based on a concept called on-demand software, or
Software as a Service (SaaS). The on-demand model of enterprise
software is made possible through the widespread distribution of
broadband access to the Internet. Software as a Service vendors
maintain enterprise software on servers within their own company data
center and then provide access to the software to their enterprise
customers via the Internet.
Enterprise software is often categorized by the business function that it
automates - such as accounting software or sales force automation software.
Similarly for industries - for example, there are enterprise systems devised for
the health care industry, or for manufacturing enterprises.
Major organizations in the enterprise software field include IBM, BMC Software,
HP, UC4 Software, JBoss (Red Hat), SAP, Microsoft, Adobe Systems, Oracle
Corporation, and Computer Associates but there are thousands of competing
The word enterprise can have various connotations. Sometimes the term is
used merely as a synonym for organization, whether it be very large (e.g., a
corporation with thousands of employees), very small (a sole proprietorship), or
an intermediate size. Often the term is used only to refer to very large
organizations, although it has become a corporate-speak buzzword and may
be heard in other uses.
Some enterprise software vendors using the latter definition develop highly
complex products that are often overkill for smaller organizations, and the
application of these can be a very frustrating task. Thus, sometimes "enterprise"
might be used sarcastically to mean overly complex software.
The adjective "enterprisey" is sometimes used to make this sarcasm explicit. In
this usage, the term "enterprisey" is intended to go beyond the concern of
"overkill for smaller organizations" to imply the software is overly complex even
for large organizations and simpler solutions are available.
 See also
Integrated business planning
Operational risk management
Management information system
Strategic information system
Information technology management
ERP System Selection Methodology
Commercial operations management
Enterprise forms automation
An enterprise architecture (EA) is a rigorous description of the structure of an
enterprise, which comprise enterprise components (business entities), the
externally visible properties of those components, and the relationships (e.g.
the behavior) between them. EA describes the terminology, the composition of
enterprise components, and their relationships with the external environment,
and the guiding principles for the requirement, design, and evolution of an
enterprise. This description is comprehensive, including enterprise goals,
business process, roles, organizational structures, organizational behaviors,
business information, software applications and computer systems.
Practitioners of EA call themselves "enterprise architects." An enterprise
architect is a person responsible for developing the enterprise architecture and
is often called upon to draw conclusions from it. By producing an enterprise
architecture, architects are providing a tool for identifying opportunities to
improve the enterprise, in a manner that more effectively and efficiently pursues
The scope of an enterprise architecture
The term enterprise refers to a complex, socio-technical system that comprises
interdependent resources of people, information, and technology that must
interact with each other and their environment in support of a common
The term "enterprise" is used because it is generally applicable in many
Public or Private Sector organizations
An entire business or corporation
A part of a larger enterprise (such as a business unit)
A conglomerate of several organizations, such as a joint venture or
A multiply-outsourced business operation
Defining the boundary or scope of the enterprise to be described is an
important first step in creating the enterprise architecture. It should also be
noted that the term "enterprise" as used in enterprise architecture generally
means more than the information systems employed by an organization.
 Methods and frameworks
Enterprise architects use various business methods, analytical techniques and
conceptual tools to understand and document the structure and dynamics of
an enterprise. In doing so, they produce lists, drawings, documents and
models, together called "artifacts". These artifacts describe the logical
organization of business functions, business capabilities, business processes,
people organization, information resources, business systems, software
applications, computing capabilities, information exchange and
communications infrastructure within the enterprise.
A collection of these artifacts, sufficiently complete to describe the enterprise in
useful ways, is considered by EA practitioners an 'enterprise' level architectural
description, or enterprise architecture, for short. The UK National Computing
Centre EA best practice guidance states
Normally an EA takes the form of a comprehensive set of cohesive models that
describe the structure and functions of an enterprise.
The individual models in an EA are arranged in a logical manner that provides
an ever-increasing level of detail about the enterprise: its objectives and goals;
its processes and organisation; its systems and data; the technology used and
any other relevant spheres of interest.
This is the definition of enterprise architecture implicit in several EA frameworks
including the popular TOGAF architectural framework.
An enterprise architecture framework collects together tools, techniques,
artifact descriptions, process models, reference models and guidance used by
architects in the production of enterprise-specific architectural description.
See the related article on enterprise architecture frameworks for further
In 1992, Steven Spewak described a process for creating an enterprise
architecture that is widely used in educational courses.
 Areas of practice
Several enterprise architecture frameworks break down the practice of
enterprise architecture into a number of practice areas or "domains". In his
book on Enterprise Architecture, Spewak divides the practice into two domains
at 'level 2': "Business Modelling" and "Current Systems and Technology" and
three subordinate domains at 'level 3': "Data Architecture", "Applications
Architecture" and "Technology Architecture". The final level of Spewak's EAP is
the "Implementation" or "Methods" level, which deals with "how" to migrate the
Enterprise to match the new model.
The popular TOGAF framework divides the practice into three domains:
"Business Architecture", "Information Systems Architecture" and "Technology
Architecture" and then subdivides the information systems architecture into
"Information Architecture and "Applications Architecture".
The Strategic Architecture Model allows for a flexible division into up to ten
domains covering many aspects of an enterprise from its objectives and goals
through its projects and programmes to its software applications and
The dividing of the practice into a number of domains allows enterprise
architects to describe an enterprise from a number of important perspectives.
This practice also encourages the contributions of many individuals and allows
the practice as a whole to make good use of individual domain-specific
expertise and knowledge. By taking this approach, enterprise architects can
ensure a holistic description is produced.
The popular and most common four domains and their component parts look
1. Strategy maps, goals, corporate policies, Operating Model
2. Functional decompositions (e.g. IDEF0, SADT), business
capabilities and organizational models expressed as enterprise /
line of business architecture
3. Business processes, Workflow and Rules that articulate the
assigned authorities, responsibilities and policies
4. Organization cycles, periods and timing
5. Suppliers of hardware, software, and services
1. Information architecture - a holistic view on the flow of information
in an enterprise
2. Metadata - data that describes your enterprise data elements
3. Data models: conceptual expressed as enterprise information
architectures, logical, and physical
1. Application software inventories and diagrams, expressed as
conceptual / functional or system enterprise / line of business
2. Interfaces between applications - that is: events, messages and
1. Inter-application mediating software or 'middleware'.
2. Application execution environments and operating frameworks
including applications server environments and operating
systems, authentication and authorisation environments, security
systems and operating and monitoring systems.
3. Hardware, platforms, and hosting: servers, datacentres and
4. Local and wide area networks, Internet connectivity diagrams
5. Intranet, Extranet, Internet, eCommerce, EDI links with parties
within and outside of the organization
6. Operating System
7. Infrastructure software: Application servers, DBMS
8. Programming Languages, etc. expressed as enterprise / line of
business technology architecture.
 Using an enterprise architecture
Describing the architecture of an enterprise aims primarily to improve the
effectiveness or efficiency of the business itself. This includes innovations in the
structure of an organization, the centralization or federation of business
processes, the quality and timeliness of business information, or ensuring that
money spent on information technology (IT) can be justified.
One method of using this information to improve the functioning of a business,
as described in the TOGAF architectural framework, involves developing an
"architectural vision": a description of the business that represents a "target" or
"future state" goal. Once this vision is well understood, a set of intermediate
steps are created that illustrate the process of changing from the present
situation to the target. These intermediate steps are called "transitional
architectures" by TOGAF. Similar methods have been described in other
enterprise architecture frameworks.
 The growing use of enterprise architecture
Documenting the architecture of enterprises is done within the U.S. Federal
Government in the context of the Capital Planning and Investment Control
(CPIC) process. The Federal Enterprise Architecture (FEA) reference models
serve as a framework to guide Federal agencies in the development of their
architectures. Companies such as Independence Blue Cross, Intel,
Volkswagen AG and InterContinental Hotels Group have also applied
enterprise architecture to improve their business architectures as
well as to improve business performance and productivity.
 Relationship to other disciplines
Enterprise architecture is a key component of the information technology
governance process in organizations such Dubai Customs and AGL
Energy. Organizations like Dubai Customs and AGL Energy have
implemented a formal enterprise architecture process as part of their IT
management strategy. While this may imply that enterprise architecture is
closely tied to IT, this should be viewed in the broader context of business
optimization in that it addresses business architecture, performance
management and process architecture as well as more technical subjects.
Depending on the organization, enterprise architecture teams may also be
responsible for some aspects of performance engineering, IT portfolio
management and metadata management. Recently, protagonists like Gartner
and Forrester have stressed the important relationship of Enterprise
Architecture with emerging holistic design practices such as Design Thinking
and User Experience Design.
The following image from the 2006 FEA Practice Guidance of US OMB sheds
light on the relationship between enterprise architecture and segment(BPR) or
Solution architectures. (This figure demonstrates that software architecture is
truly a solution architecture discipline, for example.)
Activities such as software architecture, network architecture, database
architecture are partial contributions to a solution architecture.
 Published examples of enterprise architecture
It is uncommon for a commercial organization to publish rich detail from their
enterprise architecture descriptions. Doing so can provide competitors
information on weaknesses and organizational flaws that could hinder the
company's market position. However, many government agencies around the
world have begun to publish the architectural descriptions that they have
developed. Good examples include the US Department of the Interior, and
the US Department of Defense business transformation agency.
 See also
Books are collections of articles that can be downloaded or ordered in print.
Enterprise Architecture framework
Architecture Patterns ( EA Reference Architecture)
Business Technology Management
Enterprise Architecture Planning
Enterprise Life Cycle
Enterprise Unified Process
GINA : Global Information Network Architecture
IT Portfolio Management
IT Service Management
Enterprise Architecture Assessment Framework
Open Source Enterprise Architecture Tools
An Enterprise Architecture Framework (EA Framework) is a framework for an
Enterprise Architecture which defines how to organize the structure and views
associated with an Enterprise Architecture.
The three components of the enterprise architecture framework are:
Views : provide the mechanisms for communicating information about
the relationships that are important in the architecture
Methods : provide the discipline to gather and organize the data and
construct the views in a way that helps ensure integrity, accuracy and
Training/Experience : support the application of method and use of tools
Because the discipline of Enterprise engineering and Enterprise Architecture is
so broad, and because enterprises can be large and complex, the models
associated with the discipline also tend to be large and complex. To manage
this scale and complexity, an Architecture Framework provides tools and
methods that can bring the task into focus and allow valuable artifacts to be
produced when they are most needed.
Architecture Frameworks are commonly used in Information technology and
Information system governance. An organization may wish to mandate that
certain models be produced before a system design can be approved.
Similarly, they may wish to specify certain views be used in the documentation
of procured systems - the U.S. Department of Defense stipulates that specific
DoDAF views be provided by equipment suppliers for capital project above a
Impression of Enterprise Architecture Frameworks evolution (1987-2003). On
the left: The Zachman Framework 1987, NIST Enterprise Architecture 1989,
EAP 1992, TISAF 1997, FEAF 1999 and TEAF 2000. On the right: POSIX, TAFIM,
JTA, JTAA, TOGAF 1995, DoD TRM and C4ISR 1996, and DoDAF 2003.
Enterprise Architecture started with the Zachman Framework in 1987. Another
early implementation of an Enterprise Architecture framework was the
"Technical Architecture Framework for Information Management" (TAFIM). The
first draft of TAFIM was completed in 1991 with the TAFIM Technical Reference
Model (TAFIM TRM). This technical reference model wanted to use open
systems and new technologies available in the commercial market, to develop
a DoD-wide application. The TOGAF TRM was originally derived from the
Technical Architecture Framework for Information Management (TAFIM), which
in turn was derived from the IEEE model 1003.0 or POSIX Open System
Environment: a standard "to construct an information processing system,
including consumers, system integrators, application developers, system
providers, and procurement agencies".
In recent years, it has become apparent that a key benefit to be gained from
Enterprise architecture is the ability to support decision making in changing
businesses. Because Enterprise Architecture brings together business models
(e.g. process models, organizational charts, etc.) and technical models (e.g.
systems architectures, data models, state diagrams, etc.) it is possible to trace
the impact of organizational change on the systems, and also the business
impact of changes to the systems.
As this benefit has emerged, many frameworks such as DoDAF, MODAF, or
AGATE have adopted a standard meta model which defines the critical
architectural elements and the dependencies between them. Applications
based on these models can then query the underlying architectural information,
providing a simple and strong mechanism for tracing strategies to
organizational and technological impacts.
 EA Framework topics
 Framework of building codes
Persons who have ever remodeled their home, know how important building
codes, blueprints, and city or county inspections are to successfully complete
the project. The architect operates within a "framework" of building codes,
preparing blueprints for each phase of the project, from the structural changes
to the size and layout of the rooms. Detailed drawings specify plumbing,
electrical, and building construction information for the entire structure.
Enterprise Architecture works in a similar manner.
An architecture framework for Information Technology (IT) affects every aspect
of the enterprise. An Enterprise Architecture framework is similar to building
codes that ensure the building is soundly constructed. The IT governance
bodies and procedures serve as the city and county inspectors for building
improvement projects. Frameworks contain models and standards that will be
used to develop IT architecture descriptions. The architecture description is the
 Architecture domain
Example of the Federal Enterprise Architecture, which has defined five
In the context of the creation of enterprise architecture it is common, according
to Péter Bernus (2005), to recognise three or four types of architecture, each
corresponding to its particular architecture domain. Examples of such domains
Information systems architecture, often subdivided into
o Data architecture, and
o Application architecture,
and Technical architecture.
Architectural domains are a structuring criterion for a collection of architecture
products. They should not be confused with the application domain of the
framework as such.
 Layers of the Enterprise Architecture
Layers of the Enterprise Architecture.
Contemporary federal guidance suggests thinking about “layers” of the
Business processes and activities
Applications such as custom or off-the-shelf software tools
Data that must be collected, organized, safeguarded, and distributed
Technology such as computer systems and telephone networks
The Architecture Domains follow a pattern of decomposition as one goes from
top to the bottom of the framework. The ownership can be divided into 4 broad
categories: planner's view, owner's view, designer's view and developer's view
in this order. All the views are mostly hierarchical in nature. For business view
the planner and owner's level is typically called the value chains (which are
descriptive by nature). The designer's view of business is also known as the
analytical view and there are various standards for modeling this view. One
mostly commonly used modeling standard is the Business Process Modeling
Notation (BPMN). The designer's view typically represents the execution level
which uses standards like Business Process Execution Language (BPEL).
 Enterprise Architecture Domains and Subdomains
Enterprise Architecture Reference Architecture with Sub Domains
The Application and Technology Domains (which are not to be confused with
business domains) are characterized by domain capabilities and domain
services. The capabilities are supported by the services. The application
services are also referred in Service-oriented architecture (SOA). The technical
services are typically supported by software products.
The data view starts with the data classes which can be decomposed into data
subjects which can be further decomposed into data entities. The basic data
model type which is most commonly used is called ERD (Entity Relationship
Diagrams, see Entity-relationship model). The Class, subject and entity forms a
hierarchical view of data. Enterprises do have millions of instances of data
The Enterprise Architecture Reference Traditional Model offers clear distinction
between the Architecture Domains (Business, Information/Data,
Application/Integration and Technical/Infrastructure). These domains can be
further divided into Sub domain disciplines. An Example of the EA Domain and
Sub Domains is in the image on the right.
Many Enterprise Architecture Teams consist of Individuals with skills aligned
with the Enterprise Architecture Domains and Sub Domain Disciplines. For
Example : Enterprise Business Architect, Enterprise Information Architect,
Enterprise Application Architect, Enterprise Infrastructure Architect, etc.
An Example of the List of Reference Architecture Architecture Patterns in the
Application and Information Architecture Domains are available at Architectural
pattern (computer science)
 View model
A view model is a framework, which defines the set of views or approaches to
be used in systems analysis or the construction of an enterprise architecture.
Since the early 1990’s there have been a number of efforts to define standard
approaches for describing and analyzing system architectures. Many of the
recent Enterprise Architecture frameworks have some kind of set of views
defined, but these sets are not always called "view models".
 Types of Enterprise Architecture framework
 Consortia-developed frameworks
EABOK (The Guide to the Enterprise Architecture Body of Knowledge) -
a U.S. Federal-funded guide to EA in the context of legislative and
strategic business requirements.
Generalised Enterprise Reference Architecture and Methodology
IDEAS Group - a four-nation effort to develop a common ontology for
RM-ODP - the Reference Model of Open Distributed Processing (ITU-T
Rec. X.901-X.904 | ISO/IEC 10746) defines an enterprise architecture
framework for structuring the specifications of open distributed systems.
TOGAF - the Open Group Architecture Framework - a widely used
framework including an Architectural Development Method and
standards for describing various types of architecture.
Good enough architecture methodology - a methodology based on
experiences, results and best-practices gathered through real-life
implementations of various building blocks that altogether provide a
realizable architecture and working solutions.
ARCON - A Reference Architecture for Collaborative Networks - not
focused on a single enterprise but rather on networks of enterprises 
 Open Source Frameworks
TRAK - a general systems-oriented framework based on MODAF 1.2 and
released under GPL/GFDL.
MEGAF is an infrastructure for realizing architecture frameworks that
conform to the definition of architecture framework provided in the
ISO/IEC 42010 standard.
 Proprietary frameworks
Solution Architecting Mechanism (SAM) - A coherent architecture
framework consisting of a set of integral modules. 
Integrated Architecture Framework (IAF) - from Capgemini company in
CLEAR Framework for Enterprise Architecture - Atos Origin's Enterprise
OBASHI - the OBASHI Business & IT methodology and framework
Information FrameWork (IFW) - conceived by Roger Evernden in 1996
Zachman Framework - an architecture framework, based on the work of
John Zachman at IBM in the 1980s
The Enterprise Framework - an architecture framework, developed by
Sam Holcman at the Enterprise Architecture Center of Excellence ()
 Defense industry frameworks
DoDAF - the US Department of Defense Architecture Framework
MODAF - the UK Ministry of Defence Architecture Framework
NAF - the NATO Architecture Framework
AGATE - the France DGA Architecture Framework
DNDAF - the DND/CF Architecture Framework (CAN)
 Government frameworks
Government Enterprise Architecture (GEA) - a common framework
legislated for use by departments of the Queensland Government
FDIC Enterprise Architecture Framework
Federal Enterprise Architecture Framework (FEAF) - a framework
produced by the Office of Management and Budget for use within the
NIST Enterprise Architecture Model
Treasury Enterprise Architecture Framework (TEAF) - a framework for
treasury, published by the US Department of the Treasury in July
Nederlandse Overheid Referentie Architectuur (NORA) - a reference
framework from the Dutch Government E-overheid NORA
A decision support systems (DSS) is a computer-based information system
that supports business or organizational decision-making activities. DSSs serve
the management, operations, and planning levels of an organization and help
to make decisions, which may be rapidly changing and not easily specified in
DSSs include knowledge-based systems. A properly designed DSS is an
interactive software-based system intended to help decision makers compile
useful information from a combination of raw data, documents, personal
knowledge, or business models to identify and solve problems and make
Typical information that a decision support application might gather and
inventories of information assets (including legacy and relational data
sources, cubes, data warehouses, and data marts),
comparative sales figures between one period and the next,
projected revenue figures based on product sales assumptions.
According to Keen (1978), the concept of decision support has evolved from
two main areas of research: The theoretical studies of organizational decision
making done at the Carnegie Institute of Technology during the late 1950s and
early 1960s, and the technical work on interactive computer systems, mainly
carried out at the Massachusetts Institute of Technology in the 1960s. It is
considered that the concept of DSS became an area of research of its own in
the middle of the 1970s, before gaining in intensity during the 1980s. In the
middle and late 1980s, executive information systems (EIS), group decision
support systems (GDSS), and organizational decision support systems (ODSS)
evolved from the single user and model-oriented DSS.
According to Sol (1987) the definition and scope of DSS has been migrating
over the years. In the 1970s DSS was described as "a computer based system
to aid decision making". Late 1970s the DSS movement started focusing on
"interactive computer-based systems which help decision-makers utilize data
bases and models to solve ill-structured problems". In the 1980s DSS should
provide systems "using suitable and available technology to improve
effectiveness of managerial and professional activities", and end 1980s DSS
faced a new challenge towards the design of intelligent workstations.
In 1987 Texas Instruments completed development of the Gate Assignment
Display System (GADS) for United Airlines. This decision support system is
credited with significantly reducing travel delays by aiding the management of
ground operations at various airports, beginning with O'Hare International
Airport in Chicago and Stapleton Airport in Denver Colorado.
Beginning in about 1990, data warehousing and on-line analytical processing
(OLAP) began broadening the realm of DSS. As the turn of the millennium
approached, new Web-based analytical applications were introduced.
The advent of better and better reporting technologies has seen DSS start to
emerge as a critical component of management design. Examples of this can
be seen in the intense amount of discussion of DSS in the education
DSS also have a weak connection to the user interface paradigm of hypertext.
Both the University of Vermont PROMIS system (for medical decision making)
and the Carnegie Mellon ZOG/KMS system (for military and business decision
making) were decision support systems which also were major breakthroughs
in user interface research. Furthermore, although hypertext researchers have
generally been concerned with information overload, certain researchers,
notably Douglas Engelbart, have been focused on decision makers in particular.
As with the definition, there is no universally-accepted taxonomy of DSS either.
Different authors propose different classifications. Using the relationship with
the user as the criterion, Haettenschwiler differentiates passive, active, and
cooperative DSS. A passive DSS is a system that aids the process of decision
making, but that cannot bring out explicit decision suggestions or solutions. An
active DSS can bring out such decision suggestions or solutions. A cooperative
DSS allows the decision maker (or its advisor) to modify, complete, or refine
the decision suggestions provided by the system, before sending them back to
the system for validation. The system again improves, completes, and refines
the suggestions of the decision maker and sends them back to her for
validation. The whole process then starts again, until a consolidated solution is
Another taxonomy for DSS has been created by Daniel Power. Using the mode
of assistance as the criterion, Power differentiates communication-driven DSS,
data-driven DSS, document-driven DSS, knowledge-driven DSS, and model-
A communication-driven DSS supports more than one person working on a
shared task; examples include integrated tools like Microsoft's NetMeeting or
A data-driven DSS or data-oriented DSS emphasizes access to and
manipulation of a time series of internal company data and, sometimes, external
A document-driven DSS manages, retrieves, and manipulates unstructured
information in a variety of electronic formats.
A knowledge-driven DSS provides specialized problem-solving expertise
stored as facts, rules, procedures, or in similar structures.
A model-driven DSS emphasizes access to and manipulation of a statistical,
financial, optimization, or simulation model. Model-driven DSS use data and
parameters provided by users to assist decision makers in analyzing a situation;
they are not necessarily data-intensive. Dicodess is an example of an open
source model-driven DSS generator.
Using scope as the criterion, Power differentiates enterprise-wide DSS and
desktop DSS. An enterprise-wide DSS is linked to large data warehouses and
serves many managers in the company. A desktop, single-user DSS is a small
system that runs on an individual manager's PC.
Design of a Drought Mitigation Decision Support System.
Three fundamental components of a DSS architecture are:
1. the database (or knowledge base),
2. the model (i.e., the decision context and user criteria), and
3. the user interface.
The users themselves are also important components of the architecture.
 Development Frameworks
DSS systems are not entirely different from other systems and require a
structured approach. Such a framework includes people, technology, and the
DSS technology levels (of hardware and software) may include:
1. The actual application that will be used by the user. This is the part of the
application that allows the decision maker to make decisions in a particular
problem area. The user can act upon that particular problem.
2. Generator contains Hardware/software environment that allows people to easily
develop specific DSS applications. This level makes use of case tools or
systems such as Crystal, AIMMS, and iThink.
3. Tools include lower level hardware/software. DSS generators including special
languages, function libraries and linking modules
An iterative developmental approach allows for the DSS to be changed and
redesigned at various intervals. Once the system is designed, it will need to be
tested and revised for the desired outcome.
There are several ways to classify DSS applications. Not every DSS fits neatly
into one category, but may be a mix of two or more architectures.
Holsapple and Whinston classify DSS into the following six frameworks:
Text-oriented DSS, Database-oriented DSS, Spreadsheet-oriented DSS, Solver-
oriented DSS, Rule-oriented DSS, and Compound DSS.
A compound DSS is the most popular classification for a DSS. It is a hybrid
system that includes two or more of the five basic structures described by
Holsapple and Whinston.
The support given by DSS can be separated into three distinct, interrelated
categories: Personal Support, Group Support, and Organizational Support.
DSS components may be classified as:
1. Inputs: Factors, numbers, and characteristics to analyze
2. User Knowledge and Expertise: Inputs requiring manual analysis by the user
3. Outputs: Transformed data from which DSS "decisions" are generated
4. Decisions: Results generated by the DSS based on user criteria
DSSs which perform selected cognitive decision-making functions and are
based on artificial intelligence or intelligent agents technologies are called
Intelligent Decision Support Systems (IDSS).
The nascent field of Decision engineering treats the decision itself as an
engineered object, and applies engineering principles such as Design and
Quality assurance to an explicit representation of the elements that make up a
As mentioned above, there are theoretical possibilities of building such systems
in any knowledge domain.
One example is the clinical decision support system for medical diagnosis.
Other examples include a bank loan officer verifying the credit of a loan
applicant or an engineering firm that has bids on several projects and wants to
know if they can be competitive with their costs.
DSS is extensively used in business and management. Executive dashboard
and other business performance software allow faster decision making,
identification of negative trends, and better allocation of business resources.
A growing area of DSS application, concepts, principles, and techniques is in
agricultural production, marketing for sustainable development. For example,
the DSSAT4 package, developed through financial support of USAID
during the 80's and 90's, has allowed rapid assessment of several agricultural
production systems around the world to facilitate decision-making at the farm
and policy levels. There are, however, many constraints to the successful
adoption on DSS in agriculture.
DSS are also prevalent in forest management where the long planning time
frame demands specific requirements. All aspects of Forest management, from
log transportation, harvest scheduling to sustainability and ecosystem
protection have been addressed by modern DSSs. A comprehensive list and
discussion of all available systems in forest management is being compiled
under the COST action Forsys
A specific example concerns the Canadian National Railway system, which
tests its equipment on a regular basis using a decision support system. A
problem faced by any railroad is worn-out or defective rails, which can result in
hundreds of derailments per year. Under a DSS, CN managed to decrease the
incidence of derailments at the same time other companies were experiencing