In these days of continual new product introduction and massive hype, it is easy to lose track of the purpose and long-term strategic goals of business applications in favor of tactical solutions. While computer scientists have offered comprehensive models for enterprise computing for several decades, these models are often too all encompassing for normal IT management to implement. A far better approach is to base purchasing decisions on a flexible, modular applications component architecture that allows pragmatic decisions, accommodates the past, and prepares organizations to move to a hypertier component model of computing.
The hypertier is a conceptual model for understanding and building structured applications that uses a network-centric infrastructure. The premise of the hypertier model is that an organization's collection of networks, data, applications, clients, and servers can be dynamically connected and disconnected in response to user needs. With the hypertier model, both end users and developers can have access to data and logic in any fashion and at any time, whether it is a new Internet application, a client/server application, or a host-based component.
The software industry is beginning to consolidate around a distributed model of computing based on applications integration, componentization, and specialized packaged software. A key consideration for corporate development is selecting an applications architecture that can sit underneath an organization's strategic software assets. This emerging applications architecture should ensure that organizations are protected from the inevitable evolution of the dynamic software industry. Organizations that establish a standards-based applications architecture will be far better equipped to thrive on this change and to maintain their competitive edge.
An applications architecture is a set of standardized services that isolates specific applications from change and allows the interchange of data and logic across services and components. While an application architecture can be tightly linked to an operating system (such as Windows NT or a host), the underlying assumption is that interoperability is more important, in many situations, than standardizing on a single platform. There are exceptions, however. For example, there may be a specific application or implementation where an organization might deliberately decide to leverage a single platform architecture because of implementation speed or internal skills.
As long as the organization understands the limitations of its choices and plans for the interoperability of architectures, there is no problem with this approach. You can use an all-Microsoft architecture based on COM and services such as MTS and MSMQ, for instance, in conjunction with third-party bridges to link to non-Microsoft environments. Packaged applications are another example. For most organizations, selecting a packaged application is more economical than building one with a set of low-level tools. However, while the selection process is based primarily on user-driven features and functions, the organization has acquired an underlying architecture by default. Organizations need to plan for applications integration outside these closed architectures.
While an applications architecture requires considerable flexibility, there are some key services that organizations should begin to standardize on for the future. Do not expect to be able to implement everything at once. But establishing these services up front will help your organization plan a roadmap for selecting products and technology. The following are services that you should consider.
Data models and metadata. Many organizations are beginning to establish a metadata catalog that includes simple data definitions (such as the standard definition of a customer across heterogeneous applications). Without these models, it is impractical even to attempt to analyze and monitor data across applications. Over time, this catalog can migrate into a more sophisticated model for creating a corporate repository that maps definitions to sophisticated rules and behavior. In an electronic business world, this mapping will encompass partners and suppliers.
Business process logic. There is substantial business-critical logic within existing applications that you must maintain to ensure adherence to consistent operations across an organization. For example, the techniques for calculating a 30-year fixed mortgage will not change with time and should be used, rather than rewritten, for each application. Identifying and using this key business logic should be a core requirement. This logic isn't limited to legacy or custom-built applications. Most organizations also implement packages that impose a business process or workflow strategy. It is quite common to have a package dictate the way a business runs rather than having the business drive software. In some cases, a company is simply too busy getting work done to think carefully about how it wants to structure processes. While this is not necessarily bad in the short term, organizations must be able to extract the business process model from these applications in order to accommodate inevitable business changes for effective long-term benefit. Without this capability, organizations using packages with integrated services and workflow will be unable to adapt rapidly to emerging new business models and practices or to support changing user requirements.
Middleware for messaging, transactions, and event management. Middleware provides the enabling technology and coordination services within an applications architecture. It supports applications integration at a fundamental level by enabling communication between components within existing applications and between disparate applications and resources. Middleware must not only link applications and components but must also provide IT organizations with access to transaction services and support mission-critical services itself, including messaging, advanced queuing and routing, guaranteed delivery, and message transformation. Most important, however, is support for abstracting the complexity involved with providing these services. Without this abstraction, middleware will remain too complex and low level for the majority of IT organizations to implement successfully.
Management services. Applications are becoming larger, more complex, and more distributed. At the same time, requirements for application availability are increasing as companies deploy more mission-critical applications across intranets, extranets, and the Internet. A distributed infrastructure therefore requires careful attention to how applications are managed when widely deployed. Management services must provide support that spans development to deployment and maintenance. Runtime version management, for instance, is required so that all users are equipped with the latest versions of services. Other mandatory management services include the incremental distribution of updates and repairs, automated desired-state management, and integrated performance monitoring and management support.
Security model. Security must pervade not just an individual distributed component, but also the middleware and applications integration framework itself. Organizations need to consider five areas: network integrity, system integrity, user account integrity, application and data integrity, and data confidentiality and privacy. Specific functionality within these areas that must be included within an applications architecture include user authentication and access control, firewalls, encryption, and virus detection.
Repository Support. Repositories are software mechanisms that enable the storage, manipulation, and management of components, including application services and business logic. Repositories also contain critical information, or metadata, about components and component interfaces as well as information about specific systems, including object designs (such as UML diagrams) and database definitions. To be effective, a repository must be logically unified but not necessarily physically monolithic. In fact, a repository implementation can range from a single database to many widely distributed databases of different types.
We have covered a large number of architectural considerations for building a flexible enterprise architecture that can help companies move to an electronic business future. Following this hypertier component model isn't as overwhelming as it might seem at first glance. There are several initial steps that organizations can take to make the transition less painful. The following are our recommendations:
There is up front work to do to transform your IT infrastructure from a traditional application model to an applications architecture. However, once you start down this path, you begin to establish an approach that will let your organization quickly transform business models in an increasingly competitive market.