Architecture centered publishing systems

ArchitectureArchitecture––CenteredCentered
Publishing SystemsPublishing Systems
Architecturebridgesthesemanticgap
betweentherequirementsand
software.
The use of an architecture–centered development process for delivering information technology began with
the introduction of client / server based systems. Early client/server and legacy mainframe applications did not
provide the architectural flexibility needed to meet the changing business requirements of the modern
publishing organization. With the introduction of Object Oriented systems, the need for an architecture–
centered process became a critical success factor. Object reuse, layered system components, data
abstraction, web based user interfaces, CORBA, and rapid development and deployment processes all
provide economic incentives for object technologies. However, adopting the latest object oriented technology,
without an adequate understanding of how this technology fits a specific architecture, risks the creation of an
instant legacy system.
Publishing software systems must be architected in order to deal with the current and future needs of the
business organization. Managing software projects using architecture–centered methodologies must be an
intentional step in the process of deploying information systems – not an accidental by–product of the
software acquisition and integration process.
Glen B. Alleman
Niwot Ridge Consulting
www.niwotridge.com
Niwot, Colorado 80503
Copyright © 2000, All Rights Reserved
Presented
IFRA Publishing Platforms Symposium
December 4
th
, 2000
Zurich Switzerland

Table of Contents
INTRODUCTION............................................................................................................... 1
THE SYSTEMS INTEGRATION PROBLEM.......................................................................... 1
STANDARDS VERSUS GUIDELINES ................................................................................. 2
WHAT IS SOFTWARE ARCHITECTURE?........................................................................... 2
ARCHITECTURE BASED INFORMATION TECHNOLOGY STRATEGIES.................................. 3
INFORMATION MANUFACTURING DOMAIN ....................................................................... 4
INTEGRATING HETEROGENEOUS ENVIRONMENTS .......................................................... 5
THE IMPEDANCE MISMATCH .......................................................................................... 6
APPLICATION INTEGRATION OVERVIEW .......................................................................... 7
APPLICATION INTEGRATION AND THE PUBLISHING DOMAIN ............................................. 8
THE INFORMATION MANUFACTURING DOMAIN................................................................ 9
CHARACTERISTICS OF OPEN INFORMATION SYSTEMS TECHNOLOGIES ......................... 11
MOTIVATIONS FOR ARCHITECTURE–CENTERED DESIGN .............................................. 11
Architectural Principles...................................................................................... 12
Architectural Styles............................................................................................ 13
4 + 1 ARCHITECTURE.................................................................................................. 14
MOVING FROM 4+1 ARCHITECTURE TO METHODOLOGIES............................................ 15
STRUCTURE MATTERS ................................................................................................ 16
REFERENCES................................................................................................................ 17
END NOTES.................................................................................................................... 20
Figures
Figure 1 – Integrating Diverse Newspaper Systems Components......................................... 5
Figure 2 – Classification of EAI Options .................................................................................. 7
Figure 3 – Domains of the Information Manufacturing Process ............................................. 9
Figure 4 – The 4+1 Architecture as Defined by [Kruc95]...................................................... 14

Niwot Ridge Consulting, Copyright © 2000 ¡ 1
INTRODUCTION
Much of the discussion in today’s literature is centered on applying the building
architectural analogies to the design and deployment of information systems.
[1]
This analogy glosses over many of the difficulties involved in formulating,
defining, and maintaining the architectural consistency associated with acquiring
and integrating Commercial Off The Shelf (COTS) applications. The successful
deployment of a COTS based system requires that the current business needs
be met, but also that the foundation of the future needs of the organization be
laid.
In many COTS products, the vendor has defined an architecture that may or
may not match the architecture of the user domain. It is unlikely the vendor’s
architecture will be a match for an organization that has mature business
processes and legacy systems in place. The result is an over–constrained
problem.
[2]
By acquiring a COTS application and installing it, the end user may have
unknowingly acquired the architecture of the application’s vendor. The
consequences of this decision may not be known for some time. If the
differences between the target architecture of the business and the architecture
supplied by the vendor are not determined before the acquisition of the COTS
product these gaps will be revealed during the systems operation — much to the
disappointment of the purchaser.
THE SYSTEMS INTEGRATION PROBLEM
In today’s news and information publishing environment, content resides on
many platforms distributed throughout the organization. Gaining access to the
right information at the right time is a daunting task. Integrating these diverse
information sources and the processes that manipulate them in a seamless
manner is called Enterprise Application Integration (EAI).
Enterprise integration should be viewed as a strategic initiative for every large
enterprise. The complexity of and the demands on modern computing environments
require a systematic, centralized approach to integration requirements to achieve
optimal value for the totality of enterprise information assets. Message brokers are an
emerging class of products that can be increasingly applied at the enterprise level.
— Patricia Seybold Group
Traditional methods of integrating systems involve building code that connects
the system components at the Application Programming Interface (API) level.
The result is a tightly coupled system that may or may not provide the needed
flexibility for future growth and adaptation. It also results in a system that
contains n
2
connections. At the same time, established enterprise solutions
(usually ERP based approaches) focus on solving business problems in a
predefined manner with commercial off the shelf products.
A new system deployment paradigm is needed to address the expanding
publishing needs for electronic commerce, Internet and multi–media publishing,
The subject of the integration of
heterogeneous publishing systems is
not only complex it is convoluted and
confusing.
By focusing on the architecture of the
system, the design and development
processes have a place to return to
when confusion sets in.
The problem in automating the
publishing enterprise is not developing
the underlying technology, or
discovering new requirements, or even
deciding how to address these
requirements with products or
services.
The problem is controlling
the complexity of the integrated
system that results from
all these activities.
One solution to the complexity issue is
to abstract the problem into a set of
reusable components.

the competitive pressures of the market, and the unceasing demand for
customer service.
This new paradigm is based on system architecture and the use of industry
standards.
[3]
These system integration standards include:
n CORBA
n MQ Series messaging systems
n Enterprise Java Beans
n XML based interprocess standards
STANDARDS VERSUS GUIDELINES
There is a major difference between standards and guidelines. A standard is a
rule that must be followed. A guideline is a recommendation that should be
followed in most cases. If an organization fails to follow a standard, a negative
outcome should occur. If the organization fails to follow a guideline, there is
usually little risk to the outcome. Most organizations allow deviations to
standards only through a formal review and approval process. Usually a
deviation requires some form of a sign–off by a manager that understands the
consequences.
In addition to the system integration standards there are numerous standards for
content interchange. When combined with the hardware, software, messaging,
database, distributed computing, and data and metadata standards, the simple
approach of picking a set of applications and assembling them into a system
may seem hopeless.
System architecture is intimately related to life cycle cost. A well–designed system
represents a valuable investment that yields adaptability to new requirements and
technologies over the system life.
WHAT IS SOFTWARE ARCHITECTURE?
Software architecture is defined as the generation of the plans for information
systems, analogous to the plans for an urban dwelling space. Christopher
Alexander [Alex77], [Alex79] (the inventor of design patterns) observed that
macro–level architecture is made up of many repeated design patterns.
Software architecture is different from software design. Software architecture is
a view of the system as a whole rather than a collection of components
assembled into a system. This holistic view forms the basis of the architecture–
centered approach to information systems. Architecture becomes the planning
process that defines the foundation for the information system.
Distributed object computing and the Internet have fundamentally changed the
traditional assumptions for architecting information systems. The consequences
of these changes are not yet fully understood by the developers as well as
consumers of these systems. The current distributed computing (client/server)
The term architecture is so overused in
the software business, that it has
become a cliché. There are “official”
descriptions of software architecture
and architects. Much of the architecture
work has taken place inside
development organizations and
academia. In this paper, the description
of architecture is taken from a variety of
reliable sources.

and Internet–based systems are complex, vulnerable, and failure–prone. This
complexity is the unavoidable consequence of the demand for ever–increasing
flexibility and adaptability. These rapidly changing technologies require a
different planning mechanism, one based on fundamentally new principles.
Because technology is changing at a rapid pace and user business
requirements are becoming more demanding, the architecting these new
systems is now essential. No longer can systems be simply assembled from
components without consideration of the whole [Foot97].
Architecture is not the creation of boxes, circles, and lines, laid out in
presentation slides [Shaw96], [Shaw96a]. Architecture imposes decisions and
constraints on the process of designing, developing, and deploying information
systems. [Adow95], [Alle94], [Kazm96], [Perr92]. Architecture must define the
parts, the essential external characteristics of each part, and the relationships
between these parts in order to assure a viable outcome.
Architecture is the set of decisions about any system that keeps its implementers and
maintainers from exercising needless creativity.
The architecture of a system consists of the structure(s) of its parts, the nature and
relevant externally visible properties of those parts, and the relationships and
constraints between them [D’Sou99].
ARCHITECTURE BASED INFORMATION TECHNOLOGY STRATEGIES
Much has been written about software and system architecture [Sei00]. But the
question remains, what is architecture and why is it important to the design and
deployment of software applications in the publishing domain?
Publishing systems possess a unique set of requirements, which are
continuously increasing in complexity. In the past, it was acceptable to assemble
a set of application that functioned in a serial manner, making format
transformations across application boundaries, and performing the workflow
processes by hand. In the current publishing environment, the timeliness,
seamless workflow and, multi–purpose nature of content has become a critical
success factor
[4]
in the overall business process.
In the past, publishing information was usually provided through a monolithic set
of applications (standalone applications integrated through file systems on a
network).
[5]
This critical data was trapped inside the applications, which were
originally designed to liberate the workforce from mundane tasks [Bryn98],
[Bryn93]. However, without flexibility and adaptability, the users were forced to
adapt their behaviors to the behaviors of the system. The result was a recurring
non–recoverable cost burden on the organization. What was originally the
responsibility of the software – as defined in the Systems Requirements
Analysis – became the burden of the user [Bryn98], [Schr97], [Bryn96]. In the
publishing environment, this includes multiple and inconsistent data and image
formats, inconsistent or duplicate database contents, islands of information and
automation, and the inability to adapt to the changing needs of the organization.

An effective publishing system architecture must combine content creation,
content management, content publishing, and information systems.
[6]
Most
approaches in the past elected to keep these two systems separate but linked,
adapting them to make intersystem communication transparent.
However, this strategy fails to address the important problem of how to
restructure the publishing operations to meet the demand of future operations.
The complexity of this customization in a just–in–time publishing environment
means that the software components, and the work processes they support, are
in constant flux. For an integrated publishing system to function in this way,
software systems must be continuously expanded, modified, revised, tested,
and repaired. The software components must be integrated quickly and reliably
in response to rapidly changing requirements. Finally, such a system must
cooperate in addressing these changing objectives. All these requirements
define a highly flexible, adaptive architecture capable of operating in rapidly
changing conditions [Mori98].
In order to address these needs, the system architecture must:
n Define the goals of the business in a clear and concise manner, using a notation
that is readable by both humans and machines.
n Identify the Information Technology already in place that meets these goals.
n Identify gaps in the levels of Information Technology that fail to meet these goals.
n Identify the organizational structure needed to support the implementation of the
strategy.
n Define a layered framework for connecting the system components.
INFORMATION MANUFACTURING DOMAIN
With the availability of Commercial Off The Shelf (COTS) publishing
applications, the integration of these best of breed components becomes the
primary strategy for many rapidly developing software markets. The newspaper
automation systems market is an example of this trend. The state–of–the–art
tools for pagination, editorial text creation, digital asset management, database
management, and distributed object technologies are readily available for a
variety of platforms.
Figure 1 is a simplified view of the problem domain. Best of Breed COTS
products are available for each of these problem domains. However, these
components operate in disjointed ways, with proprietary data formats and
processing models.
With the advent of Enterprise
Application Integration, the design and
implementation of integrated systems
is guided by an academically sound
and field proven techniques.

Editorial Pagination
Asset
Management Advertising
Figure 1 – Integrating Diverse
Newspaper Systems Components
INTEGRATING HETEROGENEOUS ENVIRONMENTS
The individual components shown in Figure 1 are typical in a publishing
environment. Each component provides a unique setoff features and functions.
Some components may be assembled from COTS products, some may be
purpose built by the vendor or system integrator. Each may have individual
database schemas, or they may share a central database and the related tables
and schemas.
In this heterogeneous COTS environment:
n Each application domain makes use of a specific implementation paradigm. The
editorial domain assumes documents are kept in a database and indexed using
content–based retrieval of document specific attributes. The Digital Asset
Manager (DAM) stores digital images and graphics, indexing them with
traditional attribute databases. Browser–based clients access content through
URLs or GUIDs. Locating this content first requires a query to a SQL database.
The pagination system provides tools for manipulating pages, but stores the
page image and the entities on the page in a proprietary format, accessible only
through an API. Each application assumes this private paradigm can be
syndicated to other application domains. This assumption is rarely true, since the
semantics of the data and control processes are unique for each application.
[7]
n Each application domain assumes it is independent from other application
domains. This independence includes the flow of control within the domain as
well as the announcement of events and changes in state across the domain
boundaries. This domain independence creates an inversion of control or the
lack of explicit control across these application boundaries.
[8]
This inversion of
control is a fundamental architectural flaw found in tightly coupled integration
architectures, where multiple information producers and consumers are present.
The diversity of publishing system
components creates a unique problem
for the system integration designer.
Assembling a heterogeneous group of
products exposes problems not
normally found in the traditional
product integration environment.
The diverse set of application
paradigms, application programming
interfaces, and inversion of control
issues creates the need for a unique
approach to constructing seamless
product suites with commercial
applications.

n Each application domain makes use of unique file formats and communication
protocols. Pagination systems, editorial systems, asset management systems,
wire services, databases, and CORBA integration components all provide
different file formats and protocols. In some cases, the format of the data is also
unique to the operating system or the underlying database management
system.
[10]
n The event signaling, thread control, exception handling, and other low level
software behaviors are difficult to control – even if the systems are intentionally
designed to be compatible.
[9]
Each application domain assumes a unique
mechanism for controlling the thread of execution. The synchronization of these
execution threads across application boundaries is one of most difficult problems
in the integration of heterogeneous systems.
n Exceptions are reported within each application domain using the semantics of
that application. Simple error codes and user response processes are unique to
each domain. The unification of the exception semantics and the handling of the
exceptions is a difficult task.
[10]
THE IMPEDANCE MISMATCH
In this heterogeneous integration environment, the influence of each domain –
as well as many other intangible influences – creates an impedance mismatch
between the COTS components.
[11]
The challenge for the system architect is to
define a mechanism that integrates the disparate components while maintaining
their unique functionality.
[12]
In addition to the impedance mismatch between the COTS components, these
components are also undergoing continuous change.
[13]
These changes create
a moving target for the seamless integration of heterogeneous systems.
There are only two things we know about the future: 1) it cannot be known, and 2) it
will be different from what exists now and from what we expect. Any attempt to base
today’s actions and commitments on predictions of the future events is futile. But
precisely because the future is going to be different and cannot be predicted, it is
possible to make the unexpected and unpredicted come to pass
— Peter Drucker
The inability to predict the future system requirements of a system as well as the
underlying changes in the system component’s behaviors means that the
integration mechanism of these COTS components must provide sufficient
flexibility to deal with these unknown requirements.
Impedance mismatches are
unavoidable. The role of the UNA is to
“bridge” these mismatches by
normalizing the interfaces between
each application domain.
Forecasting the needs of future
software requirements and integration
problems is “sporty” business at best.
The development of a Framework for
this integration requires careful
consideration to tangible and
intangible aspects of software design.

APPLICATION INTEGRATION OVERVIEW
The tools available for Enterprise Application Integration (EAI) are described in
Figure 2. This simple matrix isolates both the problem domain and the
solutions.
[14]
There are distinctly different problem areas in EAI:
n The purpose of the integration – which can be to update the information in the
integrated systems in order to maintain cross–system consistency, or simply to
read data from one system from another in order to provide a unified view of the
distributed data.
n The level at which EAI can be performed – which can through messages at the
application level or through the exchange of data through a shared database.
Data
Level
TP Monitor
Application Server
Data Federation Systems
Data Warehouse and Data
Marts
Event
Level
Message–Oriented
Middleware (MOM)
Publish and Subscribe
Update
(Cross System
Consistency)
Read
(Unified Views)
Figure 2 – Classification of EAI Options
The facilities available to address the purpose and level of integration can be
portioned into four quadrants.
n TP Monitors and Application Servers allow applications to push data to multiple
data sources while maintaining update consistency.
n Message–Oriented Middleware provides a one–to–one message passing
process between applications. When an event occurs in one system, information
is pushed to another system to ensure consistency.
n Publish and Subscribe systems push messages asynchronously between
applications when events occur.
n Data Federation and Warehousing systems perform integration by moving data
from two or more locations to a third location. Data Federation Systems (DFS)
are pull systems that request data on demand from the underlying systems.
EAI provides a mechanism to connect
heterogeneous systems through
several commercial solutions.

APPLICATION INTEGRATION AND THE PUBLISHING DOMAIN
Depending on the business domain, there advantages and disadvantages to
each purpose and level of integration shown in Figure 2. A publishing system
based on the Enterprise Application Integration (EAI) of Commercial Off The
Shelf (COTS) components must:
[15]
n Provide access to a networked set of heterogeneous information sources,
without relocating the original information or forcing changes to the information
format. This integration must provide open access to the heterogeneous services
of the integrated environment, including business application logic, data format
transparency, event synchronization, error detection and handling, and fault
tolerance.
n Create and manage the meta–data for retrieval of the information. This meta–
data describes the location and other content attributes of the information. The
meta–data repository becomes a clearing house for applications creating,
reading, updating, and deleting information.
n Provide scalable systems without concern for the information’s locality. By
distributing the information and meta–data, the CORBA based system can be
scaled to meet the demands of the publishing process. Multiple information
resources can be added to the system without impacting the existing
components. The underlying CORBA services can be scaled to meet the
demands of the information processing systems.
n Provide neutral programming interfaces between the various services, which
provide state, status, and content manipulation. Using the CORBA IDL interface
specification, programming language independence is established.
n Provide scalable services for each application domain, as well as fault tolerance,
load sharing, configuration management, and distributed operations. These
services are provided through the core components of CORBA.
n Create a separable set of functions for the core architecture. By this, it is meant
that each business domain operates independently of the other application
domains, while forming as an integrated system. This architecture is based on
several important principles
[16]
:
n Producers and consumers of data are separate. Neither producers nor
consumers have knowledge of the internal behavior of other application
domains. This is accomplished by interposing an intermediary persistent data
store between producers and consumers.
n A shared persistent data store provides an abstract interface to the
information needed by producers and consumers. The abstract interface
reduces the data coupling between data producers and data consumers.
n Data producers are publishers and data consumers are subscribers to this
abstract persistent data store. When a producer publishes a piece of data,
all subscribers are notified. The subscribers can then retrieve the data and
use it in a manner appropriate for the application domain. In this way, the
data store is not passive, but tracks the production and consumption of the
data.
The EAI requirements for a publishing
system are different from the
requirements found in business
transaction processing systems.
The diverse sources of information,
the real time aspects of information
content, the heterogeneous data and
control formats all create a unique set
of requirements for the Publishing
Enterprise Application Integration
architecture.

THE INFORMATION MANUFACTURING DOMAIN
The interaction between large grained components (subsystems) and the work
processes that define these interactions is an important consideration in the
design of the meta–system. The creation of a newspaper or other published
information media is similar in many ways to the publishing domain.
[17]
Raw
materials are gathered through a procurement process. These materials are
inventoried and scheduled for assembly. The raw materials or partially finished
goods are assembled into the final product. These products are transported to
the customers or users. Figure 3 describes the partitioning of these domains.
The creation of a seamless integration environment between each participant in
the Information Manufacturing process is the role of the Universal NewsGram
Architecture (UNA).
[18]
Digital
Asset
Manager
Pagination
System
Object
Store
Editorial and
Classified
System
Story
Page
Photo
Content
Management
Reports,
Stringers,
Wire Services,
etc.
Photographers
Paginators
Content
Procurement
Creation of
Content
Assignment of
Content to the
Publication
Content
Assembly
Content
Delivery
Output
Management
Publishing the
Paper to
Specific Media
Figure 3 – Domains of the Information
Manufacturing Process
n Content Procurement – the raw materials of the publishing industry includes new
advertisements, stories, photos, and graphics. These items are captured,
created, and acquired independent from their use. In this domain, the format of
the information varies across the gathering and authoring tools. The primary
attributes of this domain include:
n The format of the arriving information is specified by an external entity.
Some of these specifications are industry standards some are proprietary to
a specific product.
The concept of Information
Manufacturing is derived from hard
goods manufacturing. Raw materials
are manipulated into finished goods,
which are then distributed to
customers.

n The arrival rates of the information cannot be throttled by the Insiight system.
Either the information arrives in a real–time manner from a network or
reporters cover news events occurring in a spontaneous manner creating
heavy demands on the system.
n Content Management – the procured items are managed as raw or semi–
finished goods. Since they are not yet assigned to a publication, the content
management domain can manipulate them without concern to the final output.
The format and semantics of the content are irrelevant to the management of the
content. The applications that make use of the content gain access to the
content through the NewsGram Object Store and the URLs referencing the
content. The primary attributes of this domain include:
n Creation of meta–data descriptions of the content and the storage of this
meta–data in a system neutral location and format.
n Creation of connections between the various content domains that convey
state, status, and location, but not the actual content information.
n The pagination process assembles these raw and semi–finished elements
into a finished product. The NewsGram Object Store is the repository that
holds the connections between these independent components.
n Content Assembly – publishable entities are assigned to a publication. At this
point, the formats and content are targeted to a specific output paradigm. Again,
the format and semantics of the content are related to the application domain.
The UNA manages the state, status, and the relationships between of the
content. The primary attributes of this domain include:
n The construction of the connections and topology of these connections,
independent of the content of the entities.
n A standard event protocol to report status changes to the content that occurs
in the content domain using a standard event protocol. This reporting
process will follow the IFRA standard workflow data schema.
[19]
n Content Delivery – publishable entities are delivered to a specific medium. The
publication process takes the finished goods from the information manufacturing
process and delivers them to the customers in a form and format required. At this
point the format, syntax, and semantics of the content is now used to produce
the product. The primary attributes of this domain include:
n Conversion from the native publishing format to XML, PDF and Postscript for
distribution to the target devices.
n Re–purposing the published output to various devices with different
formatting and content display capabilities.
Each of the material and product manipulation domains imposes specific data
format, data semantics, and workflow process on the individual entities. The role
of the UNA and its infrastructure is to normalize the interfaces between each
domain and remove the impedance mismatch between these domains, but not
necessarily between individual entities produced in these domains.
[20]

CHARACTERISTICS OF OPEN INFORMATION SYSTEMS TECHNOLOGIES
There are several characteristics of publishing systems that are shared by all
systems with good architectural foundations. [Witt94], [Rech97], [Shaw96],
[Garl95]. These properties may appear abstract and not very useful at first.
However, they are measurable attributes of a system that can be used to
evaluate how well the architecture meets the needs of the user community.
n Openness – enables portability and internetworking between components of the
system.
n Integration – incorporates various systems and resources into a whole without
ad–hoc development.
n Flexibility – supports a system evolution, including the existence and continued
operation of legacy systems.
n Modularity – the parts of a system are autonomous but interrelated. This property
forms for the foundation of flexibility.
n Federation – combining systems from different administrative or technical
domains to achieve a single objective.
n Manageability – monitoring, controlling, and managing a system’s resources in
order to support configuration, Quality of Service (QoS), and accounting policies.
n Security – ensures that the system’s facilities and data are protected against
authorized access.
n Transparency – masks from the applications the details of how the system
works.
MOTIVATIONS FOR ARCHITECTURE–CENTERED DESIGN
The application of architecture–centered design to publishing systems makes
several assumptions about the underlying software and its environment:
n Large systems need sound architecture. As the system grows in complexity and
size, the need for a strong architectural foundation grows as well.
n Software architecture deals with abstraction, decomposition and composition,
style, and aesthetics. With complex heterogeneous systems, the management of
the system’s architecture provides the means for controlling this complexity is a
critical success factor for any system deployment.
n Software architecture deals with the design and implementation of systems at
the highest level. Postponing the detailed programming and hardware decisions
until the architectural foundations are laid is a critical success factor in any
system deployment.
The publishing domain creates a unique
set of requirements, not found in other
business information system
environments. By focusing on the non-
functional requirements for publishing
systems, the operational aspects of the
software can be isolated from the
underlying infrastructure. This isolation
provides the means to move the system
forward through its evolutionary
lifecycle, while minimizing the impacts
on the operational aspects of the
business processes.

Architectural Principles
Software architecture is more of an art than a science. This paper does not
attempt to present the subject of software architecture in any depth, since the
literature is rich with software architecture material [Tanu98], [Witt94], [Zach87],
[Shaw96], [Hofm97], [Gunn98], [Sei00]. There are several fundamental
principles however to hold in mind:
n Abstraction / Simplicity – simplicity is the most important architectural quality.
Simplicity is the visible characteristic of a software architecture that has
successfully managed system complexity
n Interoperability – is the ability to change functionality and interpretable data
between two software entities. Interoperability is defined by four enabling
requirements:
[21]
n Communication Channel – the mechanisms used to communicate
between the system components.
n Request Generation Verbs – used in the communication process.
n Data Format Nouns – the syntax used for the nouns.
n Semantics – the intended meaning of the verbs and nouns.
n Extensibility – is the characteristic of architecture that supports unforeseen uses
and adapts to new requirements. Extensibility is a very important property for
long life cycle architectures where changing requirements will be applied to the
system.
Interoperability and extensibility are sometimes conflicting requirements.
Interoperability requires constrained relationships between the software entities,
which provides guarantees of mutual compatibility. A flexible relationship is
necessary for extensibility, which allows the system to be easily extended into
areas of incompatibility.
n Symmetry – is essential for achieving component interchange and
reconfigurability. Symmetry is the practice of using a common interface for a
wide range of software components. It can be realized as a common interface
implemented by all subsystems or as a common base class with specializations
for each subsystem.
n Component Isolation – is the architectural principle that limits the scope of
changes as the system evolves. Component isolation means that a change in
one subsystem will not require a change in another.
n Metadata – is self–descriptive information, which can describe services, and
information. Metadata is essential for reconfigurability. With Metadata, new
services can be added to a system and discovered at runtime.
n Separation of Hierarchies – good software architecture provides a stable basis
for components and system integration. By separating the architecture into
pieces, the stability of the whole may sometimes be enhanced.

Architectural Styles
Architectural style in software is analogous to an architectural style in buildings.
An architectural style defines a family of systems or system components in
terms of their structural organization. An architectural style expresses
components and relationships between these components, with constraints on
their application, their associated composition, and the design rules for their
construction [Perr92], [Shaw96], [Garl93].
Architectural style is determined by:
n The component types that perform some function at runtime (e.g. a data
repository, a process, or a procedure).
n The topological description of these components indicating their runtime
interrelationships (e.g. a repository hosted by a SQL database, processes
running on middleware, and procedures created through user interaction with a
graphic interface).
n The semantic constraints that will restrict the system behavior (e.g. a data
repository is not allowed to change the values stored in it).
n The connectors that mediate communication, coordination, or cooperation
among the components (e.g. protocols, interface standards, and common
libraries).
There are several broad architectural styles in use in modern distributed
systems and several detailed substyles within each broad grouping [Shaw96],
[Abow95].
Because practical systems are not constructed from one style, but from a
mixture of styles, it is important to understand the interrelationship between
styles and their affect on system behavior.
This architectural style analysis [Adow93]:
n Brings out significant differences that affect the suitability of a style for various
tasks, the architect is empowered to make selections that are more informed.
n Shows which styles are variations of others, the architect can be more confident
in choosing appropriate combinations of styles.
n Allows the features used to classify styles to help the designer focus on
important design and integration issues by providing a checklist of topics.

4 + 1 ARCHITECTURE
In many projects, a single diagram is presented to capture the essence of the
system architecture. Looking carefully at the boxes and lines in these diagrams,
the reader is not sure of the meaning of the components. Do the boxes
represent computers? Blocks of executing code? Application interfaces?
Business processes? Or just logical groupings of functionality? [Shaw96a]
One approach to managing architectural style is to partition the architecture into
multiple views based on the work of [Kruc95], [Adow93], [Perr92], [Witt94]. The
4+1 Architecture describes the relationship between the four views of the
architecture and the Use Cases that connect them.
[22]
A view is nothing more
than a projection of the system description, producing a specific perspective on
the system’s components.
Logical
Architecture
Physical
Architecture
Process
Architecture
Development
Architecture
System Usage
Scenarios
End User
Use Cases
Developer / Integrator
Abilities System Engineers
Figure 4 – The 4+1 Architecture as Defined by
[Kruc95]
Figure 4 describes the 4+1 architecture as defined in [Kruc95]. The 4+1
architecture is focused on the development of systems rather than the assembly
of COTS based solutions. The 4+1 paradigm will be further developed during
the ARCHITECTURAL PLANNING phase using the ISO/IEC 10746 guidelines.
There are many architectural paradigms
in the market place. The 4+1 paradigm
is used here to focus the system
architecture of the decomposition of the
architectural components into a COTS
based view of the system.

The system architecture is the structure of a software system. It is described as a set
of software components and the relationships between them. For a complete
description of an architecture several views are needed, each describing a different
set of structured aspects [Hofm97].
For the moment, the 4+1 Architecture provides the following views:
n Logical – the functional requirements of the system as seen by the user.
n Process – the non–functional requirements of the system described as abilities.
n Development – the organization of the software components and the teams that
assemble them.
n Physical – the system’s infrastructure and components that make use of this
infrastructure.
n Scenarios – the Use Cases that describe the sequence of actions between the
system and its environment or between the internal objects involved in a
particular execution of the system.
There are numerous techniques used to describe the architectural views of a
system: algebraic specifications [Wirs90], entity relationship diagrams [Chen76],
automata [Hopc79], class diagrams [Rumb91], message sequence diagrams
[ITU94], data flow diagrams [DeMarc79], as well as many others. In this paper,
the Unified Modeling Language (UML) combines many of these notations and
concepts into a coherent notation and semantics [Booc99], [Fowl97], [D’Sou99].
MOVING FROM 4+1 ARCHITECTURE TO METHODOLOGIES
Now that the various components of system architecture are established, the
development of these four architectural components must be placed within a
specific context. This is the role of an architectural methodology.
In the 4+1 architecture the arrangements of the system components are
described in constructive terms – what are the components made of. The next
step in the process is to introduce a business requirements architecture process.
The business requirements will drive the architecture. Without consideration for
these business requirements the architecture of the system, would be context
free. By introducing the business requirements, the architecture can be made
practical in the context of the business and therefore become it can become
generative.
These business requirements are not the business functions, but rather the
functional and non–functional requirements of a system to support the business
functions.

STRUCTURE MATTERS
From the beginnings of software engineering, structure has been the foundation
of good architecture [Parn72], [Dijk68]. There are some basic tenets that can be
used to guide the architecture–centered deployment [Clem96]:
n Systems can be built in a rapid, cost–effective manner by importing (or
generating) large externally developed components.
n It is possible to predict certain qualities about a system by studying its
architecture, even in the absence of detailed design documents.
n Enterprise–wide systems can be deployed by sharing a common architecture.
Large–scale reuse is possible through architectural level planning.
n The functionality of a system component can be separated from the
component’s interconnection mechanisms. Separating data and process is a
critical success factor for any well architected system
———

REFERENCES
[Abow95] “Formalizing Style to Understand Descriptions of Software
Architecture,” G. Abowd, G. Allen and D. Garland, ACM
Transactions on Software Engineering and Methods, 4(4), pp.
319–164, 1995.
[Adow93] “Using Style to Understand Descriptions of Software Architecture,”
G. Adowd, R. Allen and D. Garlan, ACM Software Engineering
Notes, December, 1993, pp. 9–20.
[Alle94] “Formalizing Architectural Connection,” R. Allen and D. Garlan in
Proceedings of the 16
th
International Conference on Software
Engineering, 1994.
[Alex79] The Timeless Way of Building, C. Alexander, Oxford University
Press, 1979.
[Alex77] A Pattern Language: Towns, Buildings, Construction, C.
Alexander, S. Ishikawa, and M. Silverstein, Oxford University
Press, 1977.
[Bryn98] “Beyond the Productivity Paradox,” E. Brynjolfsson and L. M. Hitt,
Communications of the ACM, 41(8), pp. 49–55, August 1998.
[Bryn93] “The Productivity Paradox of Information Technology,” E.
Brynjolfsson, Communications of the ACM, 36(12), pp. 66-77,
December 1993.
[Chen76] “The Entity Relationship Model – Towards a Unified View of
Data,” P. Chen, ACM Transactions on Database Systems, 1(1),
1976, pp. 9–36.
[Clem96] “Coming Attractions is Software Architecture,” P. C. Clements,
CMU/SEI–96–TR–008, Software Engineering Institute, Carnegie
Mellon University, Pittsburgh, PA, January, 1996.
[DeMarc79] Structured Analysis and System Specification, T. DeMarco,
Prentice Hall, 1979.
[Dijk68] “The Structure of the T.H.E. Multiprogramming System,” E. W.
Dijkstra, Communications of the ACM, 26(1), January, 1968, pp.
49–52.
[Foot97] “Big Ball of Mud,” B. Foote and J. Yoder, University of Illinois at
Urbana–Champaign, September 1997.
[Garl93] “An Introduction to Software Architecture,” D. Garlan and M.
Shaw, Advances in Software Engineering and Knowledge
Engineering, Volume 1, World Scientific, 1993.
[Garl95] “Architectural Mismatch or Why It’s Hard to Build Systems Out of
Existing Parts,” D. Garlan, R. Allen, and J. Ockerbloom,
Proceedings of the Seventh International Conference on Software
Engineering, April 1995.

[Gunn98] “The Architect’s Role in Package Application Integration,” S.
Gunnell, Sun World, August 1998.
[Fowl97] Analysis Patterns: Reusable Object Models, M. Fowler, Addison–
Wesley, 1997.
[Hofm97] “Approaches to Software Architecture,” C. Hofmann, E. Horn, W.
Keller, K. Renzel, and M. Schmidt, in Software Architecture and
Design Patterns in Business Applications, edited by M. Broy, E.
Denert, K. Renzel, and M. Schmidt, Technical University at
Muhchen, TUM–I9746, November, 1997.
[Hopc79] Introduction to Automata Theory, Languages and Computation, J.
E. Hopcroft and J. E. Ullman, Addison Wesley, 1979.
[ITU94] International Telecommunications Union: Message Sequence
Charts, ITU–T, Z.120, 1994.
[Jaco92] Object–Oriented Software Engineering: A Use Case Driven
Approach, I. Jacobson, Addison Wesley, 1992.
[Kazm96] “Classifying Architectural Elements,” R. Kazman, P. Clements, G.
Abowd, and L. Bass, Proceedings of the ACM SIGSOFT
Symposium on the Foundations of Software Engineering, 1996.
[Kruc95] “The 4+1 View Model of Architecture,” P. Kruchten, IEEE
Software, 12(6), pp. 42–50, 1995.
[Mori98] “Applications in Rapidly Changing Environments,” K. Mori, IEEE
Computer, April 1998, Volume 31, Number Four, pp. 42–44.
[Parn72] “On the Criteria to be Used in Decomposing Systems into
Modules,” D. Parnas, Communications of the ACM, Vol. 15, pp.
1053–1058, December 1972.
[Perr92] “Foundations for the Study of Software Architecture,” D. E. Perry
and A. L. Wolf, ACM Software Engineering Notes, October, 1993,
pp. 40–52.
[Rech97] The Art of Systems Architecting, E. Rechtin and M. W. Maier,
CRC Press, 1997.
[Rumb91] Object–Oriented Modeling and Design, J. Rumbaugh, M. Blaka,
W. Permerlaui, F. Eddy, and W. Lorenson, Prentice Hall, 1991.
[Sei98] Continuous Risk Management, Software Engineering Institute,
1998.
[Sei00] “Software Architecture Bibliographies,” Software Engineering
Institute, http://www.sei.cmu.edu/architecture/bibliography.html
[Schr97] “The Real Problem with Computers,” M. Schrage, Harvard
Business Review, 75(5), November/December, 1997, pp. 178–
183.

[Schn98] Applying Use Cases: A Practical Guide, G. Schneider and J. P.
Winters, Addison Wesley, 1998.
[Shaw96] Software Architecture: Perspectives on an Emerging Discipline,
M. Shaw, and D. Garlan, Prentice–Hall, 1996.
[Shaw96a] “A Field Guide to Boxology: Preliminary Classification of
Architectural Styles for Software Systems,” M. Shaw and P.
Clements, Proceedings of the 2
nd
International Software
Architecture Workshop, October 1996.
[D’Sou99] Objects, Components, and Frameworks with UML: The Catalysis
Approach, D. F. D’Souza and AS. C. Wills, Addison Wesley,
1999.
[Tanu98] “Software Architecture in the Business Software Domain: The
Descartes Experience,” M. Tanuan, Proceedings of ISAW3, ACM
1998, pp. 145–148.
[Wirs90] “Algebraic Specifications in Formal Methods and Semantics,”
Handbook of Theoretical Computer Science, M. Wirsing, Elesiver,
1990, pp. 675–788.
[Witt94] Software Architecture and Design Principals, Models, and
Methods, B. I. Witt, F. T. Baker, and E. W. Merritt, Van Nostrand
Reinholt, 1994.
[Zach87] “A Framework for Information Systems Architecture,” J. Zackman,
IBM Systems Journal, 26, Number 3, 1987.

END NOTES
1
Many of these architectural analogies are based on mapping the building
architecture paradigm to the software architecture paradigm. If this were the
actual case software systems would be built on rigid immovable foundations,
with fixed frameworks and inflexible habitats and user requirements. In fact,
software architecture is more analogous to urban planning. The macro level
design of urban spaces is provided by the planner, with infrastructure (utilities,
transportation corridors, and habitat topology) defined before any buildings are
constructed. The actual dwelling spaces are built to broad standards and codes.
The individual buildings are constructed to meet specific needs of their
inhabitants. The urban planner visualizes the city–scape on which the individual
dwellings will be constructed. The dwellings are reusable (remodeling)
structures that are loosely coupled to the urban infrastructure. Using this analog,
dwellings are the reusable components of the city–scape, similar to application
components in the system architecture. In both analogies, the infrastructure
forms the basis of the architectural guidelines. This includes, utilities, building
codes, structural limitations, materials limitations, and local style [Alex79],
[Alex77].
2
In many real life applications, there does not exist a solution to a problem that
satisfies all the constraints. Such systems are called over constrained systems.
An example might be the selection of matching cloths (shirt, shoes, and pants).
There are red and white shirts, cordovan and sneaker shoes, and blue, denim,
and gray pants. If the following matching constraints are used – Shirts and
Pants: {(red, gray), (white, blue, (white, denim)}; Shoes and Pants: {(sneakers,
denims), (cordovans, gray)}; Shirts and Shoes: {(white, cordovans)}, there is no
solution.
3
The concept of integration standards is complex and fraught with
misunderstandings and over simplifications, mostly provided by vendors. One
source of a set of standards guidelines can be found at
www.computer.org/standards/sesc/MasterPlan/index.htm. This include:
§ Architectural standards for software
§ Correlation of product standards to architectural standards.
§ Identification of critical constraints on the system.
§ Precise definitions of all software-software interfaces.
§ Precise definitions of functions and outputs.
§ Precise definitions of all software-hardware interfaces.
§ Domain specific user interface metaphors.
§ Conventions for object-oriented messages.
§ Language bindings that provide integration of the software packages.
§ Process and criteria for preparing software integration estimates.
§ Clear and interoperable relationshipos between hardware and software
standards.
§ An understanding of the copyright and patents.
§ Criteria for assessing quality of the integrated product.
§ Criteria for assessing the reliability of the integrated product.
§ Criteria for assessing the maintainability of the integrated product.
§ Criteria for assessing the usability of the integrated product.
§ Criteria for assessing the functionality of the integrated product.
§ Criteria for assessing the performance of the integrated prod uct.
4
Dr. John Rockhart from MIT's Sloan School of Management is the source of the
concept of Critical Success Factors (CSF). The CSF’s for a business are

associated with its industry, competitive strategy, internal and external
environmental changes, managerial principles, and a CEO perspective.
5
The mainframe environment has been tagged with the monolithic label for some
time. Now that mature client / server applications have been targeted for
replacement, they too have been labeled monolithic. It is not the mainframe
environment that creates the monolithic architecture, it is the application's
architecture itself that results in a monolithic system being deployed. This
behavior occurs when the data used by the application is trapped inside the
code. Separating the data from the application is one of the primary goals of
good software architecture. This separation however, must take into account the
semantics of the data, that is the meaning of the data. This meaning is
described through a meta–data dictionary which is maintained by the architect.
6
At this point, the separation between content management and information
management systems is somewhat artificial. The separation between content
management and information management is defined through the access
facilities of the system. Many systems provide some form of access to the
underlying database. What is not provided is a uniform data model of the both
the semantics and the syntax of this data. This is usually referred to as the
meta–data or meta–model. This architecture is the foundation of an open
standards based integration strategy. Without such a meta approach the
integration process creates an instant legacy system in the same way the
previous generation systems functioned. With a meta–model the system
becomes open and adaptive in a manner that supports adaptation and
integration with other similar systems.
7
“Integrating Islands of Automation,” Michael Stonebraker, eaiJournal, September
/ October 1999. www.eaijournal.com.
8
“Object–Oriented Application Frameworks,” Mohamed E. Fayad and Douglas C.
Schmidt, Communications of the ACM, 40(10), October 1997, pp. 32–38.
9
“Michael Stonebraker on the Importance of Data Integration,” Lee Garber, IEEE
IT Pro, May / June, 1999
10
“Framework Integration: Problems, Causes, Solutions,” Michael Mattsson, Jan
Bosch, and Mohamed E. Fayad, Communications of the ACM, 42(10), October
1999, pp. 81–87.
11
The term impedance mismatch is widely used in the database domain to
describe the mismatch between SQL database technologies and Object
Oriented technologies. This mismatch comes about through the query and
updating processes that are distinctly different in their semantics. In addition, the
concept of architectural mismatch is now well understood and cause of many of
the problems found in the industry. To understand this issue and how it affects
the design of UNA some background materials are available and should be
read by anyone intending the make changes to the UNA. “Detecting
Architectural Mismatches During System Composition,” Cristina Gacek, Center
for Software Engineering, Computer Science Department, University of
Southern California, USC/CSE–97–TR–506, July 8, 1997, “Composing
Heterogeneous Software Architectures,” Ahmed Abd–el–Shaft Abd–Allah, PhD
Thesis, University of Southern California, August 1996 and “Attribute–Based
Architectural Styles,” mark Klein and Rick Kazman, Software Engineering
Institute, CMU/SEI–99–TR–022, October 1999.
12
“Architectural Mismatch, or Why It’s Hard to Build Systems Out Of Existing
Parts,” D. Garlan, R. Allen, and J. Ockerbloom, Proceedings of ICSE ‘95, IEEE
Computer Society Press, April 23–30 1995, pp. 179–185.

13
“Architectural Issues, other Lessons Learned in Component–Based Software
Development,” Will Tracz, Crosstalk, January 2000, pp. 4–8.
www.stsc.hill.af.mil/CrossTalk/index.asp.
14
“Integrating Islands of Information,” Michael Stonebreaker, EAI Journal,
September/October 1999.
15
There are formal integration strategies for other business domains defined by
the Object Management Group (OMG). The publishing business domain has
not been addressed yet by any formal standards body.
16
The importance of an academically sound, field proven architecture cannot be
over emphasized in the commercial market place. Many of the developmental,
operational and maintenance problems in commercial software products can be
traced to poor architecture and poor implementation of architectures. The
Universal NewsGram Architecture is constructed using several sub–
architectures. Each of these architectures is carefully chosen to meet the
requirements of the publishing domain, while providing a clear and concise
means of extending the system into new markets.
The UNA architecture is based on the following foundations. Anyone intending
to extend the UNA or alter the use of the UNA components is cautioned to gain
a full understanding of the motivation and foundation of the architecture by
reading the following as well as all the other references in this paper:
“Attribute Based Architectural Styles,” Mark Klein and Rick Kazman, CMU/SEI–
99–TR–022, Software Engineering Institute, October, 1999.
“A Unified Framework for Coupling Measurement in Object–Oriented Systems,”
L. Briand, J. Daly, and J. Wuest, IEEE Transactions on Software Engineering,
25(1), January/February 1999.
“SAAM: A Method for Analyzing the Properties of Software Architectures,” R.
Kazman, G. Abowd, L. Bass, M. Webb, Proceedings of the 16
th
International
Conference of Software Engineering, May 1994, pp. 81–90.
“Attribute Based Architecture Style,” M. Klein, R. Kazman, L. Bass, S. J.
Carriere, M. Barbacci, and H. Lipson, Software Architecture. Proceedings of the
First Working IFIP Conference on Software Architecture, February 1999, pp.
225–243.
17
This analogy is not far from the truth. The development of just in time
manufacturing control systems is based on the Theory of Constraints, in which
the materials for the finished product are identified, managed, and delivered just
in time for the manufacturing operations to perform their value added
processing. The theory of these manufacturing systems is well understood and
used to reduce cost, improve performance of the capital and labor assets, and
shorten delivery times. No formal theory of newspaper production has been
performed, so this analogy is anecdotal at best. See Manufacturing Planning &
Control Systems 4th Edition, Thomas Vollmann, McGraw Hill, 1997.
18
The detailed process workflow between these components is the subject of
another White Paper, Insiight Theory of Operations. These workflows will not be
described here, but the UNA’s role in this process will be.
19
The IFRATrack specification describes the data schema for tracking the
production status of a newspaper. IFRATrack 2.0 is a specification for the
interchange of status and management information between local and global
production management systems in newspaper production. The key here is the
exchange of information between production management systems. This
assumes that two production management systems exist and that information
can be exchanged between them using IFRATrack. There is the common
misunderstanding that IFRATrack schemas are primarily designed for the

internal representation of status and state information. The UNA and the NOS
provide IFRATrack compliant capabilities. The semantics of the status and state
information maintained in the NOS through the NewsGram matches as close as
possible the IFRATrack specifications found in IFRATrack 2.0, published in
IFRA Special Report 6.21.2. This data schema represents a logical newspaper,
with specific relationships between the departments. In addition, this schema is
print–centric and not extensible to other media.
20
This is a fundamental distinction between an integrated system and a federated
system.
21
The Channel, Verb, Noun, Semantics approach to defining interoperability is a
high level concepts that can be used for nearly any architectural approach to
system design.
22
The Use Case notation has become popular in object oriented design and
development. The Use Case specifies the sequence of actions, including any
variants, that a system can perform, interacting with actors of the system.
[D’Sou99], [Jaco92], [Schn98]. Use Cases provide a functional description of
the system but may not be appropriate for the non–functional requirements
specification. When combined with sequence diagrams, Use Cases an describe
the components of the system and the interactions between these components.
These components include software, users, administrators, databases, and
communication channels.

Architecture centered publishing systems

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Architecture centered publishing systems

Similar a Architecture centered publishing systems (20)

Más de Glen Alleman

Más de Glen Alleman (20)

Último

Último (20)

Architecture centered publishing systems