..

..
..
..
..
SUN MICROSYSTEMS ..
.. W H I T E PA P E R
..
..
.

SUNTONE ARCHITECTURE METHODOLOGY

A 3-DIMENSIONAL APPROACH TO ARCHITECTURAL DESIGN
Key Concepts and Overview
Contents

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
The Sun Approach for Dot-Comming . . . . . . . . . . . . . . . . . . . . . . . . .4
The Need for a Better Architectural Model . . . . . . . . . . . . . . . . . . . .4
The Limitations of Traditional Architecture . . . . . . . . . . . . . . . . . . .5
Services-Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
The New Focus on “Network Services” . . . . . . . . . . . . . . . . . . . . . .6
Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
The Services-Driven Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
The 3–Dimensional Architectural Framework . . . . . . . . . . . . . . . . . .10
Systemic Qualities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Logical Application Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Physical Deployment Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Platform Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
3-Dimensional Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
The SunTone Architecture Methodology . . . . . . . . . . . . . . . . . . . .21
SM

Use Case-Focused . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Architecture-Centric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Iterative and Incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Systemic-Quality-Driven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Patterns-Based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Architecture at the Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
What is architecture? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Architectural Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
The Architectural Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

Sun Microsystems, Inc. 1

 Architectural Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Process, Patterns, and Views—The SunTone
Architecture Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Benefits Summary: 3D Architecture . . . . . . . . . . . . . . . . . . . . . . .34
How Sun Professional Services Can Help . . . . . . . . . . . . . . . . . . . . .35
Dot-Com-Ready Workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Dot-Com Proof-of-Concept Services . . . . . . . . . . . . . . . . . . . . . . .35
Dot-Com Inception Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Dot-Com Architecture Services . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Sun’s Comprehensive Service and Support Capabilities . . . . . . . . . .37
About Sun Microsystems, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

2 SunTone Architecture Methodology

EXECUTIVE SUMMARY

The explosion of the web has fundamentally changed the mission and critical suc-
cess factors facing most corporate IT shops. The “users” are now real, live customers,
and there are tens of thousands or even millions of them. More than ever before, sys-
tem problems can result directly in lost revenue and lost customers. When a system
crashes and the phone rings, it’s not an angry branch manager on the phone—it’s CNN.

Until very recently, the vast majority of IT organizations developed applications

intended for deployment exclusively to their company’s employees. Although quality
has of course always been an important consideration in corporate software
development—nobody’s happy about a buggy release—a huge class of software defects
could be tolerated reasonably well by an enterprise. Periods in excess of months would
often roll by before glacial response times might be addressed through, for instance, a
massive mainframe upgrade. Employees would be given “workarounds” to deal with
various cases of software malfunction.

Corporate IT organizations are being faced with developing applications that are
more scalable, reliable, and secure than ever before, more quickly than ever before, and
with far greater Quality of Service (QoS) than ever before. IT organizations are
confronting huge challenges in retraining staff in Web-based technologies and
implementing the process changes necessary for rapid, successive, bug-free releases to
the web. Perhaps more than any other single factor, application architecture can make
or break a dot-com system. Get the architecture wrong, and a system can ultimately
prove impossible to scale, secure, or rapidly change.

Most of the biggest names on the Internet run on Sun, and many of their systems
have been built with the help of Sun Professional Services. Over the past several years,
Sun Professional Services has amassed a tremendous amount of expertise in building
dot-com applications. We have recently synthesized this learning into a standard process,
SM
the SunTone Architecture Methodology (SunTone AM).

This paper details the key concepts in a 3-dimensional approach to creating dot-com
system architecture. It gives an overview of:

• The 3-Dimensional Framework that analyzes an architecture in terms of the

three primary design dimensions: Application Tiers, Infrastructure Layers, and
Systemic Qualities.

Sun Microsystems, Inc. 3

• The process of developing an architecture through the application of “architec-
tural patterns”.

• How QoS requirements should be used to drive the architecture definition process.

• How these principles are synthesized into the SunTone Architecture Methodology,
which is iterative and incremental, architecture-centric, use-case-focused, systemic-
qualities-driven, and pattern-based.

THE SUN APPROACH FOR DOT-COMMING

Sun's comprehensive approach for dot-comming the enterprise consists of the fol-
lowing primary components:

• SunTone Architecture Methodology—a step-by-step process for creating dot-com

SM

architectures.

• Our architecture reference model—a service driven architectural framework based

on loosely coupled, asynchronous communication.

• Architectural patterns—generic templates for structuring a system to meet rigorous

system level requirements like scalability, securability, and manageability.

• Solution sets—sample implementations of dot-com platforms such as e-tail, eCRM,

eSCM, or Community Portals.

• SI Partners—Consulting organizations certified to deliver the SunTone Architecture

Methodology and particular solution sets.

• ISV Partners—ISV products used to implement a solution set which are built with
Java™2 Platform, Enterprise Edition (J2EE-technology) compliant products, or prod-
ucts with a well-defined roadmap for migrating to J2EE.

This paper discusses the 3-Dimensional Architectural Model that is at the core of the
SunTone Architecture Methodology, and gives an overview of the methodology.

THE NEED FOR A BETTER ARCHITECTURAL MODEL

The dot-com age has fundamentally changed the rules of systems architecture. It has
changed end-user demands for IT services, management expectations for IT
infrastructure, and even the strategic role of the IT department. Legacy system
architectures were simply never envisioned to handle the number of users, the level of
security, and the pace of change required of dot-com systems.

4 SunTone Architecture Methodology

THE LIMITATIONS OF TRADITIONAL ARCHITECTURE
Most enterprise networks—even those designed and deployed recently—were built
to support a relatively small number of internal corporate users at set hours of
operation. The majority of enterprise systems are still accessible only from devices
that physically reside within secure corporate office facilities—the so-called
“enterprise fortress.”

Today’s Web users need access to multiple enterprise services at any time, from
anywhere, using anything—from laptops to PDAs to cell phones and pagers. The sheer
number of clients, the diversity and heterogeneity of these clients, and the service
level expectation of these clients are all expanding exponentially, quickly making the
enterprise fortress model obsolete.

Customer
Order Entry Billing Service Shipping
(Mainframe) (HP server) Inventory (Sun server)
(Sun server) Management
(Oracle)

Dumb Workstation PC + Oracle NC + Web

PC + VB app
Terminal + Motiff Forms Browser

Figure 1—The Silo Problem

At the same time, a history of legacy system evolution, decentralized development,

and lack of platform standardization has led to the “silo problem.” Over the years, com-
panies have deployed multiple systems and networks—each chartered and funded by
a single line of business or division, each with a narrowly focused goal, and each using
different technologies and platforms. As a result, multiple silos or “stovepipes” have
emerged, with little integration and minimal ability to communicate.

These implementations present the information resources of an enterprise in the

form of its organization chart—reflecting internal processes of the company, rather
than the concerns and viewpoints of customers and partners.

Mergers and acquisitions compound the problem, because even enterprise-wide tech-
nology strategies become silos within the combined organization, creating “silos of silos.”

Sun Microsystems, Inc. 5

 Confronted with silo problems, many organizations adopt a strategy of Web-enabling
each silo independently. While achieving the short-term objective of making these
systems available over the Web, the resulting Web presence is fractured and difficult
for customers to navigate. More seriously, this approach makes it extremely difficult to
combine the functionality of various silos and create new value-added services.

Internet

Intranet

Figure 2—Web Silos

For example, a company might separately Web-enable its order entry system and its
inventory system. Although this allows customers to check on product availability and
order products, it does not enable customers to check availability as part of the order
entry process, let alone suggest alternative products as substitutes for those that are
currently out of stock.

The systems architecture needs to support what might best be described as an enter-
prise utility model. Like electricity through a power outlet or water through a faucet,
services need to be provided around the clock from standard access points to any
network device. These services need to bridge the silos to allow for an integrated,
customer-centric presentation of your business.

SERVICES-DRIVEN ARCHITECTURE
THE NEW FOCUS ON “NETWORK SERVICES”
The dot-com age is all about service delivery—anytime/anywhere access to any
needed service with predictable availability, reliability, performance, and security. The
SunTone Architecture Methodology focuses on how to identify, design, and deploy
network services to deliver this quality of service, within the severe time constraints
imposed by the dot-com space.

6 SunTone Architecture Methodology

 Simply put, network services are the delivery vehicles for functionality that can be
accessed over a local or wide area network, delivered at a quality-of-service (QoS) level
that meets business and end-user requirements. Examples range from low-level ser-
vices such as authentication and mail transport to true line-of-business services such
as order entry, customer profile, payment, and inventory management.

The goal of the SunTone AM is to define and deliver network services that provide
the desired functionality with a high level of predictability, so that these services can
be counted on by end users or by other network services.

While the functionality of network services is infinitely variable, all well-designed

network services share a set of common characteristics:

• They are based on well-defined, public interfaces. This enables them to use and be
used by other services and to deliver their functionality across multiple types of
networks and client devices.

• They can be shared and re-used by multiple network services, end users, and net-
work service developers.

• They are coarse-grained, and relatively few in number, providing a coherent and
complete range of functionality through a minimum, manageable set of APIs.

• They are location- and system-independent. In the dot-com age, software is no

longer tied to a specific location. Network services are easily distributable pieces of
code, ready to run on virtually any machine or device. And they can be deployed and
managed in numerous ways: many services on one system, one service per system
on a network, or one service spread over many systems – transparently, and in real-
time, without disturbing other services.

• They provide predictable QoS. These services are built on flexible and scalable
infrastructures which offer specific strategies for QoS enabling the service to
support diverse requestors.

• They can be combined and re-combined to create new services. For example, in an
online book purchase, the merchant may combine a payment authorization service,
a credit card fraud screen service, a delivery address verification service, a directory
service, and an order-entry service. To the end user, it appears as a single network
service--a sales transaction.

• They are easily controllable and manageable across the network, enabling them to
be used in the routine course of business: they can be brokered, billed, administered,
monitored, advertised, or syndicated.

Sun Microsystems, Inc. 7

 Management
Interface

Service Characteristics
• Coarse Grained
• Few in Number
Service • Location Independent
Interface • Predictable QoS
• Can be combined, brokered,
metered, outsourced

Figure 3—Service Characteristics

Implemented properly, each network service can be deployed independently of other

services, meaning that they can be deployed on the most appropriate platform or even
outsourced easily. This approach provides the flexibility for each network service to
tackle its QoS requirements for scalability, uptime, security, and performance in the
ways that are most appropriate. At the same time, it provides enough structure to
allow for planning and to permit the overall architecture to evolve and grow quickly
over time.

DESIGN PRINCIPLES
Although as noted earlier, legacy system architectures are fundamentally unsuited
to the supporting web-based applications, no company has the time or luxury to
re-architect beginning with a clean slate. In practice, an architecture must address the
requirements of integrating existing systems, bridging the legacy environment and all
of its heterogeneous resources to a more flexible dot-com-ready infrastructure.

To meet these challenges, the architecture will need to adhere to several overarching
principles. The dot-com architecture must be:

• hysically distributed: It should be possible to distribute processing across

multiple physical network devices. This maximizes the ability to protect (through
the firewall) discreet processing elements and to meet spikes in demand for services
using horizontal scaling.

8 SunTone Architecture Methodology

• Logically tiered for separation of concerns: Functionality should be partitioned
according to logical function, enabling services to evolve independently of one
another in response to ever-changing requirements. In particular, rapidly changing
presentation logic, specific to a particular delivery channel (such as a browser, a cell
phone, or a voice-response system) and unsuited for reuse across different applica-
tions, needs to be separated from shared business services.

• Services-based, not just code-based: The unit of re-use should emphasize reusable
generic service functionality, be readily available, deployed as components across the
enterprise and capable of being managed and controlled to achieve the needed
quality-of-service (QoS) levels.

• Assembled, not built: Using services as building blocks, systems should be formed
by assembling existing services, not by starting from scratch. Some of the parts may
even be provided by resources from outside of the corporate boundaries. Assembly
should be rapid and efficient, not a costly process of custom integration.

• Implemented in layers: Layering maximizes the independence of processing

components from their underlying platform implementations, providing maximum
flexibility in selecting, tuning, and evolving platforms in response to changes in
demand or technologies.

• Consistently managed and controlled: Services need to participate in a coherent

management and security framework, established as an enterprise-wide facility—as
opposed to implementing these capabilities in the components themselves, result-
ing in a menagerie of mechanisms and interfaces where security and manageability
cannot be guaranteed.

THE SERVICES-DRIVEN NETWORK

The architectural goal in the dot-com age is to build a services-driven network—
achieving integration and enabling rapid development of new Web-based offerings.
Sun’s approach to creating the services-driven network is to add a “services tier”
between client devices and back-end resources. Through this approach, back-end
resource functionality is made available via well-defined, network-callable compo-
nents—the services we have just discussed. These services can make back-end func-
tionality readily available to Web clients, but unlike the silo approach they provide
building blocks for combining simple services into full-featured, value-added services
that themselves become Web-available.

Sun Microsystems, Inc. 9

 Reusable,
Scalable,
Secure
Services

Intranet

Figure 4—Services-Driven Architecture

The services-driven approach establishes a standard across the enterprise that allows
for easy discovery and integration of business services. Creating this architecture
involves standardizing interface technology so that once deployed, services are
available for use by other services without complex message reformatting or protocol
conversions. This standardization allows legacy silos to be easily accessed, integrated
and aggregated, resulting in an enterprise-wide services tier.

THE 3-DIMENSIONAL ARCHITECTURAL FRAMEWORK

The Sun 3-D Architectural Framework is a model that organizes architectural
analysis along three dimensions: tiers, layers, and systemic qualities:

• Tiers: A logical or physical organization of components into an ordered chain of

service providers and consumers. Components within a tier typically consume the
services of those in an “adjacent” provider tier and provide services to one or more
“adjacent” consumer tiers. Within a tier, services are organized together according to
like requirements, e.g. functionality, security, or load distribution.

• Layers: The hardware and software stack that hosts services within a given tier;
physical, network, and software platforms and standard API sets that support the
components which provide a service. Layers, like tiers, represent a well-ordered
relationship across interface-mediated boundaries. While tiers represent processing
chains across components, layers represent container/component relationships in
implementation and deployment of services.

10 SunTone Architecture Methodology

• Systemic Qualities: The strategies, tools, and practices that will deliver the requisite
quality of service (e.g. availability, scalability, security, and manageability) across the
tiers and layers.

This Architectural Framework can be graphically depicted as a cube such as the one
shown in Figure 5.

Tiers—Application Partitioning

c e s t i o n ss ation t
e s our tegra usine esent Clien
R In B Pr

System Level
Strategic Level
Application

Service Level
User Level
Virtual Platform
Upper Platform es
i
Lower Platform au lit
icQ
tem
Hardware Platform Sys
Layers—Hardware/Software Stack
Figure 5—The Sun 3-D Architectural Framework

The key principle embodied in the cube is the recognition of the orthogonal
relationship that exists among tiers, layers, and systemic qualities. Each tier of
application functionality is hosted by a layered hardware/software stack. Systemic
qualities must be pervasive throughout the architecture; each must be addressed for
every layer, and for every tier.

In general, systemic qualities are present “weakest-link” challenges—security is

perhaps the best-known example, but the analogy applies equally to scalability or
reliability. For this reason, an architecture can only be said to provide these qualities
when it can be shown that they are pervasive.

The 3-Dimensional Framework provides a basis for a qualitative and quantitative

description of an architecture that will relate the three dimensions. As described
below, this “Systemic Qualities View” can serve to audit an architecture for its
provision of the critical QoS requirements.

Sun Microsystems, Inc. 11

SYSTEMIC QUALITIES
A new emphasis on Quality of Service (QoS) has emerged as Internet/E-commerce
services and applications have become larger and larger, and have become critical to
business operations. Achieving effective QoS requires integrating the development of
these capabilities into the design process of large-scale high-performance architec-
tures. This integration effort includes a process of specifying, designing and
implementing individual QoS, integrating the approaches for individual QoS into a
comprehensive strategy for monitoring and adapting the design for these capabilities
over time.

In many cases, such as availability, the phrase Quality of Service is synonymous with
the term “systemic qualities”, or what we might endearingly call the “ilities” (reliability,
availability, securability, reliability, etc.). However, some of the capabilities referred to,
such as flexibility, have not traditionally been included in discussions of QoS. We use
the term “systemic qualities” to apply to all of these system characteristics.

For the Internet, the focus of Quality of Service is different than the host-based and
client-server models of the past. For these new e-commerce systems the focus is on
real-time continuous processing for mission critical applications, not on a mainframe
model with programmed downtime and a batch-processing model. These new systems
are distributed heterogeneous environments that require a different perspective on
QoS. In some ways the challenge is more complex, on the other hand, if these archi-
tectures are properly designed from the beginning, this can contribute to, and not
challenge, QoS achievement.

Specific examples of Systemic Qualities include:

• Performance—relates both to the specific performance metrics (e.g., responsiveness,

latency) and to the users’ expectations about performance.

• Reliability—related to the reliability of the underlying individual components in

servers. System reliability describes the likelihood of any component failures.

• Availability—essentially the percentage of time that the system is available for use.
Total availability is also impacted by factors beyond the architecture such as latency
within a user’s ISP or the general Internet.

• Scalability—Scalability relates to the ability of an e-commerce site to add capacity

and thus add users over time. Scalability will usually require the addition of
resources, but scalability should not require changes in the architecture, redesign or
loss of service due to the time required to scale.

• Security—includes the levels of authentication supported, the granularity of autho-

rization controls, the mechanisms for provided audibility and the techniques utilized
to ensure the integrity of resources, and the resistance to unauthorized access.

12 SunTone Architecture Methodology

• Manageability—Manageability can be expressed in terms of how easy it is to mon-
itor a system and detect operational characteristics related to performance and fail-
ures, how easy is to configure systems, the processes used for effecting this control
and the degree to which the system can be managed remotely.

• Accessibility—relates to the usability of applications across the full range of user

capabilities, languages, and devices.

• Flexibility—Flexibility relates to how easy is it to re-purpose the system to provide

different services. In flexible systems the individual components can be reorganized
to provide new services and used by different services.

• Other qualities—The list of capabilities is potentially inexhaustible. Other examples

include:

• Serviceability—how easy is it to repair the system and replace components, and to

what degree maintenance causes service interruption

• Interoperability—the capability of components to work with each other and the

ability to add new components

• Portability—the ability to move components from one environment to another or

replace platform components

• Reusability—the ability to use individual components or services in the building

of additional applications

• Usability—involves issues that make the user interface an application functional-

ity that is easy to use by the end user.

These Systemic Qualities are required at each tier of a dot-com architecture and are
not the responsibility of any given layer—instead the layers must complement and
cooperate in providing each quality within a given tier. Some qualities, such as secu-
rity or manageability, need to be pervasive—present at all layers in all tiers.

For this reason, the Sun 3-D Architectural Model represents these Systemic Qualities
as a separate dimension, orthogonal to the tiers and layers which represent the logi-
cal/distributed partitioning and the platform layering. Viewing Systemic Qualities
(and the related QoS levels which need to be supported) in this way is one of the key
insights of the SunTone Architecture Methodology, and allows architectural
alternatives to be quantitatively and qualitatively evaluated for their ability to provide
these capabilities.

Sun Microsystems, Inc. 13

 To focus requirements gathering, guide integration of systemic qualities in design
and implementation, and drive ongoing management and improvement of QoS, it is
useful to categorize individual qualities in terms of the group that the quality impacts
most directly, the nature of the impact, and the time horizon within which the
qualities are manifested.

User-level qualities are those, such as usability and accessibility, that directly affect
the user interface and end-user functionality, are felt at run-time, and are controlled
in the design phase.

Service-level qualities are those, such as performance and availability, that directly
affect business functions of end-users, are felt at run time, and are controlled by
system management.

Strategic-level qualities are those, such as scalability and flexibility, that affect
the enterprise itself, are manifest over time, and are controlled primarily through
architecture. Of course, failures in scalability will result in failures in performance and
availability, which will be felt directly by the end user.

System-level qualities affect peripheral services and functions, such as manageability

and security, rather than business functionality. They are characteristics of the system
implementation, and often act as constraints to the implementation of other qualities
and are controlled by the operations staff.

Naturally, which category a particular quality falls in is relative to the business goals
and design of the systems. While security might be a system-level quality for most
applications, it may be a service-level quality for a company that is selling security
oriented services. The key to the use of these categories is not what category the
quality is in generally, but how each quality is experienced by what constituency and
how it is designed or controlled.

14 SunTone Architecture Methodology

TIERS

Logical Application Tiers

The Internet provides the infrastructure necessary for any number of vastly different
access devices to gain access to enterprise resources. The implementation of resources
does not remain static but changes in response to advances in technology as well as
partnering and outsourcing relationships. By separating processing into discreet
presentation, business, and integration tiers, an enterprise can take advantage of new
delivery channels regardless of the associated access technology, and can remain
independent of back-end resource implementations. This approach allows user inter-
faces, business processing and rules, and back-end resource implementations to evolve
separately as business requirements and technologies change.

Partitioning the services layer into separate tiers allows business logic to remain
independent of access channels and resource implementations, thereby allowing the
enterprise to couple business service processing with any number of different access
methods and back-end resource technologies.

For these reasons, Sun recommends a five-tier model that includes the following tiers:

• Clients: Any client device or system that manages display and local interaction
processing. Enterprises may not have control over the technologies available on the
client platform, an important consideration in tier structuring. For this reason state
at the client tier should be transient and disposable.

• resentation services: These services aggregate and personalize content and

services into channel-specific user interfaces. This entails the assembly of content,
formatting, conversions, and content transformations—anything that has to do with
the presentation of information to end users or external systems. These services
manage channel-specific user sessions and translate inbound application requests
into calls to the appropriate business services.

• Business services: These services execute business logic and manage transactions.
Examples range from low-level services such as authentication and mail transport
to true line-of-business services such as order entry, customer profile, payment, and
inventory management.

• Integration services: These services abstract and provide access to external

resources. Due to the varied and external nature of these resources, this tier often
employs loosely coupled paradigms such as queuing, publish/subscribe communi-
cations, and synchronous and asynchronous point-to-point messaging. Upper-plat-
form components in this tier are typically called “middleware.”

Sun Microsystems, Inc. 15

• Resources: This tier includes legacy systems, databases, external data feeds, special-
ized hardware devices such as telco switches or factory automation, and so on. These
are information sources, sinks, or stores that may be internal or external to the sys-
tem. The resource tier is accessed and abstracted by the integration tier.

Physical Deployment Tiers

In order to achieve certain system qualities, typically expressed as QoS levels, pro-
cessing in complex systems is commonly partitioned across network segments, CPU
clusters, and storage complexes. This partitioning segregates the system’s deployment
architecture into tiers within which common strategies are implemented for QoS
qualities such as security, scalability, load distribution, high availability, etc.

Since QoS levels are typically qualities associated with services, there is often, but
not always, a correspondence between logical tiers and physical tiers. Thus it is
common to see physical tiering associated with the logical Presentation, Business, and
Integration tiers.

In Internet-enabled systems, control and security borders between clients and

presentation services or resources and integration services require additional physical
tiering which has little relationship to logical partitioning. An example of this would
be a “Gateway” tier of firewalls and web servers, providing protocol translation and
perimeter security, but no application logic per se.

PLATFORM LAYERING
Implementing the various tiers of an application requires a combination of traditional
and specialized hardware, software, and networking technologies. Rapid development
and enhancement of a service-driven network requires creating a flexible underlying
platform environment that can be readily adapted to changing business conditions and
evolving technologies. Today the application itself is built upon an underlying platform
that can be divided into three primary layers:

• The upper platform layer consists of products such as Web servers, application
servers, and various types of middleware.

• The lower platform layer is comprised of the operating system environment and
associated low-level systems services.

• The hardware platform layer includes computing hardware such as servers, storage
hardware such as storage arrays, and networking hardware such as switches and
routers, and associated peripherals.

Service tier processing is new to many programmers. It requires the development of

network-callable presentation, business and integration services that:

16 SunTone Architecture Methodology

• Support large numbers of simultaneous users

• Incorporate mechanisms for security, caching, load balancing, and failover

• Render user interfaces across a wide range of access devices

• Integrate back-end resources through a variety of synchronous and asynchronous

communication protocols

• Manage system resources such as memory, network connections, and threads

efficiently through a lifecycle of many invocations on many objects

New classes of systems software have rapidly evolved over the last several years to
support these complex requirements. Web servers, application servers, and message-
oriented middleware products provide most of these processing requirements, allowing
developers to focus more on the business aspects of Web-based application development.
Many of these products can combine to provide a complete service-hosting environment
that is completely independent of the underlying hardware and operating system
environment. Today it is these products, not the underlying hardware and OS, that pre-
sent the “platform” visible to and needed for application development and deployment.

Together, these system software products constitute what the 3-Dimensional

Framework calls the “upper platform”. The emergence of the upper platform is a key
enabler and distinguishing feature of dot-com architectures.

Many upper platform products are available today on a wide variety of lower plat-
form products. Applications written to run on these products can be deployed on a
hardware platform and remain isolated from future hardware or operating system
changes. Although an application might maintain independence from the underlying
lower platform, it can often become dependent instead on the upper platform soft-
ware. Since the upper platform software product space today is changing rapidly, appli-
cations need to maintain upper platform independence.

This requirement gives rise to the notion of a “virtual platform layer,” which provides
an application with standard APIs and specifications for the upper platform. By writing
applications so that they depend only on the virtual platform APIs, developers can
make applications portable across upper platform products.

To put it simply, if you choose your APIs wisely at the virtual platform layer, the
payoff is platform independence across the lower layers.

The promise and delivery of such virtual platforms is an old story: it is the story of
standards-based computing. FORTRAN, the C library, the X Windows System, and POSIX
are all examples of successful virtual platform APIs. Historically, these virtual

Sun Microsystems, Inc. 17

platforms have wrapped the “lower platform” thinly, without significantly raising the
level of abstraction. Today, virtual platforms are available that provide much more
comprehensive and high-level abstractions and directly support the model outlined in
this paper. The two leading virtual platforms for dot-com implementations are Java 2
Enterprise Edition (J2EE) and CORBA.

3-DIMENSIONAL EXAMPLE
Consider an extremely simplistic example in which a retail catalog firm wants to be
able to take orders over the Internet, initially via HTML forms from desktop browsers,
and from other device types in the future. A legacy order entry system is currently
used by their call center operators to enter customer orders received over the tele-
phone, and this system will be used as the back-end for a new web-based, customer
self-service system. A packaged solution is being considered as a replacement for the
legacy system. It has been determined that the best way to communicate with the
legacy system is via message queues.

The sample application platform architecture is depicted below.

Order Legacy
Order Form Order System Order
Form Handler Service Interface System
N

N
IO

E
IO
S

C
S
T
T

R
T
TA

E
N

U
IN
E

R
N

O
LI

G
E

S
U
C

E
S

E
T

n
B
E

R
IN
R

io
P

at
liz
l le
ra
Pa
Virtual HTML JSP EJB JMS APPO
g
in
ue
Q
g
rin
Upper Any Browser iES iAS MQ Series CICS te
us
Cl
b in
Ro
u nd g
Ro a lin
Lower Any OS Solaris Solaris Solaris MVS l Sc
ta
on
o riz
H gy
te
ra
St
Hardware Any HW E450 E5500 E250 ES9000 g
a lin
Sc

Figure 6—Simple Order-Entry Example related to the 3DF

18 SunTone Architecture Methodology

 The target application tiering can be described as followed:

Client Tier—An order entry form that accepts order information from a customer
and returns whether or not the order is accepted. This is “served” from the presentation
tier as HTML—there is no persistent code deployed to the client device.

resentation Tier—An order form handler that forwards to an order processing ser-
vice the order entry data received from the form. Device-specific order form handlers
will be developed to deal with formatting and dialog interaction differences among
various access devices.

Business Tier—An order service that provides such processing as calculating the
tax and shipping costs associated with the order, and forwards the resulting informa-
tion on to the legacy order processing system.

Integration Tier—An order system interface that provides an abstraction of the

back-end order processing system, and will insulate the web-based system from the
impact of replacing the current legacy system with a new, packaged solution.

Resource Tier—The legacy order system itself.

These tiers will be implemented on a layered platform as follows:

Virtual latform—Java2 Enterprise Edition is selected for the virtual platform.

JavaServer Pages™ (JSP™) will be used for the HTML formatting and generation, servlets
provide the input handling required for the Order Form, the Order Service will be imple-
mented as Enterprise JavaBeans™ (EJB™) architecture, the Order System Interface will be
implemented using the Java Messaging Service (JMS). The Legacy Order System receives
orders via an APPC/LU6.2 interface. The virtual platform for the client tier is the HTML 2.0
specification.

Upper latform—iPlanet™ Enterprise Server (iES) is selected as the “container” for

the JSP pages, and iPlanet Application Server (iAS) is selected as the EJB container.
MQSeries is selected as the underlying implementation for JMS. The Legacy System
runs in a CICS environment. Any HTML 2.0-compliant browser can provide the upper
platform for the Client Tier.

Lower latform—It is decided that iES, iAS, and MQSeries will be run on the Solaris™
Operating Environment. The Legacy Order Processing system runs on MVS. The client-
side of the application is independent of operating system.

Hardware latform—Various classes of Sun Enterprise™ Servers are selected to host

the iPlanet and MQ servers. The legacy application is hosted on an ES9000 mainframe.
The client application is hardware-independent.

Sun Microsystems, Inc. 19

 The systemic qualities must be addressed within each tier, and at each layer. For this
example, we will first consider scalability. A horizontal scaling strategy is selected in
which requests will be distributed among multiple web servers, application servers,
and queues. Load will be distributed among the presentation tier web servers via
round-robin DNS. Native iPAS clustering will be used to distribute traffic among the
application servers. Each application server will be assigned its own MQ to avoid bot-
tlenecks in the integration tier. The choice to use queuing is itself a resource tier scal-
ability strategy since it allows the system to scale beyond the throughput capacity of
the Legacy Order System.

As an example of how layers need to cooperate within a tier to achieve a particular

systemic quality, consider a strategy that provides reliability by a “soft-clustering”
failover capability that is a feature of the iPlanet application server, in the upper
platform layer of the business tier. The architectural implications of this solution extend
into the application layer in that application components need to identify to their
platform which information is needed for failure recovery—full replication of all appli-
cation state would seriously degrade performance and increase resource usage. For this
capability to operate efficiently, the lower platform layers must provide high-speed inter-
connection between application server instances to support replication of the failover
state. Tradeoffs between such a strategy for reliability and other strategies for scalability
(e.g. session affinity vs. request-dispatch load balancing) will need consideration as well.

20 SunTone Architecture Methodology

THE SUNTONE ARCHITECTURE METHODOLOGY
SM

The SunTone AM builds on the ideas comprising the Unified Process. Like the Unified
Process, the SunTone AM is use-case-focused, architecture-centric, as well as iterative
and incremental. The SunTone AM significantly extends the Unified Process through
the incorporation of two additional fundamental concepts: it is systemic-qualities-driven,
and patterns-based. The SunTone AM refines the Unified Process notion of architectural
views to better reflect the extremely complex platform environments required for
dot-com applications.

USE CASE-FOCUSED
Use cases are functional scenarios that describe the complete flow of an operation
from the perspective of an actor. Actors are entities that are external to the system,
typically users or other systems. Examples of use cases are scenarios such as
“Customer browses on-line catalog”, or “Sales Representative enters order”.

In non-use-case-focused, strictly component-based approaches, components are

factored from an analysis and decomposition of the required functionality, and the
detailed design and development is typically performed within the context of creating
a complete component. A complete component, however, may not automatically be a
completely useful component, if its development was largely removed from the actual
context of end-to-end system functionality. An ongoing risk in developing components
is the production of extremely sophisticated components that include functionality
not required by the current application, or that ultimately do not integrate well with
the rest of the system.

In use-case-driven design and development, every attempt is made to prioritize

design and development around the realization of complete, end-to-end use cases. The
advantage of this approach is that it keeps the project team focused around continually
delivering functionality directly related to the end product being developed.
It helps avoid undue emphasis being placed on intermediate results at the expense of
end results, and provides a natural framework for an iterative, incremental process.

ARCHITECTURE-CENTRIC
In an architecture-centric approach, architecture is defined and validated before the
development teams begin the bulk of implementing the system design. This is
generally accomplished by building a prototype that exercises all of the unproven,
architecturally significant aspects of a system prior to the start of detailed design and
large-scale development. The architectural prototype focuses on such things as bench-
marking the performance of a volume of representative transactions, testing the
compatibility of various technologies, or certifying the smooth operation of a failure
recovery mechanism.

Sun Microsystems, Inc. 21

 A major benefit of this approach is the identification and elimination of fundamental
technical issues, which if left undiscovered or unaddressed, can pervade huge portions
of a system and entail large-scale re-engineering to fix late in the development cycle.
If instead designers and developers adhere to the mechanisms, technology, and overall
structure validated at the very beginning of the project, the risk of such large-scale
errors is largely mitigated.

ITERATIVE AND INCREMENTAL

Traditionally, design and development has been executed as a waterfall process
in which requirements are defined, then the requirements are decomposed into system
components, then the components are implemented and unit-tested by various indi-
viduals or teams, and finally everything is integration-tested in one final “big bang”. The
problem with this approach is that huge problems in the design or implementation of
the system can go undetected until all of the components are integrated, which is
generally shortly before the system is due to be delivered.

Use Case Use Case

Component 1, 2 3, 4 . . .
Legacy Integration Package Use Case Legacy Integration Package

System User Interface Package Application Use User Interface Package

Components Integration Case
Business Objects Package Business Objects Package
Persistence Package Persistence Package

Design It Build It Test It

Application
Integration

Figure 7—Iterative vs. Waterfall implementation approaches

As mentioned above, with a use-case-focused approach, design and development is

organized around use cases, not components. Although still component-based,
development is executed as a series of iterations, each of which consists of the
developing and integration-testing of complete use cases. In this way, integration
testing occurs early and often and throughout the development cycle, allowing the
early detection and correction of requirements, design, technology, or usability issues.
System functionality is delivered incrementally in a series of intermediate well-tested
releases, each of which builds upon the functionality delivered previously. The system
thus evolves in a series of functional releases, each of which adds to the overall
functionality, and builds on a solid foundation that has been fully tested by each prior
release. There is no “big bang”, only a series of manageable integration tests.

22 SunTone Architecture Methodology

SYSTEMIC-QUALITY-DRIVEN
How can you tell a great architecture from a good one, or a good one from a shaky
one? Since the same functionality can be delivered by a single, massive, undocu-
mented Perl/CGI script or a partitioned, object-oriented, multi-tier system, the answer
cannot lie merely in looking at functional test results. Instead, the real key to making
the right architectural decisions lies in an understanding of the business value of
non-functional systemic qualities and an evaluation of the architecture in terms of its
ability to provide them.

The SunTone AM considers systemic qualities like those discussed above (e.g. security,
manageability, scalability, availability) to be architectural considerations on a par with,
and orthogonal to, the application-level partitioning and platform layering which are
traditional concerns. In fact, these considerations are the primary focus of the architec-
tural process. This focus distinguishes architecture from design, which is concerned
primarily with the specific functionality to be provided by individual components.

The SunTone AM therefore views dot-com architecture as primarily an iterative

process of refining a set of decomposition and platform decisions based on an analysis
of their ability to provide the required QoS levels across these systemic qualities.
Revising or enhancing an architecture to reflect an analysis of its capabilities in terms
of these qualities is the essential activity of the system architect. In this very real
sense, these Systemic Qualities drive the architecture decisions and result in an archi-
tecture that is demonstrably better than alternatives.

For this reason, the SunTone AM also places a critical emphasis on identifying, ranking,
and quantifying these systemic qualities as requirements. Not all systems need all these
qualities, and some systems need more of one than another does. An advertising-sup-
ported portal may have low need for authentication-based security, but high need for
scalability; a high-net-worth private financial services system may have the reverse.
Different architectural choices will be appropriate for each context, and thus each
needs to be architected with an understanding of the business value of the specific
qualities.

PATTERNS-BASED
“ atterns” as used in the SunTone AM means “a solution to a problem in a
context”—patterns are a distillation of experience in solving problems. It is a rare
context and problem that has not been observed and addressed at some level in the
past. Patterns are a formalized way of generalizing and documenting these solutions
to recurring problems.

Sun Microsystems, Inc. 23

 The SunTone AM employs a catalog of architectural patterns, not only for software
but also for all layers of the system, which describe architectural approaches to provide
specific systemic qualities. The logical and physical tiering embodied in the 3-D
Architectural Framework is an architectural style that employs architectural patterns,
to address the problems of flexibility, scalability, security, and manageability in the
context of large, complex dot-com systems.

In the systemic-qualities-driven iterative approach described in the preceding

section, refinement of the architecture is typically accomplished by identifying and
applying an architectural pattern which addresses the problem of a gap in the service
level for a given systemic quality. Where a pattern cannot completely address the
issues, and an innovation is created, this in turn can form the basis of a pattern that
can be added to the catalog.

ARCHITECTURE AT THE CENTER

What is architecture?

The terms “system architecture” and “system design” are often used interchangeably,
but in fact deal with two very different system engineering processes. System archi-
tecture focuses primarily on the overall structure of a system, identifying major com-
ponents and their relationships. The systems architect seeks to define:

• how the overall processing should be decomposed into component parts

• how the major components should be organized with respect to one another

• and the mechanisms underlying shared system-wide operations such as

communication and storage.

Thus, the architect focuses on issues such as which components belong together or
apart; which ones should be visible to one another; which should be replicated; how
they should be distributed; how they should talk to one another; where they should be
stored; and so on.

The vast majority of what drives decisions with respect to overall system organization,
decomposition, and mechanization are the system’s target service level requirements.
Considerations such as how fast the system must be, or how frequently a component
will change are the primary factors in making decisions about architecture. The detailed
functional requirements only play a minor role in the architecture analysis process. (See
table next page).

24 SunTone Architecture Methodology

 Architecture Is Not about... Architecture Is about...

What happens when a button is pushed?
How often the button is pushed, how many
users are simultaneously pushing the button,
where the users physically are (e.g. inside the
intranet, out on the Internet, etc.) when they
push the button.

How the system should respond to an event. The timing constraints, if any, between events.

Which bits of information should be supplied What kinds of constraints should be placed
in response to an event. on which kind of data, based on which user
characteristics.

What are the business rules?
How complex are the rules? How often are
they changed? Can they be changed by
programmers or by users themselves? Will
they be implemented by a single individual,
or by separate teams? Do they change
together or independently?

What is the database schema? How complex is the schema, are there any
pre-existing constraints around it? (E.g. pre-
defined DB.)

What are the fields of the messages? What are the external systems that could be
or must be interacted with, and what are
their characteristics?

A system’s design is constrained by its architecture. In other words, the system

architect establishes the “big rules” that must be followed by the system designers
(who in turn determine how the desired functionality should be realized by the
system implementers). The process of architecture ends and the process of design
begins when enough big rules have been established to ensure that as long as a design
complies with the big rules, it will satisfy the system’s service level requirements.

Sun Microsystems, Inc. 25

 Tiers Tiers

Layers
Unconstrained Tiered Tiered and Layered

Figure 8—Architecture constrains Design

Architectural Patterns

In defining an architecture, the system architect considers and applies structuring

principles that satisfy some set of service level requirements. These structuring
principles often take the form of recognized design patterns, which can be applied to
meet specific service level requirements. For example, various load distribution patterns,
such as round robin, least-loaded-, or session-affinity-dispatch, can be used
to meet scalability requirements. As another example, replication patterns such as
mirroring, store-and-forward, or 2-phase commit can be used to achieve high-availability.

26 SunTone Architecture Methodology

 TRANSACTION

REQUEST
DISPATCHER TRANSACTION

REQUEST MIRRORED
HANDLERS RESOURCES

LOAD BALANCING REPLICATION

Figure 9—Architectural Pattern Examples

Many design patterns are applicable within each of several layers of the implementation
stack. Replication, for example, can be applied at the application layer, via 2-phase
commit logic, in the upper platform, via native database replication, or at the hardware
layer, via RAID.

Sun Microsystems, Inc. 27

 Application • Fine granularity
2 phase commit • Highest reliability
• Holds under failure
• Program each app

Messaging • Fine granularity

• User independent
• N-way

Database • Table level

replication • Applies field validation

Disk level copy • Coarse granularity

• Replicates corruption

Figure 10—Patterns by Layer

Similarly, many design patterns are applicable within or across multiple tiers. Load
distribution, for example, can be applied in the Presentation Tier, via dispatching
requests to one of several web servers, in the Business Tier, by dispatching a request to
one of several application servers, and in the resources Tier, by dispatching to one of
several database segments.

28 SunTone Architecture Methodology

 • Client application
— Built-in retry

• Internet Cloud
— Cisco Global Director

• Switching Fabric
— Alteon

• Web Front End

— Resonate Dispatch

• Application Server
— iPlanet server

• Messaging
— Tuxedo Messaging

• Database Resiliency
— Oracle SQLNet redirection

• Server Infrastructure
— SunCluster

Figure 11—Patterns by Tier

The Architectural Process

The architecture definition process consists largely of the selection of design

patterns and their application to various structural elements of a system in order to
meet a set of service level requirements. The process begins with the selection of an
initial broad pattern, referred to as the Architectural Style. The selection of this initial
pattern is based on previous experience or simple heuristics applied with respect to
the type of application to be developed. The 3-Dimensional Framework discussed
earlier in this paper, with its tiers and layers, is an example of an architectural style
with fairly universal applicability to “dot-com applications”, i.e., applications with a
huge number of users, accessible by a variety of channels over a public network.

Once an architectural style has been selected, it is useful to make initial assump-
tions about how the layers and tiers should be provisioned with system components
and services. These assumptions are typically based on experience-based implementa-
tion preferences for things like technologies and programming models, and a high-
level consideration of the Systemic Quality requirements. For example, an
organization that has standardized on the J2EE technology platform model would
likely make an initial assumption that J2EE would be included within the Virtual
Platform. Similarly, if the project developers have experience with a specific EJB tech-
nology-based server implementation, it would make sense to initially assume the pres-
ence of that EJB Server in the Upper Platform.

Sun Microsystems, Inc. 29

 Having completed making the initial set of provisioning assumptions, the architect
then begins an iterative process of analyzing service level requirements, selecting pat-
terns addressing those requirements, and applying those patterns by restructuring the
components comprising the various tiers and layers of the evolving architectural
model. This process of analyzing, applying, and restructuring continues until all ser-
vice level requirements have been satisfied.

R
E INCEPTION ELABORATION
Q
U OUTLINE ESABLISH REFINE BASE
I CONTEXT PLATFORM ARCHITECTURE PLAN
R
COMPLEXITY ANALYSIS
E CONTEXT PROBLEM CAPABILITY
M ANALYSIS ANALYSIS ANALYSIS
ANALYZE

E Base Platform App

N
T
S
ARCHITECTURAL TARGET STRATEGY GRANULARITY
APPLY
STYLE PLATFORM SELECTION SELECTION

no yes RESTRUCTURE

DEFINE OUTLINE RISKS UNDER WORK

RESTRUCTURE
CONTEXT ARCHITECTURE CONTROL? PARTITON Architecture
Baselined

Figure 12—Outline of the Architectural Process

Architectural Views

Views as communication of an architecture

In the Architectural Workflow defined in the SunTone Architecture Methodology, the

systems architect creates a series of architectural views, each of which details the
overall structure of the system from a different perspective. Architectural views are
conceptually similar to all of the various views that make up the blueprints for a
building, some of which highlight the actual layout, supporting walls, and materials,
and others of which highlight the plumbing and electrical systems.

Thus, a high-level architecture statement provides the big-picture view of the key
objectives and components of the architecture. It includes a functional decomposition
of the primary business entities as well as the supporting mechanisms required to
provide the specified functionality while achieving the desired system qualities.

30 SunTone Architecture Methodology

Several views, distinguished largely by the perspective of several stakeholders, are
often required to specify all facets of an architecture depending on its complexity.
Each view serves a different set of stakeholders with different concerns, interests, and
technical capabilities. Collectively the views represent the primary content of the
System Architecture Document.

The definitions of layers in the 3–Dimensional Framework, and the interfaces

between them, have co-evolved in modern computing culture with a set of disciplines
that manage the complexity within each layer. Thus an IT organization may have
different groups which focus on providing and managing platforms at the hardware,
network, OS, upper-platform, and application layers—indeed, some of these layers may
be outsourced entirely.

For this reason, the layers frequently provide a useful framework for views that
address the needs of different groups of stakeholders among those responsible for
creating, deploying, managing, and evolving the system. The SunTone AM categorizes
its views by layers. Layers reflect the primary distinguishing factor among skill sets
within and across the development team. Additionally, layers reflect different oppor-
tunities to incorporate components and COTS from multiple sources. Within each
layer, views can describe different aspects of the architecture such as:

• Software and hardware configurations of architecturally significant components at

different levels of detail

• Descriptions of representative dynamic interactions fulfilling targeted functionality

or systemic qualities

• Incorporated and custom mechanisms such as persistence, inter-process communi-

cation, and transaction management

• Evolutionary considerations

Within views, various types of models are used to effectively communicate structure
and purpose. This includes the use of the Unified Modeling Language (UML) and
extensions, as well as summarizations that help to ensure that systemic qualities are
being focused on at all levels. For example, a matrix format can highlight the approach
to systemic qualities across different layers. In this format, the rows represent the sys-
tem layers, and the columns represent the systemic qualities relevant to this system.
Each cell describes a feature, strategy, product, practice, or some combination thereof
employed at that layer to support the specified systemic quality:

Sun Microsystems, Inc. 31

 Layers Components Security Reliability Scalability Availability Managability Performance Portability

Redundant
system SNMP on H/W tuned CPU/ Any
Server components components memory/IO Enterprise
Hardware Sun E5500 lockdown Add Servers N+1 Servers Remote Admin configuration Server
SNMP,
Remote
Solaris, Redundant Admin Solaris
iPDS, Firewalls Network Resource Any Solaris
Lower Platform Firewall SSL Connections Manager Instance Tuning Platform
Multiple
LDAP iPAS soft- instances, N+1
based cluster thread/ instances iPAS mgnt. session affinity
Upper Platform iPAS 60 uid/pw failover sessions pools console load balancing Solaris, NT
J2EE
EJBs and Security Solaris Any J2EE
Vitrual Platform CMP Model JDMK Production JVM platform
identified
failover
Application Order Service uid/pw state JDMK good code

The system is also driven from a Domain Object Model (DOM), which is not a view
per se, but a starting point for system development. The domain object model is a log-
ical object model of the problem domain, identifying the business entities and their
relationships. Along with general business rules, it captures constraints and invariants
of the underlying problem domain. The model should refer only to the business enti-
ties and activities, not to solution-domain mechanisms. Somewhat of an art, an effec-
tive domain model can significantly and favorably impact schedules and design
decisions by minimizing design efforts going down the wrong paths.

Defining this model may begin early in inception by defining essential entities.
Further definition will continue through elaboration. A well-specified domain object
model enhances the functional specification, and provides an ongoing source of docu-
mentation for later project participants.

Process, Patterns, and Views—the SunTone Architecture Methodology

The architectural core of the SunTone AM consists of iteratively defining each of the
various architectural views. The process begins with identifying the various tiers that
will make up the application, and then defining each view by considering the required
System Qualities, and applying component patterns accordingly. At each step in the
process, the architect determines whether an as yet un-addressed System Quality will
be addressed directly within the current view, or whether to defer the implementation
of that quality to a lower layer in the stack.

32 SunTone Architecture Methodology

 LINE ITEM
ORDER
CUSTOMER
CATALOG

SEGMENT PRODUCT

N
IO

E
IO
S

C
S
T
T

R
T
TA

E
N

U
IN
E

R
N

O
LI

G
E

S
U
C

E
S

E
T
B
E

R
IN
R
P
S
N
TER
T G
PA N
IN
HTML
HTML JSP EJB JMS APPC I O
IT
RT
PA O
N
• TI
I BU
R L
ST O
An
Any
AP CHE
APACHE IAS MQ SERIES CICS
CIC DI TR
Br wser
Browser • N
CO
ESS G
C N
AC CI
• N
LA
Any OS
Any SOLARIS SOLARIS SOLARIS MVS
MV BA
A D
LO
•
R
VE
I LO
FA
Anyy HW
An E450 E5500 E250 ES9000 •

Figure 13—Systemic-Quality-driven Patterns iteratively applied to an Architecture

As illustrated in Figure 13, the patterns are applied across tiers and layers, and their
selections are driven by the Systemic Qualities.

An important component of the SunTone AM is our Patterns Catalog, which details

architectural patterns and provides guidance as to how each should be used.

This approach unites the Sun 3-D Framework as an architectural style; an iterative,
pattern-driven architectural process; and view-based architectural expression into a
single whole. By bringing together Sun’s long experience in dot-com architecture, the
proven and respected Unified Process, and the best current practices in pattern-based
systems, the SunTone AM provides an invaluable guide for the working system
architect in the dot-com age.

Sun Microsystems, Inc. 33

BENEFITS SUMMARY: 3D ARCHITECTURE
The dot-com age is upon us because of a simple technology fact—we are in an age of
ubiquitous, inexpensive, everyone-to-everyone connectivity. As former islands of tech-
nology connect, they cease to become systems unto themselves and instead become
part of a huge, globally-connected, loosely-coupled, massively distributed super-sys-
tem. In this context, the demands for scalability, availability, security, and robustness
are of a completely different order than they have been in the island days. Leveraging
this ubiquitous connectivity and the global super-system has become a key source of
competitive advantage—and so flexibility, adaptability, and extensibility for dot-com
architectures have become mission-critical, strategic requirements.

These factors combine to demand a new architectural approach, which identifies the
qualities a system or infrastructure needs to deliver value to the business which is
building it, and uses these qualities as its driving principles. When done properly, the
result is an architecture that delivers value beyond its simple functions, now and into
the future.

The 3-Dimensional Framework, SunTone AM, and Patterns provide a clear, compelling
approach that fills this need. It does not make dot-com architecture into a simple cook-
book, but it does provide a frame of reference in which a talented, experienced architect
can make the right decisions quickly and with confidence. The result:

• Systems with the scalability, reliability, and security demanded in the dot-com age:
Whether it’s “Anyone, Anywhere, Anytime, on Anything” or “Everyone, Everywhere, All
the time, on Everything”, dot-com architectures need to drive from the qualities they
will have to deliver. By framing the systemic qualities of the system as strategic
requirements and relating them properly to the logical and implementation
dimensions, the 3-Dimensional Framework allows an architecture to be described
and analyzed at design time for its delivery of these capabilities.

• Flexible systems and real reuse: A system delivered in a browser today may need to be
delivered to a hand-held device, an automobile, or a programmatic agent in the near
future. By enforcing the separation of concerns implicit in the tiered approach, and by
analyzing the functionality in terms of business services, the 3-Dimensional
Framework allows presentation, business, and resource implementations to evolve
independently. By designing and deploying functionality as network-available services
with extremely high QoS, the framework encourages real reuse of these services with-
out the cost of code ownership and deployment for each project.

• Systems with a long lifespan and the ability to evolve: The promise of standards-based
computing, embodied in the 3-D framework’s virtual platform layer, helps ensure that
architects and developers can spend more time addressing business issues rather
than technical issues. It allows for platform independence, allowing your enterprise to
take advantage of advances in computing hardware, network technologies, and
software without expensive reengineering of core dot-com applications.

34 SunTone Architecture Methodology

HOW SUN PROFESSIONAL SERVICES CAN HELP
Sun Professional Services has created an array of dot-com consulting services that
address all aspects of SunTone Architecture Methodology: architecture analysis, design,
and deployment. The services range from the Dot-Com Architecture Service to develop-
ment and deployment services such as the Dot-Com Inception service. Wherever you
are on your road to building a 3Dimensional architecture, Sun Professional Services can
help you take the next step quickly, correctly, and cost-efficiently.

DOT-COM-READY WORKSHOP
Sun’s Dot-Com-Ready Workshop is a good first step for defining your dot-com busi-
ness strategy and evaluating the technical requirements of building a 3–dimensional
Architecture. The workshop is customizable for your specific needs and will show you
how Sun consulting services, architectural approaches, competency center offerings,
and specific products and services can help you build your 3–Dimensional Architecture.

DOT-COM PROOF-OF-CONCEPT SERVICES

These services provide a concrete validation of your dot-com strategy. Our project
team helps your technical staff and ISVs jumpstart your dot-com project, and our
iForce ready centers provide a unique environment to develop, test, and evaluate your
SM

dot-com solutions. The project team examines your IT infrastructure as a set of logical
and physical components, then builds a customized, demonstrable proof-of-concept of
the technology supporting your business needs.

DOT-COM INCEPTION SERVICE

Sun’s consultants work closely with your team to explore and identify key Internet
and Java technologies that can advance your critical success factors. We’ll assess your
current IT environment and map out the technology you’ll need to deliver on the ser-
vice-level commitments you’ve made or want to make. We’ll advise you about techni-
cal aspects of Internet business strategy, identify key technical goals, scope, and
success factors, help you align your architecture strategy with your business goals,
design and document the high-level technical requirements of the architecture, and
collaborate with your staff and Web design consultants to identify use cases, develop
the user interface prototype, and document the content architecture.

Sun Microsystems, Inc. 35

DOT-COM ARCHITECTURE SERVICES
Sun consultants can help you architect a versatile foundation that will reliably
support the anticipated growth of your business and the rapid deployment of new
network services. Dot-Com Architecture Services help you put in place an architecture
based on the multi-tiered, services-driven methodology that is described in this paper.
Sun consultants also help you put in place the policies and procedures that enable you
to limit your network security exposures. Specific activities include:

• Develop an architectural prototype that demonstrates and validates the solution

• Develop a master architectural plan that outlines the entire architecture, the rela-
tion of the architecture to the strategic requirements, and the identification of the
COTS components and any necessary custom application development

• Provide a project architecture plan and a phased project plan

• Design the software solution and infrastructure architecture

36 SunTone Architecture Methodology

SUN’S COMPREHENSIVE SERVICE AND SUPPORT CAPABILITIES
As a global corporation and a market leader in UNIX® servers, system software, stor-
age systems, and workstations, Sun understands the importance of comprehensive,
end-to-end service and support. Our services for the enterprise include:

• Support Services: Sun’s support services offer the proactive systems support, the
expert knowledge transfer, and the seamless service integration you need to help
meet your mission-critical uptime objectives. Our systems support programs focus
on proactive failure prevention, rapid recovery, and technical services planning for a
global corporation’s enterprise network environments.

• Professional Services: Sun Professional Services can help you create or restructure
your IT infrastructure to leverage the Internet for optimal performance and service
quality. Sun consultants provide a full spectrum of IT planning and integration con-
sulting services, systems and network management services, Internet/intranet plan-
ning and integration services, and dot-com consulting services.

• Educational Services: Sun is an industry leader in technical education, providing

expert training, education consulting, and certification services. Sun can help
ensure that your staff has the right skills at the right time to deploy and manage
your enterprise networking technology. We can provide a wide range of education
and migration services—through a broad array of delivery options—to help you
maximize your investment in technology.

ABOUT SUN MICROSYSTEMS, INC.

Since its inception in 1982, a singular vision, “The Network Is The Computer” has
propelled Sun Microsystems, Inc. to its position as a leading provider of industrial-
strength hardware, software, and services that power the Internet and allow compa-
nies worldwide to dot-com their business. With more than $17.6 billion in annual
revenues, Sun can be found in more than 150 countries and on the World Wide Web at
http://sun.com.

Sun Microsystems, Inc. 37

HEADQUARTERS SUN MICROSYSTEMS, INC., 901 SAN ANTONIO ROAD, PALO ALTO, CA 94303 -4900 USA
PHONE: 1-650-336-7786 OR 1-888-980-7263 INTERNET: www.sun.com/service/sunps

SALES OFFICES
ARGENTINA 54-11-4317-5600 • AUSTRALIA: • CANBERRA 02 6 217 5500 • MELBOURNE 03 9679 6200 • NORTH SYDNEY 02 9466 9400 • BELGIUM 32-2-704 80 00 • BRAZIL 5511-5187-2100 • CANADA 905-477-6745 • CHINA (86) 10-6803-5588
FRANCE 33-(0)1-30-67-50-00 • GERMANY 49-89-46008-0 • HONG KONG (852) 2202-6688 • INDIA (9180) 2298989 • ITALY 39-039-6055-1 • JAPAN 81-3-5717-5027 • KOREA 82-2-2193-5114 • LATIN AMERICA 650-688-9040 • MALAYSIA (603) 2116 1888
MEXICO 525-258-6100 • NETHERLANDS 31-33-4501234 • NEW ZEALAND: • AUCKLAND 0011649 976 6800 • WELLINGTON 0011644 462 0780 • SINGAPORE (65) 4381888 • SPAIN 34-91-596-9900 • SWEDEN 46-8-631 10 00 • SWITZERLAND 41-1-908-90-00
TAIWAN 886-2-8732-9933 • THAILAND (662) 3446888 UNITED KINGDOM 44-1252-372272 • UNITED STATES: • ATLANTA 770-360-6400 • BOSTON 781-270-7200 • CHICAGO 630-285-8700 • EL SEGUNDO 310-607-2442 • IRVINE 949-833-1640 • NEW YORK 212-558-9200
SANTA CLARA 408-276-9488 • SOMERSET 732-469-1000 • WASHINGTON D.C. 703-204-4100 • WORLDWIDE HEADQUARTERS 1-650-336-7786 OR 1-888-980-7263 • EUROPEAN HEADQUARTERS 44-1276-451440 • ASIA-PACIFIC 650-786-0239

© 2001 Sun Microsystems, Inc. All rights reserved. Sun, Sun Microsystems, the Sun logo, Java, Enterprise JavaBean, JavaServer Pages, Solaris, SunReady, Java 2 Platform, Enterprise Edition, iPlanet, Sun Cluster, SunTone
Architecture Methodology, and iForce are trademarks, registered trademarks, servicemarks or registered servicemarks of Sun Microsystems, Inc. in the United States and other countries. Products bearing SPARC
trademarks are base upon architecture developed by sun Microsystems, UNIX is a registered trademarks or registered in the United States and other countries, exclusively licensed through X/Open Company Ltd.
Printed in USA 5/01 FE1590-0