Integration projects are inherently risky. You don’t have to look far to find some real catastrophes across a variety of industries. For every high profile failure, there are dozens of close calls where just a few million dollars were wasted or the business had to wait longer than expected for delivery of the solutions. It is generally accepted that all large-scale integration projects will encounter significant and often costly problems before they have been completed.
Why don’t Integration projects run smoothly and without incident?
There are many reasons for these difficulties, ranging from insufficient planning and inadequate project management, to resource issues and technical problems. However the common denominator with most failures is poor communication between business and IT departments.
Business people and IT people perceive the world differently – they process information differently, they have different preferred communication methods, different priorities, different business needs, and different visual/audio styles. They even perceive risk differently. It’s no wonder that most companies experience ineffective communications between groups.
What is the solution?
Businesses and IT can communicate better through the adoption of best practices such as ITIL (Information Technology Infrastructure Library) and the application of IT Governance techniques such as Integration Blueprinting. Integration Blueprinting is fast becoming the standard for re-igniting Business and IT relationships for all IT projects.
Most of the problems encountered in integration have little to do with technology. There usually isn’t a need to replace the products and people that are being used to provide a company’s integration solutions. Rather, there is a need to identify and address the risks associated with these projects in a way that all parties understand.
Anatomy of an Integration Blueprint
Integration Blueprinting achieves these goals, and does so within the context of the methodology that is already being used for integration. The methodology may include existing corporate computer architecture, specialized integration technologies, or preferred consultants and services. Integration Blueprinting overlaps all of these, eliminates the risks, and provides the organization with an integration safety net.
The four fundamental components of an Integration Blueprint are:
1. Integration-Specific Business Requirements
2. Integration Architecture
3. A Customized Methodology
4. Implementation Tasks and Analytic
An organization's integration business requirements are broken down into the following categories:
1. Systems Rationalization
2. Data Integration
3. Process Automation
4. Composite Application
5. Business Activity Monitoring
These are assembled in consultation with the business both at departmental and cross-departmental levels. In doing this, a significant effort should be put into identifying the “culture” of the business. This will ensure that the requirements that are specified are not only technically achievable but are also targeted at the business’s motivations and abilities.
It is at this stage that the initial “buy-in” of the business is achieved. The integration is being driven by the business, for the business.
The Integration Architecture consists of both business and technical facets, providing a graphical display of the business and its architectural makeup. It should span the organization and drop to levels of detail that are relevant to the levels of integration involved. Generally, not more that 3 or 4 tiers of detail are advised to ensure that the material remains “digestible” and of benefit to the reader.
Graphics should be provided in both business and technical modes and be supported by commentaries to facilitate deeper understanding and closer cooperation between business users and IT staff.
Choices, both structural and technical, can also be included to help achieve a best possible fit with the company’s business needs and budgetary constraints.
The methodology is the “How To” side of the blueprint. It should be customized to suit your company's integration situation and will form part of your business’ IT Governance collateral.
The methodology contains a detailed description of the implementation techniques best suited to satisfying your business requirements, with particular attention paid to those integration requirements that are inherently more complex and difficult to implement.
The methodology should also contain sections on the resources and training needed to perform the implementation.
The methodology is used by your solution provider when performing the implementation: Any divergence from the methodology on the part of the solution provider should be approved, in advance, by the business.
Adherence to the methodology will allow you and your business (rather than your provider) to remain in control of your integration program.
Costs, benefits, and risks are identified and quantified.
Analytics allow the business to investigate the merits of multiple potential integration solutions, both costs and potential returns, in comparison to a “Day 1” scenario.
The final blueprint should include an implementation map detailing the order, priorities, and timing of implementation, along with costing and ROI estimates. These can then be used as input to the Project Management process.
A risk management plan should also be included to highlight and mitigate against all potential risks.
- Systems Integration Made Friendly
For IT Managers and Developers who would like an overview of Systems Integration but don't need (or want) to get into specifics. Covers: Web Services, Enterprise Service Bus (ESB), Enterprise Portal, SOA, B2B, ERP & Integration Blueprinting.
Specialist provider of Integration Blueprinting services.
More by this Author
It’s important to understand the relationship between returns and chargebacks. Both are ways for customers to get their money back, but the processes involved are very different. What Exactly are Returns and...
No comments yet.