Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 71
Architecture, Strategies, Technologies, and Contracts 71
There can be confusion between the terms open architecture and open source. Open source
refers to the legal ownership of the programming language source code used to build the software.
An open source system is one where the program source code is freely available to everyone and
can be used and modified at will, provided that certain legal conditions are met. Open source
systems are, by their very nature, open architecture, because the necessary transparency is more
than adequately provided by the public availability of the source code.
On the other hand, a system does not have to be open source to be open architecture. A com-
pany can develop an open architecture system while still keeping the source code private. Follow-
ing are some of the many benefits of using open architecture systems:
· It is easier to integrate between open systems.
· People can add features as they become necessary in the future.
· It is easier to find technical resources to maintain open systems.
When procuring software systems, answer the following questions to ensure that the system
is based on an open architecture:
· Are the data stored in a relational database, and is there documentation on the database schema?
· Are there documented APIs for integrating with this system?
· What industry standards does this system support?
· Are there any built-in mechanisms for customizing or enhancing this product? Do the mech-
anisms use a proprietary programming language or a standardized scripting language?
· Are there other software systems that integrate with this system out of the box? What technolo-
gies are used in that integration?
Protocols
A significant piece of most system architectures is the protocols the system uses. A protocol is
a set of rules that allows multiple systems to exchange information. A protocol is like a diction-
ary that helps you communicate in a foreign language when traveling. If you need to find a
restaurant, you can use an English-French dictionary to find the French phrase to ask "Where is
the nearest restaurant?" But just as these translation dictionaries are limited, most protocols do
not allow for every conceivable piece of information to be communicated.
As with system architectures, protocols can be open or closed. An open protocol is one that
follows a published standard, such as TCP/IP, the set of communications protocols used by the
Internet. Open protocols allow multiple vendors to build systems that interact with each other
because they speak the same language. A closed protocol is a protocol that is specific to one ven-
dor and is not published or standardized. Closed protocols allow multiple systems from the same
vendor to communicate, but if you buy a new system from a different vendor, it will not support
that protocol.
Legacy Systems
The term legacy system refers to an old computer system that is still in use well past its origi-
nal life expectancy. Many legacy systems in use today were created before the popularity of open
architecture computing. Some legacy systems might have been built on an open architecture that
was valid when they were built, but the standards used then are so old that newer systems do not
support them today. Any legacy system, whether open architecture or not, can hinder integra-
tion because of the following:
· Lack of resources with knowledge of the system architecture,
· Hard to find or non-existent documentation on the system and/or standards, or
· Difficulty or impossibility of upgrading.
