SunTone Architecture Methodology

The N1 Grid solution is not a replacement for doing good architectural design work. The N1 Grid is best realized by using architecture as the link between business decisions and the physical environment on which people, process, and technology decisions are carried out. Because of architecture's importance, this section provides an overview of Sun's architectural principles and building blocks.

The SunTone^SM Architecture Methodology (SunTone AM) frameworks provide the means to create a mobile, service-centric IT environment:

• A decomposition method creates reusable building blocks with specific functionality and capability.

• The methodology includes analysis of the business, service, and management contributions to the solution.

• Use cases and traceable requirements link solutions to key business drivers in clear and unambiguous ways.

• The methodology enables iterative and incremental solution creation, if needed.

The SunTone AM builds on the ideas that make up the Unified Process. Like the Unified Process, the SunTone AM is use case focused, architecture-centric, 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.

For a complete discussion of the methodology, refer to:

http://www.sun.com/service/sunps/jdc/suntonearchmethod.html

Decomposition

The SunTone AM cube (FIGURE 4-2) decomposes service functionality along three axes:

• A set of tiers you can use to physically or logically divide the application functionality across multiple platforms

• A set of layers that represents levels of abstraction within a single platform, across which service functionality can be physically or logically divided

• A set of systemic qualities that describe individual service goals in the operational or business environment

Figure 4-2. SunTone AM Cube Functionality Axes

As the name implies, the functionality axes are often drawn together in a cube.

Tiers

Tiers enable you to break up an analysis or a solution into discrete structures along some form of distinctive boundary. The distinctiveness is defined in relation to the other tiers in its enclosing system (for example, the other tiers in an "N-tier" system). There are at least three types of tiers. Each tier delivers a different distribution strategy to consider:

• A conceptual tier delineates some sort of distinct functional boundary.

• A logical tier groups segments of software functionality that communicate over the network.

• A physical tier might group one or more compute, network, or storage devices that share common scalability strategies, security requirements, or control mechanisms.

  Conceptual tiers represent a decomposition principle that is commonly used to separate functionality and provide specific systemic qualities. Well-known conceptual tiers include the following types:

• Client tiers represent the points at which data is consumed externally to the system.

• Presentation tiers mediate between multiple diverse clients and the middle tier, enabling common middle-tier logic to remain unchanged for differing client types. Presentation tiers can distribute statically or dynamically generated code to clients outside the control of the immediate system.

• Middle tiers (business logic or business service) provide the integrated view of the core business services.

• Integration tiers wrap and guide access to diverse resources in the back-end tier.

• General or back-end (often a database) tiers store, manage, and provide access points to data and other internal and legacy systems.

The design is simplified when logical tiers map closely to, or even exactly to, conceptual tiers, but this correspondence can migrate over time due to business or technology choices (for example, updates move some part of the business logic tier out to presentation or client tiers, or persistence gets moved into the business tier).

Physical tiers can map to individual logical tiers, or several logical tiers can run on the same physical tier if similar control, security, or scalability characteristics need to be delivered. A physical tier enables the support for multiple underlying configurations or a future evolution of the underlying hardware topology without significant code changes or service interruption.

A typical example of a physical tier is a set of servers delivering HTTP connections behind a hardware load balancer. The individual servers can be different in size or platform or even be removed, replaced, or updated during HTTP service delivery. Working in combination behind the load balancer, they supply the HTTP service at the advertised HTTP access point. The abstraction of the service provided from the platform on which it runs is an important element of N1 Grid solution problem analysis and solution creation.

Layers

Layers constitute another discrete analysis and distribution strategy axis. The type and number of layers is determined by the architectural style and level of desired granularity or control. Typical layers can be defined as follows:

• An infrastructure layer includes the facilities and physical network infrastructure on which the IT environment runs (for instance, elements such as cooling, physical security, and electrical power).

• A hardware layer includes the compute, storage, and network devices that provide cycles and capacity for business services.

• A lower layer provides the platform to deliver the operating system and the other lower-level system services such as time, boot, naming, and file services.

• An upper platform layer is designated to hold web servers, application servers, and various types of middleware.

• A virtual platform layer insulates the application from the various implementations in the upper platform layer, facilitating vendor independence and choice (the J2EE platform is the most prominent example of this layer).

• An application layer includes application-specific components, including Enterprise JavaBeans software and most custom code.

TABLE 4-2 depicts some example layers for several common tier types.

Table 4-2. Example Layers with Associated Tiers

Example Layer	Presentation Tier	Business Tier	Data Tier
Application	Custom form handler	Online order service	Customer, inventory, and pricing data
Virtual	JavaServer Pages™ software servlet	Enterprise JavaBeans API	JDBC (Java Database Connectivity)
Upper	Web server	Application server	Database software
Lower	Linux, LDAP, DNS, firewalls, and load balancers	Solaris OS, LDAP, DNS, firewalls, and load balancers	Solaris OS, LDAP, DNS, and firewalls
Hardware	AMD	SPARC® platform	SPARC® platform
Infrastructure	Horizontally scaled behind load balancing hardware	Horizontally scaled with a version of stateful failover	Vertically or horizontally scaled, hardened data center with replicated data for business continuity

Note that each layer represents a particular type of provider-consumer relationship between a deployable entity and its container. Using the business tier example, some of the relationships to explore are:

• The upper layer application server is deployed into and consumes lower-layer resources. It also provides an environment in which virtual-layer Enterprise JavaBeans software can be deployed and run.

• The lower layer operating system is deployed into and consumes hardware-layer resources. It also provides an environment in which an upper-layer application server service can be deployed and run.

• The hardware layer is deployed into and consumes infrastructure-layer resources. It also provides an environment in which some operating systems can be deployed and run.

The virtualization, provisioning, and control of network-centric providers and consumers is one of the central capabilities delivered by the N1 Grid system. Think about the virtualized provider-consumer relationships in your data center as you encounter additional examples throughout this book. You should also think about the benefits you will gain from virtualizing your providers and containers and automating the provisioning of your consumers and services.

Systemic Qualities

Systemic qualities are delineated on the final axis of the cube. As mentioned, systemic qualities are used to discuss and collect the current and future goals of the N1 Grid system as it fits into the business and operational environment. Although it is useful to work with individual qualities in an architecture, the qualities are often grouped to assist explaining their definition or source. FIGURE 4-2 reflects one such grouping (that is, user, service, system and strategic qualities):

• User Level qualities are those experienced directly in the user interface and directed at user functionality. These qualities are characteristics of the architecture interface that are felt directly by its users:

  • Usability reflects the ease with which users can accomplish their goals. Personalization is a trend that can benefit usability. In addition, internationalization adds to usability.

  • Accessibility incorporates usability paradigms for those with physical limitations.

• Service Level qualities are characteristics of the architecture service functionality that can be felt directly by users in their business experience. Service Level qualities impact business functions:

  • Performance as a QoS component relates both to specific performance metrics (e.g., responsiveness, latency) and to the users' expectations about performance.

  • Reliability describes the likelihood of any service loss or failure based on underlying component failures. Reliability is measured by how often the system fails or the mean or other time between failures.

  • Availability measures service uptime versus downtime and can include the capability and measurement of continued partial operation in partial failure situations. Reliability contributes to availability, but availability can be achieved even when individual components fail through the use of redundant components and failover mechanisms, with a preference toward gracefully degraded operation in place of total failure.

• System Level qualities are related to peripheral services and issues rather than direct business functionality. System Level qualities are generally only visible to end users when those qualities are more seriously degraded, and then often only indirectly. Typical System Level qualities:

  • Maintainability eases the work of minor modifications and fixes, which extensibility makes significant enhancements or changes easier to accomplish.

  • Manageability is the ability to easily start, restart, and stop the system or its sub-processes, to monitor it for behavior relative to desired quality thresholds, and to take corrective action accordingly.

  • Security is a complex and pervasive element of system design. Securability controls access to resources, information and data ensuring that critical security factors such as confidentiality, privacy, integrity, accountability, and availability are enforced and maintained. This activity typically includes configuring or adjusting the security posture (or configuration) of systems, devices, and other assets to comply with security policy while also supporting the defined business and technical objectives, provisioning access rights to individuals, roles or groups for both assets and data, and verifying security controls and compliance through monitoring and periodic assessment.

  • Serviceability is the degree to which a system can be repaired or updated, as reflected by the granularity of its replaceable components, the ease and speed they can be swapped, and the downtime effect on the overall system.

• Strategic Level qualities relate more to the ability of the architecture to change over time than to its ability to perform at any given point in time. Unlike runtime qualities, strategic evolutionary qualities are in general much more difficult to measure because their effect is not apparent until some date following the system release, and they are generally felt more by the business organization than the end user. For instance:

  • Scalability relates to the ability 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. Scalability relates to the total scalability of a service as well as the scalability of individual components.

  • Flexibility is a measure of how easy it is to add new services to the architecture and to re-purpose the components to provide new or different services. Flexible architecure have individual components that can be used by different services and can be reorganized to provide new services.

This list of qualities is often described as the "ilities." The groups of qualities discussed are an illustrative list. They are not intended to be complete indeed, how many and which qualities to incorporate into a network computing problem analysis and system design is rightfully left to the architect as a function of the problem space complexity, solution history, and architectural methodology.

Note that the combination of many smaller cubes (at the intersection of each point along the three axes that form the larger SunTone AM cube) invoke interesting architectural questions. The generic form of the questions is: "How will your design address the ility for the layer in the tier?" Three specific examples are:

• "How will you address the scalability of the upper layer in the middle tier?"

• "How will you address the availability of the hardware layer in the data tier?"

• "How will you address the securability of the lower layer in the client tier?"

The sum total of the individual questions creates a basis for the definition of the problem space, the architectural activities to decompose that space, and the design and operational efforts to deliver the required solutions.

Additional SunTone AM Principles

Although the SunTone AM cube describes the runtime stack in a very useful way, other aspects of the methodology address the business and operations elements that complement the functional service representation of IT services in the cube.

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. 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 continuously delivering functionality directly related to the end product being developed. Functional use cases illuminate certain working elements of the system: users can log on and view web content, the business tier successfully integrates information from several sources, or the database responds to a certain number of simultaneous queries. Operational use cases capture activities that support the system in use: people, processes, and tools are in place to support error condition collection and display, problem management capability is functioning, or service level agreement (SLA) metrics are being successfully calculated from the various underlying event, capacity, and performance information managers. N1 Grid solution use cases extend these typical functional and operational use cases by moving provisionable entities between elements that can host them (for instance, moving the database from one server to another) or supporting a service life cycle for a particular application or set of applications (for instance, from the development environment, to the test environment, to the production environment, and eventually to the deactivation of service).

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, but 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 benchmarking the system or service response to a volume of representative transactions, testing the compatibility of various technologies, and certifying the smooth operation of a failure recovery mechanism. Some N1 Grid solutions will benefit from these initial validation steps.

Iterative and Incremental

Development in the SunTone AM is executed as a series of iterations, each of which consists of the development and integration testing of complete use cases. In this way, integration testing occurs early, often, and throughout the development cycle. The iterations enable the early detection and correction of requirements, design technology, or usability issues. These corrections are folded back into the earlier requirements gathering, measurement, or analysis phases, and the outcome of the earlier phases is reconsidered with the new information that the later phases uncovered. In addition to this iterative construction, system functionality can be broken down and delivered incrementally in a series of intermediate, well-tested releases each of which builds on the functionality delivered in the previous release.

Regression testing has an important role in interative and incremental development. The testing metrics from each previous run should either be deprecated or applied (as appropriate) to ensure no regressions creep into the architecture.

As the next sections introduce concepts that define areas for N1 activity, consider how iterative approaches can be built into a complete solution. Two examples might be iterating through compute, then storage, then network resources, as you drive to separate the delivery of these resource capabilities from the platforms that provide the capability, or iterating through automating service provisioning and observability in preparation for the policy-based optimization of those services.

People, Processes, and Tools

The functionality of the designed system cannot be delivered on its own. It requires the operational qualities to be realized in an environment that combines people, processes, and tools to deliver IT services to an agreed-upon service level in a predictable fashion with acceptable risk and cost. As previously illustrated, people and process have a huge impact on the cost, availability, security, and reliability of data center services. Aspects of operational maturity, possible impacts, and possible capabilities are discussed throughout the remainder of this book.