The Open Group is acting on a vision to “create a worldwide
market for interoperable IT products supporting integrated access to integrated
information, in which all stakeholder needs are addressed.”

For too long, IT customers have had to pay for the failure
of IT suppliers to get their products to work together effectively. To avoid
negatively impacting business, IT customers have often had no choice but to pay
for "integration services" that simply consume development budget
today and increase maintenance costs down the road.

IT customers have each experienced the frustration of trying
individually to get key IT suppliers to fix this problem. Many have also tried
collaborative efforts, both within their own industry and across industries, to
marshal collective procurement $$ to bring pressure on the supply side.

Also for too long IT suppliers have had to deal with large
lists of vague and ambiguous requirement statements. This has resulted in the
implementation of some features that had no market value, and others that
didn’t actually fulfill the real needs of the customer, and all at enormous
costs.

We all know that open standards can help, but they must be
the right standards addressing the right areas. The Open Group is offering a
unique opportunity to come together to provide leadership for global information
technology standards and certification practices.

Actively participating in setting the directions for open
standards will help ensure that the standards that move forward are those best
positioned to support your business.

To further these aims, The Open Group is evolving this
business scenario[1] that
describes the problem caused by the lack of interoperability. The Open Group
will use this business scenario to achieve convergence around the real business
issues that IT suppliers should be addressing on behalf of their customers, and
to set in motion an empowered team of our technical champions to work with The
Open Group in setting the standards agenda to address these problems.

As a technology neutral forum for both customers and
vendors, The Open Group is ideally positioned to facilitate effective dialog
between the buy side and supply side of the IT industry. It is unique in
underpinning the results of IT standards efforts - both its own and those of
other standards bodies - with a world-class product certification process.

In the information age, many enterprises have passed the point
where information technology merely supports or enables the business –
increasingly, information technology is the business.

The business scenario documented here addresses the issue of
integrated information, and integrated access to that information, in order
to support the many different business processes of the enterprise - both
internal, and spanning the key interactions with suppliers, customers, and
partners. The title “The Interoperable Enterprise” connotes the end
state vision of addressing the above issue.

The main technical challenge in addressing this problem is
the lack of interoperability between the different systems that generate and
provide access to the data, and of the underlying IT infrastructure, whether
these are based on COTS products or custom-built solutions.

The buy
side and the supply side of the industry typically have different explanations
for this.

Customers
often cite:

Decreased commitment and accountability of suppliers in
solving the real business problems of their customers in their products

Increased focus of suppliers on the services model –
vendors externalize the interoperability cost and pass it on to customers as
integration services, rather than internalizing and solving the core problem in
their products

Increased interest of suppliers in selling rather than
delivering

Conversely, suppliers often cite:

Failure of
customers to develop and deliver a sufficiently integrated process definition
and corresponding set of requirements.

Tendency of customers to give requirements for
different parts of the business to different vendors at different times, on a
short-term, point-solution basis, with no integrated or long-term view

Tendency of customers dictate solutions to vendors
rather than describe requirements

to which customers would
counter that:

After solutions have been deployed and have matured,
organizations often re-examine their internal and external business processes.
This leads to the emergence of opportunities and needs for system-to-system
cooperation that were not identified originally.

Customers often have to make pragmatic and conscious
decisions to select / designate / design solutions that meet local
requirements, knowing full well that system-to-system interoperability will be
difficult and expensive to obtain at a future time. These decisions are driven
by business imperatives, even if from a purely IT perspective they are
sub-optimal.

There are probably elements of truth in both of these
positions. The situation is further
complicated by the continued development of new and incompatible technologies
that are embraced by both suppliers and buyers.

Whatever the cause, customers would still like to be able to
choose best-of-breed solutions for each business application area and for the
supporting IT infrastructure, have it all “just work”. Instead, they are forced
to choose between selecting entire product suites with less than optimal
functionality, in the hope that the components of the suite will at least
interoperate; and non-interoperable products, with the concomitant integration
cost and the on-going cost of maintaining the resulting custom-built
integration solution.

In many cases customers have tried a common product line as
the basis of a solution to their interoperability problem, and have found it
wanting.

Standards can help, but in a world of limited resources,
customers often face a choice between developing standards to retrofit to
existing problems, versus seizing a window of opportunity to influence emerging
technologies, where product suppliers have not yet established a dominant
market position, and customers have not yet developed a large legacy of
developed systems, so that standards can help solve or avoid the problems of
lack of interoperability.

The challenge to The Open Group is to marshal the necessary
resources and critical mass from both the buy-side and supply-side of the
industry to deal effectively with the issues identified in this business
scenario.

The Open
Group aims to help IT customers and suppliers alike to realise the vision of
the Interoperable Enterprise, by means a two-fold strategy.

Firstly, The Open Group hopes to enable IT customers
and suppliers to share a common understanding of the requirements of customers
for interoperable IT solutions, so that the supply side in particular will be
able to construct the business case for creating the interoperable solutions,
in both applications and infrastructure products, that genuinely address those requirements.

Secondly, The Open Group
intends to deliver, to IT
customers and suppliers alike, the assurance of interoperability that will
enable the IT market to function effectively.

This
document forms an essential part of the first element of this strategy.

Enterprises within an individual vertical industry sector
such as Transportation often find they have many problems in common both in
their applications suites and their IT infrastructures as depicted in the
figure below. In the figure below you see that many manufacturers have
different manufacturing processes, different manufacturing process support
business logic, and different metadata. However it is likely that there is
commonality in the scheduling, procurements, and human resources areas.

Figure
1: Common Issues in an Industry

The same holds true even for enterprises in ostensibly very
different vertical sectors like Transportation, Finance, and Petrochemicals as
depicted in a similar manner by the following figure.

Figure 2: Common Issues Across
Industries

The Open Group intends to develop from this document both a
single, guiding, generic Business Scenario that captures interoperability
issues that are common across most vertical sectors; and a suite of
industry-specific scenarios – one for each vertical sector for which it can
find CIOs and Chief Architects willing to collaborate with it – that elaborate
on the aspects that are specific to the sector concerned.

Like much of The Open Group’s output, this scenario and its
companions will in due course be placed in the public domain, so that
organizations around the world can see the progress of the initiative,
contribute to it, and leverage it where appropriate.

Business
Scenario

The Interoperable Enterprise

Interoperability is very important to us, we integrate
technology on the fly for a joint task force …we get interoperable products
that are cost effective out of the box so we get better products that we can
integrate easily to provide capability to our war fighters. – Ms. Dawn
Meyerriecks, CTO DISA

Ms. Meyerriecks’ statement above is demonstrative of the
need for products that work together more readily and easily. Here Ms.
Meyerriecks points out the benefits of products that are capable of working
together more readily in support of a very important mission. It is not
necessarily understood from day one that each and every product work together,
because in a mission scenario much can happen to require things to work
together out of necessity. Ms.
Meyerriecks’ challenge is very similar to the challenges in the commercial
sector, as missions change; systems need to interoperate with other systems out
of necessity. Even systems that do not interoperate today might be required to
interoperate tomorrow. Ms. Meyerriecks often sites the importance of open
standards in making this possible.

The business
scenario documented here addresses the issue of gaining operational
efficiencies through integrated information, and integrated access to that
information, in order to support the many different business processes of the
enterprise - both internal, and spanning the key interactions with suppliers,
customers, and partners.

The main technical
challenge in addressing this problem is the lack of interoperability between
the different systems that generate and provide access to the data, and between
different parts of the underlying IT infrastructure, whether these are based on
COTS products or on custom-built solutions. In practice the results of
addressing this challenge are often technical work-arounds, which not only
represent greater IT cost – they are costly to develop initially, and lead to
greater on-going maintenance cost – but also lead to greater business
operational cost due to mis-routing of supplies, services, and personnel, etc.,
or in extreme situations to loss of life.

Currently new
approaches are being explored, for example at the storage level (with
technologies such as Storage Area Networking (SAN) and Network Attached Storage
(NAS)) in order to integrate different sources of information, and at the
portal level in order to provide integrated access to domain-specific
information areas. However, applying new technologies that are non-standard
inevitably cause new pain – e.g., multiple portal infrastructures that are not
interoperable, and that may actually conflict with each other. Therefore The
Open Group sees value in looking at the approaches and the necessary standards
in possible solution areas to help the buy-side address this business scenario.

The present draft
of this business scenario is based on information that was gathered in two
workshops and follow-up analysis conducted in mid-year 2001. Contributions come
from:

Elaine Babcock, US Dept of Defense/DISA

Terry Blevins, The Open Group

Allen Brown, The Open Group

Ian Dobson, The Open Group

Alan Doniger, Petrotechnical Open
Software Corporation

William Priestley, Compaq Computer
Corporation

Russ Richards, US Department of Defense

Skip Slone, Lockheed Martin

Martin Smith, The Security Company

John Spencer, The Open Group

Walter Stahlecker, Hewlett-Packard
Company

This work was a
result of two workshops focused on gathering an understanding of
interoperability. After proceeding with each workshop and considering the
discussions, the description of the business scenario in each case could be
characterized as: “Gaining operational efficiencies throughintegrated
information, and integrated access to that information, in order to support the
many different business processes of the enterprise - both internal, and
spanning the key interactions with suppliers, customers, and partners.”
Providing integrated access to integrated information will support the
interoperation of the business processes within the enterprise.

While the
characterization above is technically precise, this statement makes for a less
than inspiring document title, and so the short-hand “The Interoperable
Enterprise” has been adopted as the title of this Business Scenario.

The purpose
of this business scenario is to express business and technical requirements
– not solutions – and to communicate them effectively to the IT market. The
intent is to enable the supply side to understand the needs of the buy side,
and the value proposition for meeting those needs, and to engage them in
delivering the solutions. The ultimate goal is the availability of products
that support integrated access to integrated information that meets the needs
of all its stakeholders.

The
business scenario is generic, and describes an idealised enterprise, but it is based on inputs from a
number of real organizations, and is supported by specific examples in
the appendices.

This
document will be a starting point rather than a final product. The intent is to
add to it with input from a wider community of CIOs and Chief Architects of
organizations who are experiencing similar problems and who seek to drive the
standards process into the market if needed, so that the market will provide
the solutions that genuinely address their needs.

Interoperability – The
ability of two or more systems or components to exchange information and use
the information that has been exchanged to do useful work. In this business
scenario this term specifically relates to the challenges of providing
integrated access to information and providing integrated information and
infrastructure so business processes can exchange information and do useful
work.

This business scenario
describes how information managed by various applications in various
environments needs to support operational and process efficiencies.

The main drivers for the scenario are the
generic business needs to:

Provide
integrated access to integrated information by staff, customers,
suppliers, and partners, to
support the business

Provide
higher quality products and service to customers

Maintain the security and
confidentiality of information.

In addition
to the business drivers, there are often legal and regulatory requirements
relating to access to information, and to the security and confidentiality of
information, such as the safety requirements
imposed by the FAA on the air transportation industry.

The main objectives are typically
to:

Improve business process performance – for
example if the process is a logistics process where food is provided to the war
fighter, then the performance metrics would be associated with the success of
that process; if the process is about product lifecycle development, the
metrics could be about budget, time, break even time, return on investment,
etc.

Decrease IT costs – implementing a standards
based solution to the problems described in this business scenario will help
remove redundancy and duplication in IT assets throughout the enterprise,
decrease the reliance on external IT service providers for integration and
customization, and for subsequent maintenance, and will reduce the need for
data translation between different formats used by different systems.

Improve effectiveness of business operations –
lower overall IT costs means being able to allocate budget to new business
features rather than “keeping things running”, and this in turn will decrease
the costs of running the business, decrease the time to market for the
enterprise’s products, and increase the quality of its services to customers.
Reducing the need for data translation will also improve the quality of
business information and thereby increase business operations efficiency.

Improve effectiveness of information technology
organization – information technology is currently a restraint not an
enabler. Service provision to users is poor, and information technology changes
are not implemented when the business needs them.

Improve management efficacy – today the
information technology environment system is too complex to manage and is often
not managed by a strategic architecture. This results in difficulty of
balancing the short and long term choices.

Reduce risk – complexity in the information
technology environment makes it all the harder to implement effective security
processes. Errors introduced into business processes through complex and faulty
IT systems can lead to real world safety hazards, and even to loss of life.

Effective interoperable
IT solutions can significantly
contribute directly or indirectly to all the above objectives by avoiding the
inefficiencies and inaccuracies of manually transferring information from one
system to another.

Conversely, the customers represented in this business
scenario indicate that the lack of interoperability in information technology
generally causes the following “pain” symptoms, which effective interoperable
IT solutions would address:

Increasing IT
cost without related improvement in productivity

redundancy and
duplication in IT assets

increased
maintenance cost

increased
reliance on (expensive) external IT service providers

Lack of
effectiveness of IT in delivering required services to the business

The following budget
classifications are typical key measures of success in addressing the issues in
this business scenario, from a customer viewpoint. To the extent that IT
customers are able to spend IT budget in pursuit of these measurable goals,
they also represent the basis of the value proposition for IT suppliers.

Funding growth
through consolidation - improved asset utilization

but
- IT must deliver

·
Improving business operations

effectiveness
of business operations more important than effectiveness of IT - leverage
is orders of magnitude higher

Enterprises range from small, unified companies to large,
complex, distributed organizations. Interoperability is important to them all,
but the value increases with the organization’s size and complexity. The
organizations on whose experience this scenario is based are generally at the
upper end of the complexity scale.

The key organizations and entities in the typical business
environment – particularly those relevant to the processes discussed in this
Scenario – are illustrated in the following figure.

Figure 3: The Business Environment

Not all
organizations will have all of these internal components and external
relationships. But the figure can be used to bring out a number of points
typical of complex modern-day enterprises, each of which has particular
implications for issues of interoperability. Points to note:

The organization typically has a number of facilities
of different kinds and in different locations. These include
shops, offices, warehouses, factories, and laboratories. They may also include
special-purpose facilities such as hospitals, oil rigs, and construction sites.

In addition to fixed locations, an organization usually
has users who are mobile. Users can roam between different locations
inside and outside the organization.

Organizations have business relationships with other
organizations of various kinds, including customers, suppliers, risk
sharing partners, banks, legal advisors, regulatory agencies, and government
departments.

As well as having established business relationships,
an organization may interface with the general public.

The shape of the organization and its business
relationships can change dynamically.

The distinction between those “inside” and those
“outside” the organization may not be easy to make.

The high level processes that are the subject of this
scenario are numerous, but they fall into three general categories: buy side,
internal, and sell side processes. Whether the processes are
automated or assisted by people, they need to have access to information in
order to work. Integrated access to integrated information would significantly
improve the execution of all these processes.

Process Categories

Process Description and Output

Buy side processes

Buy-side processes include
processes such as ordering, procurement, and accounts payable and receivable.

The technical environment has hundreds or thousands of
systems and equipment types that cannot be used together. Some of the systems
are “legacy” systems and some are new systems. There is mission value in
mapping the information in these legacy systems to current systems if the price
is affordable. This is usually driven by the need to improve process
efficiency. A new process requires the interoperation of multiple stove piped
systems to enable exchange of information with the various legacy systems.

Current solutions include translators and manual re-entry of
data. Another solution approach is to reduce to a minimum the number of systems
that perform similar functions. Another dimension of the environment is that of
currency of information; existing information ranges from being very stale to
being current in a real-time sense. Similar data sometimes has different levels
of integrity, depending on where it is in the overall process. Finally some of
the data is stored and carried around on laptops and desktops rather than in
safe repositories (data stores).

The key entities in the technical environment relevant to
the processes discussed in this Business Scenario are illustrated in Figures 4a
and 4b. Below is a high level depiction of the drive for integrated information
and access points. The fundamental driver is the need to improve business
operations through new processes or improvements to existing processes. This is
generating demands to integrate information from multiple sources of the same
or similar type data, e.g. the multiple procurement systems or multiple
requirements systems. Additionally the information is transferred from one
system to another when operating new business processes under technologies such
as process and workflow. Finally information is provided through integrated
access points to users such as customers, suppliers, and internal employees.

Figure 4a: The Technical Environment – Integrated Information

Figure 4b: User Views –
Integrated Access to Integrated Information

Within the business
environment there are multiple businesses areas involved, usually:

Buy
side processes of the business – suppliers

Internal
processes of the business – employees and partners

Sell
side process of the business – customers

The systems will typically be a mix
of systems specific to particular vertical domains and systems common to
multiple vertical domains. In the manufacturing domain, for example, the
product lifecycle processes typically include:

product definition;

manufacturing process design and definition;

inbound logistics;

workflow / shop floor logistics;

outbound logistics (fulfillment/delivery);

maintenance; and

discontinuance

Systems that support enterprise
functions common to a number of vertical domains typically include:

The following table maps the individual process categories
to presumed environments, either business or technical environments.

High Level Processes

Environment mapping

Buy
side processes

These processes are dealing with
suppliers, the procurement organizations, and the accounting departments.
Also in today’s approaches collaboration services are used frequently to
facilitate these processes, for example to obtain signatures of authority.

Internal
processes

These processes are dealing with
the internal employees of the organization across departmental boundaries.
The organization can be a company or a government.

Sell
side processes

These processes are dealing with
users of the organization’s products or services, be they customers of a
private company or civilian beneficiaries of a government service. The sell
side processes include processes such as sales, customer support, and
customer relationship management.

Figure 5
provides a “network” view of the various components in an IT environment that
has the types of issues outlined in this business scenario. The diagram shows
the diversity of information technology within most organizations, i.e. that
many departments have various types of servers and clients. The clients are
also inside and outside the firewall indicating a need for access from either
position. Network access is provided through external ISPs where needed.

Figure 5: Network View of Technology Environment

Figure 6
depicts the detail of a typical department. Of importance here is the depiction
of the numerous owners of the subject data; from the clients, desktops,
applications servers, database servers, and file servers.

No attempt
is made here to describe a “generalized” set of human actors and roles, since
these will be entirely dependent on the enterprise concerned. Lists of actors
and roles for the specific enterprises that provided input to this business
scenario are given in the various appendixes to this document.

The
following table provides a very high level list of computer actors and their
roles. The list is segmented into layers. Note that between client and server
layers there appear to be overlap, e.g. web portal. In the client there is
software that exposes the web portal to the user, in the server there is
software that fulfills the requests from the client.

Note there
is a fundamental assumption that the network can be “opened” through the
appropriate use of routers, switches and networking protocol converters. This
particular part of the problem is out-of-scope of this business scenario.

Openness – Standards based open
interfaces need to exist for critical interfaces to more easily provide
interoperability and integration of components. For example the areas of
protocols, web portal, collaboration, database, and storage connections
would require standards based interfaces. The rationale for this is that
without open standards based interfaces the implementation of web portals
for integrated access and storage solutions for integrated information
will cause interoperability issues down the road.

Data integrity – today the same data
actually is stored in many places and in many formats. For example a
customer record may reside in multiple databases in multiple places. The
solution must support interoperability by translating as necessary between
the multiple formats. For example if height is stored in multiple places,
then the solution must assure that when height is used, it is provided to
the user (person or application) in the desired unit, e.g. feet, inches,
meters, etc.

Availability – the solutions being
proposed must be available 7*24*365 as business processes that must be
available continuously are using these services. This places high
requirements on all services of the system. Where maintenance requires
downtime, fallback services must be available.

Security – the solutions being provided
must be able to support different security levels and protection based
upon both the sensitivity of the data, whether or not the data is exiting
the firewall, and the use of the data. Included are the normal
requirements for data integrity, confidentiality, logging and tracking.
The system security must provide flexible policy management to handle
these situations. Additionally the solution must provide strong
authentication yet provide users with single sign-on and user
administration. PKI certificates are managed by either internal or
external certification authorities.

Accessibility – the solutions being
proposed must provide global accessibility to the information while not
compromising security.

Manageability – the solutions must be
manageable.

Internationalization and Localization –
as the solutions will be deployed around the world they should be designed
to accommodate multiple languages and adapt to cultural and technical
requirements of specific countries.

Solutions should be based on standards – which can be
international, imposed, or market-driven given the need to assure new
technologies can more easily allow for interoperation and integration in the
future.

This section does not attempt to define a complete nor
technically accurate technology architecture. In the first place, the
requirements are only partially understood at present. In the second place,
even if the requirements were understood completely, circumstances differ so
widely between different enterprises that it is unlikely that a single
architecture could suit them all.

What this section does attempt to do is to present a
software architecture that depicts the key components and subcomponents. Figure
7 depicts an architecture that supports the processes described in this
business scenario. This software architecture was created as part of the
analysis of the issues presented here. Note the 3 separate major components;
the Client, the Network, and the Server. Also there is a backplane of two key
qualities driven by an organizations policy, security and management.

At the heart of this effort is a new global initiative on
the part of The Open Group to create a trusted forum at the level of the CIOs
and Chief Architects of the Fortune 500 IT customer organizations and their
equivalents around the world. The Open Group believes that a key responsibility
of CIOs is to lead the task of standardization within the IT industry, so that
standards initiatives are driven by the real business needs and requirements of
the global IT customer community rather than by ad hoc technology trends and
vested interests.

This scenario document provides a vehicle to communicate
business needs and requirements, and to articulate them in a common format.
Through this The Open Group hopes to foster a common understanding of the
requirements of IT customers for interoperable IT solutions, so that the supply
side in particular will have the business case for creating the interoperable
solutions in both applications and infrastructure products that genuinely
address those requirements.

The business requirements
presented above included measures. These measures are measures that a business
would use to determine if progress was being made in addressing the problems
described in this business scenario. The following table suggests how The Open
Group could support those measures through possible actions.

Business Measure

Support from
The Open Group

Funding growth through
consolidation

Providing standards and
certification of products that:

Provide consolidation of information

Provide integrated access to information

Improving business operations, effectiveness of business
operations more important than effectiveness of IT

Driving revenue growth

Lower IT spend for the entire
organization

Increase % of procurements against
standards

Decrease spend on customizations

Improved cycle time for rolling
out upgrades

An initial analysis of this business scenario has resulted
in the identification of two of many possible areas of emerging
technology, where The Open Group’s strengths of providing a trusted, technology-neutral
forum for customer/supplier dialog, standards integration to facilitate market
growth, and acknowledged certification skills, can be brought to bear
effectively. These technology areas are: web portal technologies; and Storage
Area Networking (SAN) / Network Attached Storage (NAS). Web portal technologies
address integrated access, and SAN/NAS address integrated information. There
may be more or other alternatives that address integrated access and integrated
information and it is hoped that exposing this business scenario to public
scrutiny will expose these alternatives. The appropriate groups within The Open
Group, such as the Customer and Supplier Councils, should decide whether other
possibilities should be explored.

We have documented some issues related to interoperability
in this paper and identified some areas that could be tackled. There are many
opportunities for standardization, in many areas that will ease the pain
associated with tackling interoperability issues. Identifying and selecting the
areas that The Open Group will tackle is the main focus of the next steps
required to move forward.

The following represents further actions recommended.

Publish and present Revision 1.0 of this paper in
Amsterdam - done

Revise based upon feedback and republish in Anaheim - done

Convene a customer-member sub committee to review the
document for action

Convene a supplier-member sub committee to review the
document for action

Convene a combined customer and supplier member meeting
to compare results and propose a way forward to deal with the requirements
considering some of the subjects below:

Storage Area Network (SAN) *
– A back-end network connecting storage devices via peripheral channels such as
SCSI, SSA, ESCON and Fibre Channel. There are two ways of implementing SANs:
centralized and decentralized. A centralized SAN ties multiple hosts into a
single storage system, which is a RAID device with large amounts of cache and
redundant power supplies. The cabling distances allow for local as well as
campus-wide and metropolitan-wide hookups over peripheral channels rather than
an overburdened network. SCSI distances have also been extended. Using fiber,
Gigalabs' SCSI switches can communicate over 20 km. This centralized storage
topology is commonly employed to tie a server cluster together for failover.

Network Attached Storage (NAS) *
– A specialized file server that connects to the network. A NAS device contains
a slimmed-down (microkernel) operating system and file system and processes only
I/O requests by supporting popular file sharing protocols such as NFS (UNIX)
and SMB (DOS/Windows). Using traditional LAN protocols such as Ethernet and
TCP/IP, the NAS enables additional storage to be quickly added by plugging it
into a network hub or switch. As network transmission rates have increased from
Ethernet to Fast Ethernet to Gigabit Ethernet, NAS devices have come up to
speed parity with direct attached storage devices.

The following detailed
description is taken from Part IV of The Open Group Architectural Framework
(TOGAF) - http://www.opengroup.org/public/arch/. This publicly available document describes
an open framework and method for IT architecture, which includes Business
Scenarios as a method for articulating the business and technical requirements
that architecture work is to address.

A key factor in the success of any IT architecture is the
extent to which it is linked to business requirements, and demonstrably
supporting and enabling the enterprise to achieve its business objectives.

Business scenarios are an important technique that may be
used prior to, and as a key input to, the development of the architecture, to
derive the necessary characteristics of the Technical Architecture directly
from the high-level requirements of the business. They are used to help
identify and understand business needs, and thereby to derive the business
requirements that the architecture development has to address.

A Business Scenario describes:

a
business process, application, or set of applications, that can be enabled
by the architecture

the
business and technology environment

the
people and computing components (called "actors") who execute
the scenario

the
desired outcome of proper execution

A good Business Scenario is representative of a significant
business need or problem, and enables vendors to understand the value to the
customer organization of a developed solution.

A good Business Scenario is also "SMART":

Specific,
by defining what needs to be done in the business

Measurable,
through clear metrics for success

Actionable,
by clearly segmenting the problem, and providing the basis for determining
elements and plans for the solution

Realistic,
in that the problem can be solved within the bounds of physical reality,
time and cost constraints

Time-bound,
in that there is a clear statement of when the solution opportunity
expires

A business scenario is essentially a complete description of
a business problem, both in business and in architectural terms, which enables
individual requirements to be viewed in relation to one another in the context
of the overall problem. Without such a complete description to serve as
context:

There
is a danger of the architecture being based on an incomplete set of
requirements that do not add up to a whole problem description, and that
can therefore misguide architecture work.

The
business value of solving the problem is unclear

The
relevance of potential solutions is unclear

Also, because the technique requires the involvement of
business line management and other stakeholders at an early stage in the
architecture project, it also plays an important role in gaining the buy-in of
these key personnel to the overall project and its end-product - the IT
architecture.

An additional advantage of business scenarios is in
communication with vendors. Most architectures nowadays are implemented by
making maximum use of commercial off-the-shelf software (COTS) solutions, often
from multiple vendors, procured in the open market. The use of business
scenarios by an IT customer can be an important aid to IT vendors in delivering
appropriate solutions. Vendors need to ensure that their solution components
add value to an open solution and are marketable. Business scenarios provide a
language with which the vendor community can link customer problems and
technical solutions. Besides making obvious what is needed, and why, they allow
vendors to solve problems optimally, using open standards and leveraging each
other's skills.

The documentation of a Business Scenario should contain all
the important details about the scenario. It should capture, and sequence, the
critical steps and interactions between actors that address the situation. It
should also declare all the relevant information about all actors,
specifically: the different responsibilities of the actors; the key
pre-conditions that have to be met prior to proper system functionality; and
the technical requirements for the service to be of acceptable quality.

There are two main types of content: graphics (models), and
descriptive text. Both have a part to play.

Business Scenario models capture business and technology
views in a graphical form, to aid comprehension. Specifically, they relate
Actors and interactions, and give a starting point to confirm specific
requirements.

Business Scenario descriptions capture details in a textual
form. A typical contents list for a business scenario is given below.

It is important to realize that the creation of a business
scenario is not solely the province of the Architect. As mentioned previously,
business line management and other stakeholders in the enterprise are involved,
to ensure that the business goals are accurately captured. In addition,
depending on the relationship that an organization has with its IT vendors, the
latter also may be involved, to ensure that the roles of technical solutions
are also accurately captured, and to ensure communication with the vendors.

Typically, the involvement of the business management is greatest
in the early stages, while the business problems are being explored and
captured, while the involvement of the architect is greatest in the later
stages, when architectural solutions are being described. Similarly, if vendors
are involved in the business scenario process, the involvement of the customer
side (business management plus enterprise architects) is greatest in the early
stages, while that of the vendors is greatest in the later stages, when the
role of specific technical solutions is being explored and captured. This
concept is illustrated in Figure A-2.

Business Scenarios figure most prominently in the initial
phase of the Architecture Development Method (ADM), Initiation and Framework,
when they are used to define relevant business requirements, and to build
consensus with business management and other stakeholders.

However, the business requirements are referred to
throughout all phases of the ADM life cycle, as illustrated in Figure A-3.

Figure A-3:
Relevance of Requirements Throughout the TOGAF Architecture Development Method

Because business requirements are important throughout all
phases of the ADM life cycle, the Business Scenario method has an important
role to play in the TOGAF ADM, by ensuring that the business requirements
themselves are complete and correct.

The stakeholders (e.g., business managers, end-users) will
tell you what they want, but as an architect you must still gain an
understanding of the business, so you must know the most important actors of
the system.

If the stakeholders do not know what they want:

Take
time, observe and record how they are working today

Structure
information in such a way that it can be used later

Uncover
critical business rules from domain experts

Stay
focused on the "what", not the "how"

This effort provides the anchor for a chain of reason from
business requirements to technical solutions. It will pay off later to be
diligent and critical at the start.

Finally, it is important to remember that Business Scenarios
are just a tool, not the objective. They are a part of, and enable, the larger
process of architecture development, and the architect should use them, but not
get lost it them. The key is to stay focused - watch out for "feature
creep", and address the most important issues that tend to return the
greatest value.

The logistics process assures that supplies of food,
services, equipment, etc. are provided to the war fighter. The process crosses
ordering, fulfillment, packaging, tagging, loading, transportation, and
receiving.

Product
definition – develop the specifications for something that has to be
manufactured and delivered

Process
design and definition - take the product specifications and design a
repeatable process to manufacture a whole series of the products

Inbound
logistics - acquire all the materials that need to go into the
eventual product.

Shop
floor logistics - put under shop floor manufacturing control.

Outbound
logistics - fulfillment/delivery to end customer.

Maintenance
– of the delivered product

Discontinuance
– of the product and its entire life-cycle

These processes are supported by different systems, which
need to have access to similar data and would benefit from sharing data.
Product data may need to be maintained for decades, e.g. the designs of C-130
cargo aircraft is still maintained and used.

Solving problems in this area would lower risk, lower cost
(dis-intermediation), and improve efficiency.

The information intelligence process covers acquiring
dependable and reliable information on competitors. This process crosses:
intelligence gathering during and after conflicts; and analyzing and
distributing the information. The process can go as far downstream as providing
the information for target acquisition. The process goes through analysis, then
analysis management, then strategic command channels, then tactical command
channels, then possibly to war fighters and/or a command to fire. Many
transformations occur in the process, from the person collecting to the person
analyzing, to the decision maker, etc – the information has to be translated
from one format to another each time, and has to be retained for an indefinite
length of time. Information is stored in a variety of ways – for example in
data administration devices information is collected from aircraft, is buffered
and decision are made on how much to sample and store from transient to
permanent - then stored forever.