Beruflich Dokumente
Kultur Dokumente
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 organizations 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: info@doculabs.com
2003 Doculabs, 120 South LaSalle Street, Suite 2300, Chicago, IL 60603, (312) 433-7793, info@doculabs.com. Reproduction in whole or in part without written permission is prohibited. Doculabs is a registered trademark. All other vendor and product names are assumed to be trade and service marks of their respective companies.
Whats 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.
Introduction
Defines a service-oriented architecture and its components and characteristics, and discusses the role of new approaches to an enterprise reference architecture.
10
14
17
24
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.
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, todays 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 organizations existing investments in technology and systems are leveraged rather than replaced
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.
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.
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
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 nonevent-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
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 todays 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. Todays systems are capable of capturing vast amounts of
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.
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 reinvestment in development. The architecture should provide a clear approach for integration and access to these systems.
Organizations were locked into choosing solutions that may not fit with the constantly changing nature of their business. 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. 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.
By taking these issues into account, todays 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 organizations existing investments in technology and systems are leveraged rather than replaced.
10
11
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
Business Services
Design / Modeling
Business Process
Human Workflow
Event Services
Business Rules
Application Services
Application Containers Message Bus Metadata Repository
Analysis / Optimization
Standard Interfaces
Data Services
Legacy Service Abstraction Data Modeling
Application Adapters
Instrumentation
13
Technologies
Enterprise resource planning Content management Mainframe and legacy applications Customer relationship management and call center systems
Sample Providers
SAP, Oracle Applications, and PeopleSoft Documentum, Interwoven, and Vignette Fraud detection systems, telecommunications provisioning applications, etc. Kana and Siebel Actional, iWay, TIBCO, and WebMethods BEA, Rational, Sybase, Teradata, and TIBCO Microsoft, Oracle, Teradata, and TIBCO IBM, Sonic, and TIBCO BEA, Borland, IBM, Microsoft, and Oracle Java standards, .NET standards, web services, etc. IBM, Oracle, Teradata, TIBCO, and custom repositories
Data Services
Application and data systems adapters Data model and persistence engines Legacy functionality extraction
Application Services
Business Services
Fuego, Fujitsu, IBM, Microsoft, and TIBCO Ilog, Pegasystems, and TIBCO Fujitsu, IBM, Staffware, and TIBCO
IBM, Microsoft, Novell, Oracle, Plumtree, Sybase, TIBCO, and Vignette WAP, WML, Java, etc. EDIFACT, ebXML, other XML, etc.
14
15
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 companys 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 serviceoriented approach does not require redeveloping 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
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.
17
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
TIBCO
As a provider of technology, TIBCO has offered highly scalable, reliable, and high-performance solutions for missioncritical 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
18
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.
Transformation to a business process environment with a direct communication loop with the IT environment
Hewlett-Packard
HPs 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:
HP believes that achieving an adaptive enterprise calls for an evolution from todays environment of silod technology that is complex, overprovisioned, 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
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
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.
19
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
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.
21
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
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 serviceoriented 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
22
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?
23
24
25
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.
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
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.
27
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 organizations 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
Presentation Manager
Portlet Thick Client Thin Client Mobile Device
Event Aggregation
Process
Business Monitoring
Business Intelligence / Reporting Real-time Analysis
Business Services
Workflow
Process Automation
Rules Engines
Application Services
Translation Messaging
Page Navigation Manager Data View Manager Personalization Engine Data / Interface Transcoding
Application Services
Deployment Services Development Support Resource Management Persistence Services Load Balancing Caching Security Scheduling Failover
Data Services
Adapters
Web Services RDBMS Component Legacy Custom API
Data Modeling
Event Correlation
Analysis / Optimization
Integration
Transformation
Interaction Services
Globalization ./ Language Services
Event Services
Assembly / Development
Event Sequencing
Design / Modeling
Doculabs Marketfocus Report Appendix B: The Technology Layers of an Enterprise Reference Architecture
This section provides additional technical details on the layers of an enterprise reference architecture.
29
The critical objective for hardware and network components in a servicesoriented 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
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
31
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.
32
Adapters To combat the need for organizations to build and re-build connections to welldefined 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.
33
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
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 vendors 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
35
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 reuse 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
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 oneoff 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:
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
37
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
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, eventdriven 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 serviceoriented 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
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-8461000 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 clients 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: info@doculabs.com