Making the Case for Enterprise Integration: Some Guiding Principles for Steering Your IT Transformation

Enterprise architecture (EA) can mean different things to different people, depending upon the role and responsibility of the individual within the organization and depending upon the context of the organization (either being a consultancy or an end user). To many it is a framework, while others view it as a collection of rules, or a methodology for defining and designing infrastructure services. However, the common aims are to improve alignment of the IT infrastructure with business goals and to attempt to bring stability to an ever-changing, chaotic, and complex situation.

EA provides the essential backbone or blueprint for the communication, interpretation, and implementation of corporate objectives throughout the organization and enables the evolution of a strongly aligned IT environment. A plausible way of achieving this would be through creation of a number of interconnected architecture views. The various available frameworks (commercial and/or noncommercial) break the definition of enterprise architecture into a different number of models and artifacts. EA at the most consists of three main elements: business, information, and operations.

An effective and pragmatic EA relies on having a common platform and systems infrastructure on which to base the organization’s products and services. What we see is, an increasing need for convergence of multiple technologies into a platform providing components for building, managing, and deploying services. The convergence platform should be centered on loosely coupled integration at all levels—system, applications, information, processes, and people—and the ability to quickly reconfigure these elements to react to threats and opportunities in an organization’s environment.

A service’s model utilizes the logical-level deliverables provided by the other architectures (business and information), expanding a platform-independent view of the business processes with associated data and presentation requirements, and using this to develop a platform and technology-dependent model, taking “cognizance” of technologies and utilizing a services platform with common components and services. Approaches gaining significant traction in this area of SOA are enterprise class communications backbone like ESB, Model Driven Architecture, and adoption of frameworks like TOGAF.

Guiding principles for IT Transformation

Many organizations look to guiding principles to establish consistency across their IT transformation initiatives. The most important are:

Security: There is a delicate balance between acceptable risk and usability. It is vital that an enterprise’s information is adequately protected. Security will become a precondition of doing business in the future, especially with the inextricable move toward e-business and e-government.

Adaptability: In ever-altering internal and external environments, solutions have to be flexible, catering to changes in requirements, procedures, processes, and organization. An important facet of architecture must be the use of modularity to enable continual adaptation, meet changing business needs, and allow reuse of software.

Standards: Open interfaces and data models delivered through an enterprise-wide governance framework are crucial if an EA approach is to succeed. The use of standards extends further than just being used for interoperability. Openness shields against supplier dependency and is important for protecting IT investments. The move to more componentization relies on standardization.

Performance: As with security, it is costly to add scalability as an afterthought. Systems need to maintain efficiency and service levels regardless of demand. The whole operation relies on the performance of the weakest link! The architecture must support the increase in users, transaction volumes, and data capacity and prevent bottlenecks.

Management: Management of the complete architecture process is another important factor. The need for features such as version control, end-to-end visibility, and monitoring become even more critical.

Observations on EA and Enterprise Integration

When implementing EA and enterprise integration approaches in support of IT transformation, it is important to understand, position, and execute these disciplines consistent with industry best practices. These key observations have helped many EA and integration teams achieve results quickly while avoiding costly mistakes.

Enterprise Architecture

A number of organizations have implemented an EA. Approaches vary from top down or bottom up.

An EA model can have four levels: business architecture, information architecture, applications and systems architecture, and technical architecture.

It is important to have a common vision of where the business is going. This greatly influences application and hardware strategy.

Key: Model the business based on its services through templates; processes can then be modeled.

Aim for reusability. Identify interdependencies.

EA is the technique for communicating with the business. Methodologies and tools help this.

Tools can be used to document applications and business processes (not necessarily in one tool).

Important: Consider how the information from the tool will be used to ensure it is fit for its purposes and aids communication.

Plans: Make sure the business strategy translates into the IT strategy.

• Have a planning period covering three years.
• Review and update the plan regularly.
• Have a decommissioning plan.
• Expose projects at an early stage.

Build governance from the board down. A strong CIO is needed to get support from the business.

Identify the IT elements of business budgets and aggregate them. This shows a total cost of IT.

Have some form of EA policing/auditing/review. Always review pilots.

Achieving control: Make the adoption of governance part of personal appraisal objectives.

Enterprise Integration

Increase the access to and ability to change the application services (based upon business need):

• Open published interface standards including XML data formats, Web Services, JMS, FTP, and HTTP; WSDL and W3C Schemas as service definition language; and SOAP as the “messaging protocol language.”
• The capability to selectively store message data in an external data store as it traverses the middleware.
• Reduced impact of changes to IT business services to the business.

Improve the availability and reliability of the application services:

• Access to additional (existing) services.
• Generic high availability interconnects facility between all supported system components.
• Reduced technical risk of supporting IT business services.

What To Consider When Focusing On Enterprise Integration

Requirements

Description

Message Transformation/Message Translation
Transform from one message format to another, for example between different XML schemas using eXtensible Stylesheet Language Transformation (XSLT). Transform an XML message to any of the supported industry formats, and vice versa. Also the ability to act as an intermediary between source and destination systems when message interactions happen to enable translation of formally defined messages. This is to ensure that messages are enriched and distributed in real time/batch to and from disparate sources.

Support Industry Protocols and Formats
The ability to support specific industry message formats such as FIX, SwiftNet and SWIFT(ISO 15022 and 20022), PDF, CSV, MS-Excel. Further it is also assumed that there will be a point in time in the future where the messaging solution will need to support proprietary formats for asset management services.

Message Transactionality
The ability to ensure that message interactions are persistent and transactionality (XA transactions)/state are maintained through point to point and publish/subscribe.

Routing
The ability to intelligently route messages based on their subject and/or contents and allowing set up of complex dynamic message paths that will help services to interact with source and destination systems. For e.g., route on SWIFT message.

Guaranteed Message Delivery
The ability of the solution to ensure that message persistency is maintained throughout the interaction life cycle and that messages are delivered to the destination system even when there are network failures or the destination system is down.

Batch Processing
The abilities to extract, transform, and transfer files from one system to another and to process a series of batch requests through files with sync points maintained between different communication patterns (file to file, file to DB, file to messaging).

Centralized Command and Control
Centralized monitoring, configuration management, service life cycle, and deployment management.

Governance Framework
Linking the adoption of SOA closely to business as usual in the areas of operations, processes, services, data, and infrastructure.

Orchestration
The ability to “technically” orchestrate between business services based upon events raised in business processes (either system based or through human workflow). The solution should provide for technical orchestration of business services out of the box, most preferably through a BPEL workflow and engine.

Metadata Management
The solution should support strategies, principles, and standards that will be established for efficient handling of metadata to enable for the creation of operational data stores used in business dashboarding and efficient decision making.

BAM
The solution should support the ability to technically track and monitor business events/processes in real time to enable auto-error handling and publishing of this information for resolution by the BAU teams. This information is used by technical and business operations to provide visibility, measurement, and assurance of key business activities, and to support root cause analysis and alerts that warn of impending problems.

Service Assembly
The solution should provide the abilities to build services at various levels. For example, “Create and Manage Order” could be a composite service containing many underlying services such as “Order Creation,” “Order Fulfilment,” etc.

 Epilogue

This article deals with some of the basics around why organizations are giving a serious thought to enterprise architecture and how these considerations play a major role in linking to initiatives like enterprise integration.

While it is important to focus on immediate programs at hand—it is becoming increasingly imperative to also take a step back and view the enterprise from an “aircraft pilot’s viewpoint” to enable stronger linkage of IT initiatives to business goals, strategies, and measures.

Enterprise integration through traditional EAI methods need to focus on distributed/federated architectures that span multiple geographies and disparate business processes. A clear view on the definitions, policies, and standards for EA and requirements for EI will help the architect on the ground to safely steer this ship to the target destination.

by Bhavish Kumar, principal architect and deputy practice leader with Cognizant Technology Solutions. He is a certified TOGAF practitioner and has close to 20 years of experience, successfully delivering complex high-value projects within international blue chip and FTSE companies both as a customer and a consultant. He can be reached at bhavish.kumar@cognizant.com.