Planning and Building an Architecture that Lasts: The Dynamic

Marketfocus Report

Planning and Building an Architecture that Lasts: The Dynamic Enterprise Reference Architecture

In most organizations today, technology infrastructures have become highly complex and difficult to manage, with significant overlap of systems and applications, further complicated by the fact that these systems are not well integrated. There is a clear need for a standard Enterprise Reference Architecture as an architectural framework to help organizations make better decisions and enable them to leverage existing technology investments. TIBCO Software, a leading provider of software for real-time business, commissioned Doculabs to develop this white paper as a guide to the considerations involved in building an architecture that will last through the years. In this document, we advocate an approach based on the service-oriented architecture (SOA) model as a framework and guidepost toward the building of a solid architecture that will meet an organization’s needs – both current and future. We also report on how other future looking companies, HP and Intel, view building an architecture that will last.

120 South LaSalle Street Suite 2300 Chicago, IL 60603 (312) 433-7793 www.doculabs.com E-mail Doculabs at: [email protected]

2 0 0 3 D o c u l a b s , 1 2 0 S o u t h L a S a l l e S t r e e t , S u i t e 2 3 0 0 , C h i c a g o , I L 6 0 6 0 3 , ( 3 1 2 ) 4 3 3 - 7 7 9 3 , i n f o @ d o c u l a b s . c o m . R e p r o d u c t i o n i n w h o l e o r i n p a r t w i t h o u t w r i t t e n p e r m i s s i o n i s p r o h i b i t e d . D o c u l a b s i s a r e g i s t e r e d t r a d e m a r k . A l l o t h e r v e n d o r a n d p r o d u c t n a m e s a r e a s s u m e d t o b e t r a d e a n d s e r v i c e m a r k s o f t h e i r r e s p e c t i v e c o m p a n i e s .

2

Doculabs Marketfocus Report

Planning and Building an Architecture that Lasts

©2003

What’s Inside…

3 Executive Summary Highlights the business benefits of a service-oriented architecture, which leverages standards to provide even more flexibility while minimizing the costs associated with development and management.

4 Introduction Defines a service-oriented architecture and its components and characteristics, and discusses the role of new approaches to an enterprise reference architecture.

10 Conceptual Enterprise Reference Architecture Explores the conceptual layers within a sound enterprise reference architecture – layers that work together to provide a cohesive platform on which to build applications that address business requirements effectively.

14 Ensuring Success through Good Architecture Highlights best practices and approaches to ensure that the enterprise reference architecture truly helps realize the business benefits outlined above. Generic customer examples are included to highlight the key ways in which organizations should think about implementing in a phased approach the concepts presented in the enterprise reference architecture.

17 Sharing the Vision Highlights how TIBCO, Hewlett-Packard, Intel, and other leading technology providers are providing solutions that are critical to delivering on a service-oriented enterprise reference architecture.

24 The Final Word Provides Doculabs’ perspective on the value of a service-oriented enterprise reference architecture, and of the approach taken by customers and providers such as TIBCO.

25 Appendices Appendix A: “Technical Implementation of an Enterprise Reference Architecture,” and Appendix B: “The Technology Layers of an Enterprise Reference Architecture,” provide technical detail on how an enterprise reference architecture would be implemented.

Doculabs Marketfocus Report 3


©2003

Executive Summary Organizations are struggling in their efforts to adapt to quickly changing business conditions, while also maintaining an acceptable balance sheet. The volatile nature of business is forcing organizations to become more flexible, while at the same time mandating that they keep their cost structures low to meet investor demand. Technology has long been used to improve organizational efficiency and to provide better ways to solve common business problems. For example, technology can be used to improve processes in areas such as order-to-cash in the manufacturing or retail sectors, mortgage processing in the financial services sector, and straight-through processing in banks and brokerages. If organizations are to become both more agile and more effective at leveraging their existing technology investments, they must develop or adopt a guiding framework for their technology environments. By following an enterprise reference architecture, an organization ensures that it follows such a framework and can make better decisions that will optimize its technology investment decisions to achieve its business goals. Enterprise reference architectures have existed for years, but their effectiveness has sometimes been limited for a number of reasons, including a lack of

standards, a lack of supporting technologies, and an inability to facilitate closed-loop enterprise lifecycles. By taking these issues into account, today’s service-oriented enterprise reference architectures can provide organizations with a clear framework for their environments and best practices. The modern reference architecture is service-oriented, event-driven, and aligned with lifecycle support processes. In addition, the modern reference architecture can support assembly and integration, and encompasses the need to leverage existing applications and infrastructure. Ultimately, a sound enterprise reference architecture provides a number of benefits: • The ability to adapt to changes in

business conditions more rapidly than has been possible in the past, and allow business users to be closely involved with (and in some cases, even own) changes in business processes

• The ability to reduce the amount of time spent developing custom code and complex applications, using business processes to assemble applications rather than requiring the use of declarative programming

• Significant cost savings over time, as more of an organization’s existing investments in technology and systems are leveraged rather than replaced

4



©2003

Introduction This section introduces the concept of an enterprise reference architecture, its architectural constructs and characteristics, and historic failures with enterprise reference architectures that new approaches can address.

Enterprise Reference Architecture Constructs An enterprise reference architecture provides a framework or set of guidelines and practices for a technology environment. To understand the benefits and key characteristics of the modern enterprise reference architecture, it is important to understand each of the individual architectural constructs that comprise it. Architecturally, the modern enterprise reference architecture is:

• Service-oriented – Allows applications to be broken into services that can be accessed by other applications and systems to create powerful composite applications based on the functionality available in applications across the enterprise.

• Event-driven – Provides a fundamental mechanism to capture key changes in business needs and technical implementation. These changes can then be used to effect instantaneous changes to business processes and the underlying systems that support them.

• Aligned with lifecycle support processes – Organizations are constantly designing, deploying, managing, and re-evaluating their applications. Until now, the process of making decisions on design, development, and optimization has not been based on empirical evidence and real data about application usage patterns and business model behavior. Going forward, architectures must account for the collection, dissemination, and use of this information to help organizations make better decisions.

• Able to support assembly and integration – Once applications are segmented into smaller functional units, the ability to assemble these components into applications is critical. In the past, writing code was the only way to achieve the goal. Today, process management technology achieves the same goals while reducing reliance on costly code development.

• Able to leverage existing applications and infrastructure – As organizations look for different ways to minimize unnecessary technology spend, they are looking for ways to re-use existing technology. For most organizations, existing infrastructure, systems, and applications are home to the core data and functions that drive the business forward day to day. These systems must be leveraged to provide maximum benefit.



©2003

Service-Oriented Architecture A service-oriented architecture is defined as an architectural strategy that seeks to segment and isolate critical application and data functionality and access into small, operationally independent pieces that can be executed remotely and in a highly distributed manner. The end goal of a service-oriented architecture is to provide easy and secure access to enterprise technology and process resources, maximizing re-use and minimizing cost, while improving the performance and reliability of these systems.

Benefits of a Service-Oriented Architecture

Short-Term

• Enhances reliability • Reduces hardware acquisition costs • Leverages existing development skills • Accelerates movement to standards-based server

and application consolidation • Provides a data bridge between incompatible

technologies

Long-Term

• Provides the ability to build composite applications • Creates a self-healing infrastructure that reduces

management costs • Provides truly real-time decision-making

applications • Enables the compilation of a unified taxonomy of

information across an enterprise and its customer and partners

Business Value

• Ability to more quickly meet customer demands • Lower costs associated with the acquisition and

maintenance of technology • Management of business functionality closer to the

business units • Leverages existing investments in technology • Reduces reliance on expensive custom development

Table 1 – Benefits of a Service-Oriented Architecture

As with any enterprise architecture, service-oriented architectures require careful planning and a holistic approach that takes into account the effect of the architectural approach across all layers of the architecture. Layers are architectural constructs that are used as a mechanism to provide isolation between a set of components. They provide the ability to change underlying components without affecting how other resources use them.

Characteristics of Service-Oriented Architectures A good service-oriented reference architecture should embody each of the architectural constructs described above. That is, they should be event-driven, aligned with lifecycle support processes, able to support assembly and integration, and able to leverage existing applications and infrastructure. This section provides details on how this is accomplished.

Event Services Event-driven architectures allow services and applications to react to stimuli from systems, applications, and people, both across and outside of the enterprise. Unlike traditional architectures, event-driven architectures provide a mechanism for systems to take action when pre-determined or unplanned events arise. An example of an event is the failure of a business process to reach completion within a specified timeframe, such as the

6



©2003

execution of an order. Another example is the failure of a processing thread in an application container running on a specific server. These events can be extremely business focused, or they may be very technical in nature. The simple fact that these events can be captured makes it possible to take corrective action or escalate response appropriately. At a fundamental level, an event-driven architecture is more dynamic than non-event-driven architectures. The simple ability to change a business process or react to a problem as it is happening provides a tremendous advantage to organizations, relative to competitors using traditional architectures, where reaction to such changes can take days or weeks.

Benefits of an Event-Driven Architecture

Short-Term

• Allows for pro-active problem solving • Better addresses customer needs without resorting

to one-off customization by helping drive dynamic processes

Long-Term

• Improves customer loyalty and satisfaction • More visibility into business health through near

real-time organizational dashboards

Business Value

• Provides the best products and/or services to customers and partners

• Competitive advantage over slower-moving competitors

• Greater visibility into enterprise status and issues

Table 2 – Benefits of an Event-Driven Architecture

Transactional systems, such as ERP and procurement applications, tend to be inherently event-driven and can work very well within an event-driven architecture. Unfortunately, other systems, such as legacy mainframe applications, usually were not designed to be event-driven. Fortunately, there are ways to make these systems event-driven so that they can help an organization drive toward a more dynamic enterprise. Lifecycle Support Most organizations have come to realize that the technology they use to solve business problems is constantly changing and needs to be updated frequently to keep up with changing business demands. These companies are in a constant cyclical process of designing and redesigning applications, developing, redeveloping, and optimizing these applications, and deploying and managing these applications. Many decisions that are made are based not on empirical data, but rather on perceived requirements. In today’s business environment, it is critical to take this guesswork out of the equation. Today, decisions must be made first and foremost on empirical evidence. An architecture based on the fundamental concept that the enterprise lifecycle represents a closed loop of feedback is most likely to help organizations succeed. Today’s systems are capable of capturing vast amounts of



©2003

information on their usage patterns and performance against set measures. With this data, organizations can quickly provide a mechanism to use this information to optimize business processes and remove bottlenecks from the technical infrastructure within their environments. In the end, organizations that are able to better leverage the information their applications can report, will be more effective at optimizing their infrastructures. Optimization will result in increased efficiency and ultimately in the ability to spend money to increase investment in customer-facing activities. Assembly and Integration Until recently, the only way to build custom applications was to write code using declarative programming. Although writing application code has become significantly easier and more productive, it is still time consuming and fraught with the possibility of bugs and slow time to benefit. The other major problem with declarative development is that it may take a long time to make even minor changes in code and it will always involve time on the part of developers. Business users can do little to help in an environment whose architecture is driven by declarative programming. Today, the ability to rely on a service-oriented architecture that is driven by processes allows organizations to start assembling applications that can change

with the changing needs of the business. Business processes are developed and are driven by the functionality and data that is exposed through the services available throughout a services-oriented enterprise. One of the key benefits of adopting an architecture that takes advantage of application assembly and integration is that it leverages the different skills that exist in most organizations more effectively than most other architectures. Business users are finally enabled to provide value through the definition of business processes and business rules, while technologists can drive the access to key information and systems through services. Even administrative staff can more effectively manage the composite applications that are developed. Leverage for Existing Applications and Infrastructure Many of the technology investments that organizations have made over the past several decades have fallen into two major categories: technology infrastructure and application systems. Technology infrastructure refers to the hardware and network infrastructures put in place to support the application systems that run within them. Application systems include legacy applications, enterprise resource planning systems, customer service systems, databases, and other technology used to drive business.

8



©2003

Any architecture that is worth considering should strive to leverage the large investment that has already been made in application systems. Ideally, these systems can be used seamlessly throughout the organization and can participate in complex business processes without significant re-investment in development. The architecture should provide a clear approach for integration and access to these systems.

Addressing Historic Limitations of Enterprise Reference Architectures The idea of enterprise reference architectures is not new; these frameworks have existed in many forms over the years, but have failed for many different reasons, including: • A lack of technology standards.

Standards provide a way for organizations to isolate themselves from changes in technology, ultimately making their investments last longer and allowing them to avoid being locked into a particular vendor over an extended period of time. Without standards, an enterprise reference architecture does not maximize its ability to ensure long-term viability of technology investments.

• Limited ability of off-the-shelf technology to achieve the goals they proposed. In many instances, no supporting technology existed to address many key business problems. In the past, few enterprise architectures had any notion of back-end application integration, or if they did, it was a feat left to a hoard of developers to achieve. The cost of building one-off integrations among systems and applications was prohibitively high and reserved for only critical applications.

• No focus on the closed-loop enterprise lifecycle. Organizations are constantly going through a multi-step lifecycle when using technology to achieve business goals. For an enterprise reference architecture to be effective, it should embrace a lifecycle process that includes the following steps:

1. Evaluating the applicability of technology in solving or helping solve a given business problem

2. Designing the solution at both the business process level and the technology architecture level

3. Implementing the solution 4. Testing and modeling the

solution and its behavior 5. Deploying the solution 6. Maintaining the solution 7. Reviewing feedback about the

solution and technical characteristics of the solution

8. Starting the cycle again to optimize the solution



©2003

Problems with Past Enterprise Architectures

Why are these problems?

Lack of standards

Organizations were locked into choosing solutions that may not fit with the constantly changing nature of their business.

Supporting technology did not exist

Off-the-shelf technology did not exist for many of the key problems that plagued organizations. Some examples include integration technology and process management engines.

Lack of support for a closed-loop enterprise lifecycle

Solutions must constantly evolve to meet changing business needs; in the past, there was no way to achieve such changes, except through guesswork based on the information available. Today, data should be captured that allows business owners and technologists understand key usage patterns and their effects on a solution so that the solution can be optimized on an ongoing basis, based on empirical data and evidence.

Table 3 – Problems with Prior Enterprise Architectures

By taking these issues into account, today’s enterprise reference architectures should provide organizations with a clear framework for their environments and best practices. Such an architecture will provide a number of benefits, including: • The ability to adapt to changes in

business conditions more rapidly than possible in the past. Business users should be able to be closely involved with – in some cases, even own – such changes in business processes.

• The ability to reduce the amount of

time spent developing custom code and complex applications using business processes to assemble applications rather than declarative programming.

• Significant cost savings over time, as

more of an organization’s existing investments in technology and systems are leveraged rather than replaced.

10



©2003

Conceptual Enterprise Reference Architecture Although each architectural characteristic or construct is important on its own, none of them can deliver the benefits that are possible when all of them are brought together in a single architecture. A services-oriented architecture can be depicted as providing a number of individual service layers. Together, these layers provide an unprecedented level of flexibility in application design, while minimizing cost and providing more pertinent applications and business value to customers. The major layers are as follows: • The enterprise application and data

systems layer, which consists of an organization’s existing technology investments. The rest of the architecture relies on this layer for the critical application functionality and data that are used to drive business processes throughout the organization. Moreover, much of the investment and capital expenditures in technology have been made in this layer. Thus, it is extremely important that these investments be leveraged fully in the rest of the architecture.

• The data services layer, which provides a set of services that allow organizations to extract and re-use data from the enterprise application and data systems in the organization. The data services layer isolates the organization from changes in the underlying data systems and applications, as well as providing a unified approach for accessing the data and functionality of those systems.

• The application services layer,

which is designed to provide the functional components and technologies that are used to ensure high levels of application scalability, performance, and reliability. Application components are managed in this layer to ensure that they are secure and available to other parts of the architecture when needed.

• The business services layer is where

technology meets business. In this layer, applications are composed from a combination of business processes, business rules, human workflow, and the services exposed by the application services layer. The combination of these technologies allows organizations to quickly and effectively model and optimize their business processes to best suit customer and business needs.



©2003

• The presentation and interface services layer, which provides users and external systems a way to communicate and interact with business processes and business applications. This layer is the primary mechanism to enable human workflow and is also used to issue alerts and to gather events from external systems.

• The event services layer, which

gathers event data across the enterprise and also across all of the layers of the architecture. The events are then used to drive dynamic business processes and dynamic changes in the underlying layers to provide better performance, reliability, and scalability. The event services layer also creates a closed feedback loop with each layer of the architecture allowing developers and business users to optimize their part of the architecture using empirical data to drive key decisions.

• The enterprise lifecycle services layer, which provides a mechanism to effectively: • Design and model business

processes and system interaction

• Assemble and develop applications from existing components

• Deploy and maintain applications in a production environment, even if the components are distributed

• Analyze and optimize processes and application infrastructure, based on data gathered by the event services layer

The following figure illustrates a business view of the layers of the enterprise reference architecture.

12



©2003

Inst

rum

enta

tion

Even

t Ser

vice

s

Ente

rpris

e Li

fecy

cle

Serv

ices

Presentation / Interface Services

Business Services

HumanWorkflow

Business Process

Business Rules

Application Services

Data Services

Data Modeling

Enterprise Application and Data Systems

Message Bus

MetadataRepository

ApplicationContainers

StandardInterfaces

ApplicationAdapters

LegacyService

Abstraction

Mainframe /Legacy Apps

ERP

CRM/SFA

ContentManagement

Other Systems

Other DataSources

Web Portal Mobile Devices Standard Formats

Design /Modeling

Assembly /Development

Deployment /Maintenance

Analysis /Optimization

Figure 1 - Business View of the Enterprise Reference Architecture



©2003

The following table illustrates some of the common technologies found in the major architectural layers and lists some vendors that provide those technologies.

Layer Technologies Sample Providers Enterprise Application and Data Systems

• Enterprise resource planning • Content management • Mainframe and legacy

applications • Customer relationship

management and call center systems

• SAP, Oracle Applications, and PeopleSoft

• Documentum, Interwoven, and Vignette

• Fraud detection systems, telecommunications provisioning applications, etc.

• Kana and Siebel Data Services • Application and data systems

adapters • Data model and persistence

engines • Legacy functionality extraction

• Actional, iWay, TIBCO, and WebMethods

• BEA, Rational, Sybase, Teradata, and TIBCO

• Microsoft, Oracle, Teradata, and TIBCO


• Messaging • Application containers • Standard interfaces • Metadata repositories

• IBM, Sonic, and TIBCO • BEA, Borland, IBM, Microsoft,

and Oracle • Java standards, .NET

standards, web services, etc. • IBM, Oracle, Teradata, TIBCO,

and custom repositories Business Services • Business process

• Business rules • Human workflow

• Fuego, Fujitsu, IBM, Microsoft, and TIBCO

• Ilog, Pegasystems, and TIBCO • Fujitsu, IBM, Staffware, and

TIBCO Presentation / Interface Services

• Web portal • Mobile devices • Standard formats

• IBM, Microsoft, Novell, Oracle, Plumtree, Sybase, TIBCO, and Vignette

• WAP, WML, Java, etc. • EDIFACT, ebXML, other XML,

etc.

Table 4 – Conceptual Architecture Layers

14



©2003

Ensuring Success through Good Architecture As mentioned previously, adopting a service-oriented enterprise reference architecture is the first step in making better technology decisions that lead to a more efficient and nimble organization. However, there are many decisions to be made on the road to building a more flexible organization around a service-oriented reference architecture. The situation is further complicated by the fact that different organizations have different business priorities, different risk-tolerance levels, and different budget levels allocated to leverage technology to solve their business problems. There is a clear approach and methodology that can help individual organizations determine how best to proceed. In building toward a service-oriented enterprise reference architecture, it has been proven that organizations that have taken a pragmatic approach share a number of key characteristics. These organizations tend to:

• Solve small problems first • Involve both technologists and

business users • Make key investments in technology

when necessary • Achieve buy-in from the highest

levels within the organization • Leverage existing investments

before investing in new technology

Successful organizations have identified and prioritized specific business problems that have clear benefits for the organization. These benefits may include projects that are accretive in the short-term, projects that improve internal organizational communications and morale, projects that improve relationships with partners, or that provide a number of other valuable outcomes. By taking a step-by-step approach to implementing a services-oriented approach to solving a specific business problem, an organization is able to better manage the selection, development, implementation, and management of different technologies. As more and more projects are completed and meet with success, the result is greater buy-in from organizational management, representing both the technology and business groups within the company. A successful project involves getting commitment from a variety of constituencies throughout an organization. The first hurdle is getting a common understanding of the business process or application that is being prioritized. Many organizations never get past this stage in the implementation; they have difficulty clearly defining the process interactions at a process level. Some of the causes of this confusion are a lack of involvement from the people who intimately understand the process, or lack of



©2003

involvement from the people who will need to build and maintain the business application that implements the business process. It is important to have both constituencies involved to ensure success and ownership from start to finish. In some cases, it becomes apparent that a project cannot proceed without significant investment in a new technology. For many organizations, this technology investment may be a strong event-driven process management and integration engine; for others, it may be investment in a robust, scalable, and reliable hardware and network infrastructure. These expenditures are often costly, and require support from top levels of management. Organizations must be prepared to perform a thorough analysis to determine the benefit of such investments over the long term. Investments in core technology that can be leveraged over and over again are often justified and pay back dividends that multiply many times over the amount that was spent early on. For example, consider a large utility company that had to replace an aging power outage management system in an effort to meet regulations related to meeting service level agreements. The organization was faced with the daunting task of replacing the mainly mainframe-based application with a more manageable service-oriented architecture. Process automation was

one of the key requirements to make the change viable as a long-term solution. The organization was hoping to implement an event-based process management infrastructure that could react to external stimuli such as power level fluctuations, power outages, and other critical events that could occur in different parts of the organization or even in the systems of the company’s power system alliance. A service-oriented architecture was appealing because it provided a way to create a system that was based on standards and one in which the application could change quickly with changing business needs, without requiring a great deal of manual recoding of applications. Ideally, the system would allow the utility company to modify business process flows, and the underlying services would automatically service the changes. One of the critical realizations in this project was the fact that a service-oriented approach does not require re-developing applications from the ground up to make them services. Rather, monolithic applications, such as the mainframe-based outage management system, could be queried and accessed to appear as though it were providing a variety of services that could be accessed by other applications within the organization, such as the outage management executive dashboard that was built using web application technology.

16



©2003

To ensure the success of this project, both the line-of-business and information technology group were involved in defining and outlining the problem to be solved. Executive sponsorship was almost guaranteed (not something that an organization can always count on), in this case because of the legal ramification of failure to comply with the regulation. A large investment in an event-driven business process management solution was deemed necessary early in the project. Because the technology was leveraged in subsequent projects throughout the organization, the utility company realized a return on its investment within just one year. The organization met the requirements for compliance and has enjoyed success in deployment and in the ongoing maintenance of the application. The company has been able to reroute and automate processes effectively, lowering its processing costs and reducing costly errors. Going forward, the utility company would like to be able to more effectively analyze its business process and get real-time feedback on the performance of its processes. The information will be invaluable when reconfiguring and optimizing the existing process flows.



©2003

Sharing the Vision A number of leading technology providers now offer solutions that deliver on a service-oriented enterprise reference architecture. This section looks at how TIBCO, Hewlett-Packard, and Intel share the vision: providing technology that allows for the building of an architecture that lasts.

TIBCO As a provider of technology, TIBCO has offered highly scalable, reliable, and high-performance solutions for mission-critical applications for nearly two decades (originally as Teknekron). Today, TIBCO continues to innovate and provide a suite of solutions to businesses focused on solving business problems. Its ActiveEnteprise suite provides integration, process management, workflow, portal, and related technologies. Looking forward, TIBCO has embraced the idea of a dynamic architecture that allows business to create a closed loop between business, technology, business problems, business solutions, and customers, partners, and staff. TIBCO believes that the combination of a service-oriented architecture with business process management will allow organizations to effectively build composite applications that can be

assembled as needed by leveraging existing investments in development. Composite applications by themselves provide a flexible way to develop and deploy applications across an enterprise, but they generally lack the ability to take action based on business situations that may arise within an organization. TIBCO believes that the next logical evolution to the composite application is the incorporation of event-processing technology and business rules. As mentioned previously, event-processing technology allows systems and applications to take action automatically to better meet requirements that may arise spontaneously. Event-driven services and composite applications can quickly be reconfigured based on the needs of an organization – almost instantly. For more complex changes, TIBCO believes that externalizing business rules from business processes puts the power of change back into the hands of those who best understand the business. Armed with a system that supports business rules on top of a process management engine, business analysts can change processes and business flows without making fundamental changes to the underlying processes and application code. The final piece of the puzzle is the ability to monitor and optimize the business. Tools to help organizations analyze the process flows they have created and how they are being used

18



©2003

will prove invaluable as systems evolve and become more automated. The combination of an event-driven service-oriented architecture, externalized business rules, and process analytics and optimization should provide a solid platform on which to build a lasting architecture.

Hewlett-Packard HP’s strategy and vision is the Adaptive Enterprise – recognizing that the ability to manage change is the key imperative for businesses today, to accommodate and respond to near-term marketplace challenges and to sustain competitive advantage over the long term. HP has developed an enterprise reference architecture that identifies the components and interrelationships needed for an adaptive enterprise: the Darwin Reference Architecture. The Darwin Reference Architecture is based on four fundamental key transformations that are needed for an enterprise to evolve to become an adaptive enterprise. These include:

• Transformation to a service-oriented architecture (especially within application environments)

• Transition to automation in the infrastructure (supported by management and control)

• Transformation to business-focused management and control

• Transformation to a business process environment with a direct communication loop with the IT environment

HP believes that achieving an adaptive enterprise calls for an evolution from today’s environment of silo’d technology that is complex, over-provisioned, and inflexible, to one in which IT assets can be better utilized to achieve an improved ROI for the corporation. The specific approach of any individual organization will be different based on its industry, business strategy, model, competitive and regulatory environment, and IT environment. HP feels that three basic stages are required in the journey to become an adaptive enterprise:

• Stage 1: Stable – an organization must have a stable, available, and secure environment in place as its foundation

• Stage 2: Efficient – where the organization is now optimizing the integration and management of the environment

• Stage 3: Agile – where the organization has achieved business and IT alignment in a dynamic and synchronized way, for seamless response to changing business requirements

HP believes that by taking this approach companies can make adaptive improvements along this continuum in the way that makes most sense for their individual context and situation.



©2003

Application architecture plays an instrumental role in enabling a company’s flexibility. HP experienced this first hand in its merger with Compaq. With the merger of HP and Compaq – the biggest technology merger in history – the respective IT organizations faced a major challenge in determining how to merge their systems to support the unified company’s system requirements. The new company would need to link 1,200 networked sites; 215,000 desktops; 49,000 network devices; more than 7,000 applications; 26 million e-mails a week; and 30 million business-to-business messages monthly. The desired result was a company in which customers and partners would interact with HP as one company; products and solutions would go to market through integrated, global supply chains; the workforces would operate as a single company; IT cost and complexity would be reduced; and the business performance would improve. The widespread understanding and emphasis on an Adaptive Enterprise empowered the two organizations to combine their systems in record speed, surprising pundits and critics. HP has identified a common set of general design principles that drive adaptive improvements for companies at any stage of the Adaptive Enterprise journey, and that underlie all of the Darwin reference architecture transformations. These design principles include simplification, standardization, modularity, and integration. When

these principles are applied to the critical Application Services Layer, they have these characteristics: • Simplification: simplify the

connections between applications and allow components to be re-used

• Standardization: use industry standards such as J2EE, .NET, and SOAP to ensure the maximum flexibility throughout the development cycle and platform independence

• Modularity: use and re-use modular applications to support rapid change, along with easier diagnosis and resolution of problems; swap components with low risk of impact to business services integration

• Integration: improved application and data integration leads to improved response to business change

HP Services developed and is expanding its portfolio of offerings around Adaptive Application Architecture services. Specific services HP offers its customers include:

• Impact and ROI Calculation – focused on identifying and measuring key metrics; developing business case for investments

• Integration Competency Center – provides expertise and services to improve the speed of integration; ensures sound architectural foundation for integrations

20



©2003

• Design and Implementation – pure and simple integration and development services with J2EE and .NET expertise

• Solution Lifecycle Management – includes both software factory management and operations management, which improves re-use of services and operational efficiency

HP is helping customers reach their Adaptive Enterprise goals by working closely with strategic partners and industry leaders, such as TIBCO Software.

Intel Corporation Intel has been responsible for developing some of the most widely deployed semiconductor technology in the world. From central processors, to network technology, to the integrated circuits that make these components work with each other, Intel has long been an innovator and leader in providing innovative technology and solutions to customers.

As a Provider of Technology As a technology provider, Intel has been a leader in creating solutions that have enhanced the network and hardware infrastructures and related architectures for organizations worldwide. Intel central processing units have gained worldwide acceptance for desktop PC, workstations, servers, and mobile and embedded applications.

Intel provides a large variety of the infrastructure components that are required in a service-oriented architecture. Intel’s network technology allows organizations to effectively provide high bandwidth connectivity in both wired and wireless applications. This allows organizations to provide better application and service connectivity to its users. Productivity and customer satisfaction are just two of the benefits gained from efficient and reliable connectivity. For mobile platform requirements, Intel provides solutions such as Intel® Centrino™ mobile technology to enable extended battery life, improved mobile performance on thinner and lighter form factors, and integrated Wireless Local Area Network (WLAN), validated with third party security solutions to provide safer connectivity. Intel has also been working to promote deployment and build awareness of public WLAN services. To address the larger business needs of organizations, Intel also provides consulting services that help organizations:

• Optimize data centers • Consolidate their technology

investments • Optimize e-commerce solutions • Help with migration planning • Educate organizations on the use of

web services



©2003

In the final analysis, Intel provides a compelling, leadership-driven approach to technology that has provided value for organizations worldwide. Intel appears to continuing this leadership with innovation and services to help organizations move toward more open, service-based architectures. As a User of Technology As a user of technology, Intel should also be considered among the top organizations in the world today. For the past year Intel has placed a heavy focus on designing an architecture that will be used to help drive key technology acquisition, consolidation, and development decisions. Intel has divided its vision of a service-oriented architecture into four distinct layers: • Business – Processes and services

that are shaped into dynamic applications that positively affect business value

• Application – Fundamental services that are required to ensure connectivity, reliability, performance, and scalability

• Data – Systems, applications, and data sources that house the information assets within an organization

• Technology Infrastructure – The fundamental hardware, software, and network infrastructure that enable business applications

Intel believes that in the current market, where budgets are smaller and organizations are more risk averse, it is imperative to build a good architecture to deliver higher value with less. To accomplish its goals, Intel has placed strong focus on key enabling technologies in the middleware and application tier of the architecture that was defined earlier. Intel believes in using good off-the-shelf technology where it is appropriate, as is evidenced by its strong portfolio of middleware technology solutions. The middleware tier enables the organization to provide critical business applications that can be used by users worldwide. The key to its entire technology strategy is using a multi-tier services oriented architecture to make key decisions related to the use of technology throughout the organization. In many organizations, business process management technology has proven to provide a high return on investment when properly implemented, and Intel is no exception. Intel feels that the biggest challenge with implementing good business processes is defining the processes and breaking the problem to be solved into small, more manageable pieces. In general, experience shows that organizations that can accomplish this difficult task are over 80 percent more likely to have successful projects than those that bite off too much at one time. Intel agrees and has put processes in place to ensure that the definition of

22



©2003

processes is not a secondary thought, but a driver in the services oriented architecture it envisions. Intel believes that, in many instances, too much focus is placed on creating a homogeneous data infrastructure layer. Many organizations are quickly paralyzed by the daunting task of cataloging, consolidating, and integrating their data systems and related applications. Intel proposes a more pragmatic approach, driven by prioritized business initiatives. Each business priority should be decomposed to determine what data systems are affected and the level of integration required to make the business application work. Once these requirements are identified, they should be reviewed to ensure they fit into the overall architectural vision of the organization. Intel believes that some of the key challenges of service oriented architectures include:

• Security – How does an organization secure the components of a distributed services-based architecture?

• Management – How can individual components be managed across the enterprise in a geographically and logically distributed environment?

• Distribution – How do components in a services-oriented architecture get distributed most effectively throughout an enterprise?

Security must be addressed at a number of levels. First, one must secure the core network and hardware layers so that information is maintained within the control of an organization and the designated extended enterprise. Data encryption must then be implemented to ensure that internal entities cannot access the information unless they are authorized to do so. Finally, authentication and authorization are required to determine what systems people are allowed access, and what they are allowed to do once access is granted. As services are deployed across an organization, management and distribution of those services becomes critical. The first step is to ensure that the service is registered so that it can be re-used frequently. Once the service is deployed and running, management is required to ensure it is running properly and that security is maintained. Once these problems are addressed, it becomes possible to build a dynamic infrastructure that supports intelligent composite applications. Intel believes that applications will be built dynamically and used to solve key business problem as they arise. Proper modularizing of application components is the key to allowing these services to be reconfigured dynamically to provide new and unique applications without even writing a line of code.



©2003

One of the most interesting forward-looking ideas Intel is exploring is distributed computing resource utilization and management. This technology is sometimes referred to as virtualization, and is a key component in architectures that will feature grid computing. The idea behind virtualization is to enable organizations to harness the underutilized computing resources that exist throughout an organization. With advances in distributed computing technology, increases in network bandwidth, better bandwidth utilization, and more effective management of these resources, it is becoming possible to optimize the investments in computer hardware. As with many other successful organizations, Intel is taking a portfolio-based approach to implementing technology. It is using a service-oriented enterprise reference architecture, similar to the one presented in this document, to help make more consistent and more successful decisions related to technology issues. The company has shown clear leadership in many areas over the years, and its usage and commitment to services-oriented architectures bodes well for organizations still considering moving in that direction.

24



©2003

The Final Word As organizations explore the need to minimize unnecessary technology spend, they will undoubtedly begin looking into the vast benefits of using a service-oriented architecture. This white paper should make it apparent that there is much more to a service-oriented architecture than standards such as web services. An adaptable and cohesive service-oriented architecture should be designed to be a dynamic part of an organization’s infrastructure. Technology is only one component of a lasting architecture. Executive-level buy-in, as well as support from business users and business units, is absolutely critical to ensure success. Organizations will certainly choose their own pace when it comes to implementing components of a service-oriented architecture, but it is important to start with manageable projects. Organizations will also have a good selection of providers, such as the providers featured in this document, to partner with to help move them toward a dynamic, service-oriented infrastructure.

For an organization, the end goal should be the ability to understand how it conducts business at a process level and to be able to optimize those processes. The goal of optimization should be to minimize costs and unnecessary investments, while maximizing value to customers, partners, and the organization itself. If an organization can start to look at a business problem holistically – from the business level all the way down to the technical implementation – it can become more agile and better able to serve customer requirements, while always leveraging its investments in people, processes, and technology.



©2003

Appendices The following appendices provide more technical detail on how an enterprise reference architecture would be implemented. They provide a detailed technical architectural view that builds on the business-level model presented in the main document. This technical design addresses the issues related to the individual components and services required to achieve the goals of the dynamic enterprise reference architecture.

Appendix A: Technical Implementation of an Enterprise Reference Architecture A service-oriented architecture is defined as an architectural strategy that seeks to componentize critical functionality into small, operationally independent pieces that can be executed remotely and in a highly distributed manner. As with any enterprise architecture, service-oriented architectures require careful planning and a holistic approach that takes into account the effect of the architectural approach across all layers of the architecture. Previously, this paper presented a business view of the enterprise reference architecture. When it comes to

implementation, a more detailed technical view is required that shows the technology layers that are involved in the architecture. Layers are architectural constructs that are used as a mechanism to provide isolation between a set of components. They provide the ability to change underlying components without affecting how other resources use them. As stated previously, these layers include: • The enterprise data and application

layer, which consists of the existing technology investments made by the organization. The rest of the architecture relies on this layer for the critical application functionality and data that is used to drive business processes throughout the organization. At a technical level, this layer includes all network and hardware infrastructure that supports the business applications and data systems within the organization. From a network perspective, everything from network protocols to physical routing and switching equipment will need to be addressed. Key concerns in the network layer include reliability, load handling, and connection latency. Hardware in this layer includes the server infrastructure and the detailed implementation of this server hardware. Hardware services that affect the behavior of the infrastructure, such as self-healing

26



©2003

and failover features, should be considered within the architecture.

• The data services layer, which

provides a set of services that allow organizations to extract and re-use data from the enterprise application and data systems in the organization. The data services layer isolates the organization from changes in the underlying data systems and applications, as well as providing a unified approach for accessing the data and functionality of those systems. At a technical level, this layer is the foundation for access to functionality and data that exists within and potentially outside of the organization. This layer provides the information needed to drive process automation and ultimately a dynamic enterprise.

• The application services layer,

which is designed to provide the functional components and technologies that are used to ensure high levels of application scalability, performance, and reliability. Application components are managed in this layer to ensure that they are secure and available to other parts of the architecture when needed. At a technical level, this layer contains the software server components, such as application server technology and messaging buses to run application effectively in an enterprise environment.

• The business services layer is where technology meets business. In this layer, applications are composed from a combination of business processes, business rules, human workflow, and the services exposed by the application services layer. At a technical level, this layer is where applications are composed from services and data that are exposed throughout the enterprise through the application and data services layers.

• The presentation and interface services layer, which provides users and external systems a way to communicate and interact with business processes and business applications. At a technical level, this layer is where information leaves and enters enterprise systems. Standards are a key driver for what happens within this layer.

• The event services layer, which gathers event data across the enterprise and also across all of the layers of the architecture. The events are then used to drive dynamic business processes and dynamic changes in the underlying layers to provide better performance, reliability, and scalability. At a technical level, the event services layer provides a standardized mechanism to publish and subscribe to critical events that drive dynamic applications.



©2003

• The enterprise lifecycle services layer, which provides a mechanism to effectively design, model, assemble, develop, deploy, maintain, analyze, and optimize business processes and related system and applications.

These layers work together and interact to provide a mechanism to quickly adapt to changing conditions within the enterprise. For example, a hardware failure may result in an alert to an administrator, while simultaneously launching a deployment of new services to existing healthy servers in order to maintain a minimum quality of service level. Understanding the roles that each of these layers play is critical to an organization’s ability to maximize its current and future technology investments. It is also critical to finding ways to reduce costs through simplification and redundancy reduction. The following subsections address the components and the design of each of these layers in more detail.

28



©2003

Ente

rpri

se A

pplic

atio

nan

d D

ata

Syst

ems

Grid Computing Resources

Servers Storage

Network Devices

Application Servers / Clusters Edge Servers DASD RAID SAN NAS Optical/ Tape

Workstations

PeripheralsPrinters ScannersIVR/

TelephonyRouters Switches

Hubs

Firewalls

Load Balancer System Monitor

MobilityServices

Dat

a S

ervi

ces

AdaptersWeb

Services

RDBMS

Component

App

licat

ion

Ser

vice

s

Universal Abstraction Layer

Grid Computing Resource Mgr


LoadBalancing

PersistenceServices

Caching

SchedulingDevelopmentSupport

FailoverResourceManagement

SecurityDeploymentServices

Content / Directory ServicesDirectory

(User / Content / Resources / Metadata)

Repository(User / Content / Resources / Metadata)

Data Modeling Legacy DataAbstraction

Legacy

Custom API

Interaction ServicesGlobalization ./ Language Services

Page Navigation Manager

Data View Manager

Personalization Engine

Data / Interface Transcoding

InfrastructureManagement /Instrumentation

IntegrationTransformation

Translation

Messaging

Process

Workflow Process Automation Rules Engines

Business MonitoringBusiness Intelligence / Reporting

Real-time Analysis

Business / InstrumentationTranslation Engine

Automated Business Response

Bus

ines

sSe

rvic

esPr

esen

tatio

n/In

terf

ace

Serv

ices

Presentation ManagerPortlet

Thick Client

Thin Client

Mobile Device

Even

t Ser

vice

sApplications / Data Systems

Data Access Interface

Process Access Interface

Presentation Interface

Programmatic Interface

Instrumentation

Management

Ente

rpris

e Li

fecy

cle

Serv

ices

Des

ign

/M

odel

ing

Asse

mbl

y /

Dev

elop

men

tD

eplo

ymen

t /M

aint

enan

ceAn

alys

is /

Opt

imiz

atio

n

Even

tA

ggre

gatio

nEv

ent

Sequ

enci

ngE

vent

Cor

rela

tion

Rea

l-Tim

eE

vent

Proc

essi

ng

Figure 2 – Service-Oriented Enterprise Reference Architecture (Source: Doculabs)



©2003

Appendix B: The Technology Layers of an Enterprise Reference Architecture This section provides additional technical details on the layers of an enterprise reference architecture.

Enterprise Application and Data Layer As shown in the preceding figure, the core components in this network and hardware focused layer include:

• Servers – In an SOA or grid computing model, servers are seen as shared processing resources. Types of machines an organization is likely to have in this layer include the application servers (either standalone or clustered), edge servers, and potentially workstations.

• Storage – Storage can take on many forms, from redundant array of independent disk (RAID) arrays, to traditional direct access storage device (DASD) and Network Attached Storage, as well as storage area networks (SANs) and optical/tape output.

• Network Devices – These are traditional components such as routers and switches, as well as load balancers and system monitors.

• Peripherals – Enterprise peripherals such as scanners and printers can also be treated as shared components in the SOA stack.

The critical objective for hardware and network components in a services-oriented architecture is to provide a consistent architecture to allow for portability and the ability to distribute components in a flexible, manageable manner. In order to take advantage of SOAs, companies must organize their underlying systems platform for scalability and agility. Architectures must provide high performance and rapid scalability, and must also be able to change to accommodate emerging requirements. The keys to an agile infrastructure investment for Internet services deployment are to prepare a transaction/user scaling model, develop a comprehensive architecture, deploy on a flexible infrastructure, and monitor performance, while being prepared to adapt to changing loads and emerging requirements. Networks enable services by integrating legacy and new applications through application servers, and this infrastructure must be optimized for agility and scalability. Generally, customers will demand a services-based infrastructure approach that features an n-tier architecture, heterogeneous legacy integration, multiplatform Java technology, and a multi-level security model.

30



©2003

Many organizations that are seeking to move to SOAs are migrating from static, complex architectures to a necessarily flexible model. In the late 1990s, building high-performance Internet services meant splitting things up, and decomposing functions at both the service and task layer. Typical architectures take a “silo” or partitioned approach: dividing each separate service onto separate hardware and each layer of that service – the web server or the database server, for instance – onto separate hardware, because these systems are divided into discrete components that can be readily scaled. In addition, availability is often provided through dedicated, box-level failover for each component. The drawback of this design is limited flexibility. Although this silo architecture can provide high performance, its limitations emerge when the need to provide a new service requires creation of a new and separate silo. In addition, the excess resources included for availability are isolated in the subcomponents and cannot be readily repurposed. Applications are built one at a time, with little opportunity for re-use or integration, let alone interoperability with other organizational divisions or with external partners. By contrast, what is required for SOA is an architecture that can scale rapidly and can add new services or rebalance existing services in a highly flexible

manner. This is achieved by design of an architecture built on a common services infrastructure and deployment of this architecture on a consistent, universally deployed physical architecture. This approach is very similar to the “fabric” concept that underlies grid computing models. These models are extremely applicable to the SOA concepts, in that they share the same goal: that of a ubiquitous processor and storage pool that can support any service. Already, industry leaders in the traditional application server arena are taking notice of grid computing as a complementary extension to web services and service-oriented architectures. Two of the critical requirements to support this vision at the hardware and network level are symmetric multi-processing and self-repairing capabilities.

Clustering and Partitioning Organizations are looking for ways to provide highly available and reliable infrastructures without making extremely large investments in hardware and software. Clustering and application partitioning are methods that are used to provide reliable and available infrastructures at relatively low cost. Clustering allows a group of servers to appear as a single unit. Benefits include simplified management, improved fault tolerance, and better scalability. A larger number of less expensive systems can replace a



©2003

smaller number of monolithic systems and provide comparable or superior performance and reliability. To further improve availability and scalability, application components can be deployed across a group of servers and accessed seamlessly across a network. This arrangement can significantly improve performance as more component instances can be started during peak times across a larger number of systems. During non-peak volumes, the system processing power can be used for other applications or tasks. This capability is important in SOAs because of the need to distribute and execute services irrespective of location.

Self-Repairing Capability Self-repairing networks include dynamic routing and recovery algorithms that allow distributed networks to detect faults in the node connections and to find alternate routes, or to re-establish links without operator intervention. This capability relates to the multiprocessing capability discussed above in that the distributed loads managed through multi-processing can be better served with an adaptive infrastructure. A complement to this is network-based load balancing, which can be leveraged in a self-repairing environment to distribute processing loads dynamically.

Eventually, technology assets such as routers and load balancers will become more “aware” of their roles related to business applications. As network and hardware providers build more intelligent equipment, it will become possible to diagnose and profile applications against the hardware to further optimize performance and quality of service levels.

Data Services Layer This layer turns data systems and existing business application into useful information to be consumed by users and systems in the application services and business services layers. The data services layer simplifies and speeds access to information and also to provide the data that helps orchestrate processes across applications and even across organizations. Without data services making sound business decisions would be impossible. Key components of this layer include: • Adapters to data and applications • Data modeling • Legacy service abstraction

32



©2003

Adapters To combat the need for organizations to build and re-build connections to well-defined systems and applications, adapters – a breed of off-the-shelf software technology – emerged to ease this particular customer pain. Adapters are generally self-contained components that provide a mechanism to connect to specific types of data and systems. Adapters can be as simple as file access adapters that allow the reading of a text file from storage media, or as complex as a rules-driven data access component that connects to an enterprise resource planning (ERP) system using one or more protocols. The core benefit to using a pre-built adapter from a reputable solution provider is that there is usually an understanding that the solution provider will ensure rapid updates as data systems and applications are updated, freeing an organization from the messy task of building costly one-off integrations with their systems. The types of adapters available on the market today include the following: • Relational database adapters –

These adapters typically are available ubiquitously and are inexpensive or free. They take advantage of one or more common relational database access technologies, including native drivers, JDBC drivers, or ODBC drivers, to name a few.

• Legacy connections – Specialized adapters are available that allow access to common legacy applications.

• Custom Application Programming

interfaces (APIs) – The majority of adapters for legacy systems and applications take advantage of existing APIs and related programmer interfaces exposed by the legacy or specialized application. One example is SAP BAPI, a programming interface exposed by the SAP ERP system to allow developers to access or extend the functionality of the core product.

• Component technology-based

adapters – Many modern applications and systems provide interfaces to data and functionality, using commonly accepted standards for application component technology. The most prevalent today are Enterprise Java Beans (part of the Java 2 Enterprise Edition specification by Sun/JavaSoft) and Component Object Model (part of Microsoft’s .NET application framework). Some organizations still use CORBA technology, but the number of users is dwindling.

• Web services – Rather than a radical

new technology, web services provide a way to simplify access to data and applications by leveraging existing technology.



©2003

Data Modeling Effective use of the data in an organization’s systems is contingent upon a clear understanding of the interrelationships between the data elements. Data modeling tools are used for a number of purposes, including the creation of metadata that describes the relationship of data. A solid data model allows for quick and easy access to information across the enterprise in a well-defined and common way. Legacy Service Abstraction One of the biggest hurdles organizations face is making their generally monolithic legacy applications useful in business processes and new business applications. The ability to break a larger legacy application into functional services is a daunting task that can be accomplished via programming, or by leveraging technology such as application adapters to introspect and extract only those services required to get to the functionality and data required by a process or application.

Application and Business Services Layer These two layers provide the critical infrastructure and process automation technology to keep business applications running efficiently and reliably within an organization. These layers also provide the fundamental utility services such as messaging that are leveraged in all other layers of the enterprise reference architecture. Without application and business

services, providing applications and services for use across the enterprise would be impossible. Many components and services come together to form application and business services, including: • Abstraction layers • Event services • Grid computing and application

resource managers • Application services • Content / directory services • Integration and process

management services • Infrastructure management and

instrumentation

Abstraction Layers The usefulness of middleware services is limited in a service-oriented architecture if those services are not easily accessible by all parts of the architecture. As technologies evolve, it is critical to shield applications from the volatile nature of key technology components by using abstraction layers. Examples of these components include data access adapters, workflow engines, security services, and content repositories. Abstraction layers are simply standardized interfaces that are used to communicate with underlying sub-systems and components. These abstraction layers do not change significantly over time, from the perspective of the consumer of service.

34



©2003

A good example of an abstraction layer is a Java Database Connectivity (JDBC) or Open Database Connectivity (ODBC) database driver. Developers can access a variety of generally proprietary database technologies using the same metaphor and access mechanisms. In the ideal case, swapping out one vendor’s database for another would not require any changes to code that calls the standardized JDBC or ODBC layer. Properly creating abstraction layers for each componentized service allows for flexibility in the future. Individual components can be swapped out at will and replaced by standalone or customized components at any time. Properly designing abstraction layers also allows an organization to leverage its existing resources and skills more effective by focusing them on smaller parts of a large problem, making it easier to manage and increasing the likelihood of success. The goal of using abstraction layers is to define coarse-grained services and business functions that are derived from existing legacy systems and applications, that are frequently monolithic and not very service oriented.

Grid Computing and Application Resource Managers Service-oriented architectures tend to componentize functionality into small pieces that can be executed remotely

and in a highly distributed manner. Until recently, many organizations have struggled with understanding how to take advantage of their vast computing resources that sit idle 80 percent of the time, and peak with usage (with server- crashing results) at other times. Grid computing promises to provide a mechanism to harness that idle computing power to serve applications that need additional computing resources, irrespective of their physical location. Service-oriented architecture becomes much more attractive once grid computing technology begins to be adopted. Well-developed service-oriented applications should maintain high performance, scalability, and reliability at all times, while also having favorable management and deployment costs. To take effective advantage of grid computing, the middleware tier must have a management system that can introspect and make decisions about the proper deployment of service components across a computing grid. For example, during peak loads the manager may determine that quality-of-service levels are dropping below minimum levels, and may initiate a deployment of key web service components onto idle server resources. Once the peak period has passed, the components can be uninstalled automatically.



©2003

The primary benefit of a grid-based service-oriented architecture is a dramatic reduction in the cost of server hardware (i.e. an organization can buy more, but less expensive, servers that can easily be replaced at a low cost).

Application Services Until recently, application services were something that developers were responsible for creating whenever they built a new application. Application server technology introduced the idea of a server-side framework that provided key services to any application built within the container. The evolution of application server technology has been quick, and adoption has been rapid. Basic services such as security and caching technology should be addressed by a good service-oriented architecture, and these services should be exposed for use across the middleware tier.

Content/Directory Services Organizations have large amounts of structured and unstructured data in their systems. The most effective application can seamlessly access both structured and unstructured data. Today, accessing this data is a daunting task and in many cases is possible only if the application developers also have ownership of the data they are accessing. In a service-oriented architecture, it will be critical to provide tools to locate key information in data

stores and systems at a very granular level. Today, a number of different standards surround the storage of information in repositories, as well as standards focused on the cataloging, look-up, and retrieval of this information. For user authentication and access control information, it is common to use a Local Directory Access Protocol (LDAP) directly. Web content may be accessible through a proprietary web content management API or through standards such as WebDAV. A service-oriented architecture will require a unified or federated repository that houses information about both structured and unstructured data in a single repository. This will allow organizations to compose applications more easily and truly benefit from re-use across the organization. A metadata repository will become critical in a lasting service-oriented architecture. Among other things, the repository would: • Hold data required to understand

the interrelationships between data and systems within an organization

• Provide a place to look up and request services

• Maintain a business process library that could be queried or updated as needed

36



©2003

• Hold business rules that could be reviewed or modified by authorized users

The metadata repository may consist of one or more physical repositories, but it would work to provide a unified view onto the process, application, and data resources within an organization.

Integration and Process Management Services One of the core functions of the middleware layer is to provide access to information that may exist in legacy and modern systems and applications and to use it to affect process automation and enhance the value of applications. The integration problem is complex in most organizations, since there are literally thousands of existing legacy systems and applications, and an almost limitless number of custom applications, in the world today. In the past it was common for applications to build “one-off” connections to any systems they needed access to. Although this technique worked, it was costly to develop and even more costly to maintain, as changes in the underlying applications forced changes in the custom data access code. Once the data is available, it is critical to have services to be able to use the data to drive automated processes to reduce the reliance on human interaction. The following key technologies are required to make such automation a reality:

• Process engine – The process engine can take a defined process flow and manage the automated flow of information through the defined process.

• Workflow – Workflow provides a mechanism to enable human interaction when necessary (e.g. exception processing, manual approvals)

• Rules engine – Processes by themselves simply move information from step to step. Rules engines allow decisions to be made based on predefined rules that act on data. These rules work independently from processes; this allows higher-level users (business users) to make dynamic changes to the infrastructure quickly, efficiently, and safely.

Infrastructure Management and Instrumentation As computing infrastructures become more complex and potentially more geographically dispersed, management of applications, components, and services becomes a very complex task. Unless the proper management and instrumentation interfaces are put in place early on, an organization is likely to face high management costs and potentially application failure. Instrumentation in the middleware tier must collate data from the network and hardware layer and relate the data to services and processes that are running



©2003

on the middleware tier. The aggregate data should be invaluable in understanding the problematic areas in an application and provide some insight into how to fix the problem and manage the overall solution more effectively. Management of services must also be a seamless and painless process for administrators. The management interfaces should provide rules-based alerting and provide a mechanism to take simple action when problems arise, such as hardware failure or slow application response time.

Presentation and Interface Services Layer Many businesses gain competitive advantage through the effective use of applications and data systems. More efficient integration between these systems and the ease of use of these systems boost their value to business and improve the productivity of the knowledge workers that use them. The business services, application services, and data services layers are where these application and data systems reside in the dynamic enterprise reference architecture. However, more than any other layer, the presentation and interface services layer can entice users into adoption or push them away once and for all. It is critical to a good architecture to provide strong services related to the presentation of content and applications to the ultimate end users.

This also holds true when presenting information designed to be consumed by other systems and applications. Oftentimes these applications lie outside of the enterprise, so providing consistent, well-formed data is important in maintaining relationships with the owners of those systems. There are two key factors involved with the presentation layer: applications and data systems, and people. Applications and Data Systems Standards are the foundation for exchanging information between two or more systems. Everything from the network protocol used, to security mechanisms, to the data formats used, determine how well systems communicate with each other. Data validation and reliable and secure transport of data are of key importance in this architectural layer. People Information workers are most likely to react to the presentation and interface services layer, their primary mechanism for interacting with processes and applications. The problem for an organization is compounded by factors such as user experience levels, user location, user browsing device or software, and pre-conceived expectations.

38



©2003

Event Services A complete service-oriented architecture requires event management services. An event-driven architecture allows services and applications to react to stimuli from systems, applications, and to other people, both across and outside of the enterprise. Unlike traditional architectures, event-driven architectures provide a mechanism for systems to take action when stimulated by pre-determined or ad hoc events. An example of an event may include the failure of a business process, such as the execution of an order, or could be as technical as a failure processing thread in a Java virtual machine running on a server. These events are published, and systems and applications that are interested in receiving events can subscribe to get these events as they happen. A service-oriented architecture that leverages events provides the dual benefit of being dynamic and quick to react to changes in the extended enterprise. A number of services are required to provide a full-featured, event-driven architecture. The key services include: • Real-time event processing – the

ability to process events as they arrive rather than on a scheduled or manual basis; this ability allows the organization to react immediately to changes in the environment

• Event correlation – the ability to take events from a variety of systems and processes and relate them to each other intelligently; this allows for seemingly unrelated events to be correlated to effect change in the environment

• Event sequencing – the ability to take events that may arrive out-of-sequence and intelligently reassemble them

• Event aggregation – the ability to group events together to analyze and make decisions based on the sum of events

Together these services allow organizations to achieve a dynamic enterprise that changes to meet customer and business demands.

About TIBCO

TIBCO Software Inc. (NASDAQ:TIBX) is the largest independent business integration software company in the world, demonstrated by market share and analyst reports. In addition, TIBCO is a leading enabler of real-time business, helping companies become more cost-effective, more agile and more efficient. TIBCO has delivered the value of real-time business, what TIBCO calls The Power of Now®, to over 2,000 customers around the world and in a wide variety of industries. For more information on TIBCO's proven business integration, business optimization, and enterprise backbone solutions, TIBCO can be reached at 650-846-1000 or on the Web at www.tibco.com.

About Doculabs Doculabs, Inc., is a technology consulting firm backed by research and extensive client experience. Our services lower the business risk of technology decisions through client-specific recommendations, objective analysis, and in-depth research. Founded in 1993, Chicago-based Doculabs provides consulting services that are based on our fundamental belief that in order to protect a client’s long-term interest, technology advisors should not be implementers.

Doculabs helps clients deliver on their business objectives through customized services that address technology initiatives related to business challenges in areas such as strategy development, technology acquisition, and go-to-market initiatives. Doculabs’ consulting services are completely objective because the firm does not sell software or integration services. For over 10 years, our research methodology has provided customers facing mission-critical challenges with the information and advice they need to make confident and well informed decisions.

Hundreds of leading organizations within the Fortune 1000 – from financial services companies to major technology software providers – have turned to Doculabs for assistance with their technology strategies.

For more information about Doculabs, visit the web site at www.doculabs.com or call (312) 433-7793.

120 South LaSalle Street, Suite 2300 Chicago, IL 60603

(312) 433-7793 www.doculabs.com

E-mail Doculabs at: [email protected]

Education

Planning and Building an Architecture that Lasts: The Dynamic