In this part deux , I want to emphasize on the need for unified Integration methodology. Lets see how integration technologies play a major role in Technology alignment to Organization objectives.
IT strategy based on a global requirements management process
To meet the business needs of single and associated projects, especially when planning to take advantage of shared infrastructure to deliver cost reductions and operational resilience, a well-defined IT strategy and supporting architecture must exist. This IT strategy is the basis for deriving IT initiatives and concrete IT projects. The IT strategy defines the large-scale action plan (programme) and includes products to the business (IT services offerings) and IT business areas, platforms, architectures and technologies, methods and tools, competencies and IT processes that are the basis of a shared but responsive infrastructure.
The IT strategy definition must be based on a proper business requirement identification process. IT requirements cannot be defined independently from business requirements; business process requirements and IT solutions must be developed jointly and coherently. In customer management projects it is common to translate business needs too quickly to IT application selection, ignoring the importance of people, processes and other key issues, which usually have a more immediate effect on project success or failure.
A consistent and well-managed approach to governance for customer management activities and underlying systems transformation is required for programme success. This should provide a consistent view of prioritized business processes across the organization, and requires an overall view of all IT systems involved in that programme. This is important for the technical, business and financial success of the programme. A good architecture enables the exploitation of existing systems in conjunction with new application investments. The same architecture must support all the initiatives of the company (not only customer management) in an integrated and shared manner. The architecture must also provide the basis for future developments, although in many cases future technologies and technology applications cannot yet be envisaged. A good architecture will achieve these objectives through use of sound integration technologies, enabling flexible and prioritized integration of data, real time and other messaging, onscreen applications (eg portal and portlet) and workflow concepts. Industry data models and common interchange standards (eg XML) have an increasingly important role to play here.
Enterprise architecture management includes the analysis of the current application portfolio and the identification of areas for improvement, and the definition of a unique business, application and infrastructure architecture across the enterprise. The management of processes to create this unique view with the relevant architectures is called IT governance.
Most of today's enterprises have to deal with a heritage of poorly integrated technologies. By 'technology' we mean all aspects of applications, platform categories, operating systems and middleware including application servers, transaction monitors, user interface platforms, messaging and extract-transform-load middleware, database management systems, or programming language environments. A company may have a variety of products within these categories from different vendors in different releases.
Reasons for poor integration include the following. For application selection or custom application development, the major issue is the lack of coordination of (internal) development efforts. The trend to moving responsibility for application selection or development towards business units often has the undesirable effect that each project team makes its own technology decisions, undermining enterprise flexibility, cost reduction and operational resilience. But even without this general trend, development often becomes dispersed within the enterprise.
Second, for the integration of application (component) products, the major issue is the dependency of each such application component on a given technology, or the application component may bring its own technology components, making the problem worse.
In considering the consequences of poorly integrated technology, we need to distinguish whether the technology is used 'locally' to applications or whether it serves as a shared application integration platform. With the increasing need for application integration, there is a trend to view more technologies as potentially local to application components (eg a programming language/environment or a database system). The application component then only reveals its interfaces in a way that is neutral to these technologies (eg as WebServices with only functional interfaces). Varied, poorly integrated technology local to applications leads to increased cost of ownership, including (additional) investments in skills, licences, maintenance, or bug tracking. It can also make integration of application components much harder and more expensive, and might even completely undermine the business case for such integration. With the growing demand for e-business solutions which span a single enterprise, poorly integrated technologies create additional problems, for example in inter-business processes.
Explore the Integration Capabilities
The capabilities needed to address the above issues fall into two categories: first, those used to unify technology and architecture decisions within the enterprise wherever feasible, and second, those used to manage heterogeneity where necessary, since it may be too idealistic (or naive) to aim to avoid heterogeneity completely.
The first category requires process and architectural capabilities. The most important process requirement is for strict architecture and technology management processes and for a delegation of decision responsibilities, which is enforced by these processes - the governance model. There are very different approaches to such models, depending on a company's organization and culture. The introduction of a particular model usually requires organizational and cultural change. Models include a centralized technology management department with decentralized development units (where development may take place in the business units), a centralized development unit ('production line') including technology management, or decentralized development with technology/ architecture boards.
If an effective architecture management process is in place, the remaining threat to uniformity of architecture arises from technology evolution. Evolution, including the evolution of technology standards, is still extremely dynamic, with significant new technologies being introduced every year. Many evolutionary steps do not introduce significantly new architectural principles, though. Consider, for example, the chain of DCE, CORBA, EJB (as part of J2EE) and WebServices. All are models for distributed computing, all have to reinvent, replicate or reuse solutions to the tough but common problems of security and transaction handling in distributed environments, but none introduce significantly new architectural principles. For in-house application development, it is therefore good practice to separate application logic completely from the underlying technology, for example, by encapsulating specific technology through an extra software (architecture) layer or by using code generation techniques that generate flexible mapping between application code and the current technology. Thus, architecture can remain stable (evolve through upward compatibly) for some time, while technology that implements the architecture may well change. Typical architectural decisions that enable this flexibility include separation of user interface and application logic, and separation of components via interfaces.
The second category, management of heterogeneity, requires a component-based approach to application architecture with an enterprise-wide standard for integrating application components. Components themselves may then use any basic technology as long as it is encapsulated within the component. Integration of components must be enabled on two levels: on the functional level and on the user interface level. On the functional level, the major integration mechanism is provided by message-oriented systems with added capabilities for message routing and data mapping. XML, the de facto data standard in this area, is being extended with functional capabilities through SOAP (simple object access protocol) and WebServices. It is more important to focus on the general architectural capability of separating application components with well-defined interfaces than to focus on one specific technology. Once such interfaces are conceptually defined, it is mostly simple to map them to different technologies, be it CORBA, EJB, or WebServices. More and more application products expose their functional interfaces to enable their integration on a functional level, despite potentially heterogeneous underlying technology. On the user interface level, (tight) integration is much more difficult, since most off-the-shelf application components do not expose their user interfaces as separate entities. However, this is changing, since with the increasing need for business workflows, application systems will need to be broken down into activities that can be triggered separately, including functionality and user interface. Another promising trend is the move of user interfaces towards pure Web technology and shared portals. This requires more sophisticated Web user interface elements and, more important, the separation of Web page content from sequencing control.
Managing technology heterogeneity for off-the-shelf application products while providing the necessary integration capabilities depends on imposing requirements that products publish their interfaces and provide a component based approach to their overall architecture, from a functional, but also from a user-interface point of view.
We will explore the Collaboration part in the concluding part of this article, Watch this Space
Loving P&C
DC*
No comments:
Post a Comment