Migration Challenges in BizTalk Migration

Integration migration projects are humbling in their complexity and over-whelmingly communication-intensive. You are more likely to run into communication, management and operational challenges which can conspire to defeat your march than any serious technical challenges. An adaptive, agile approach where assumptions are questioned daily and where close anticipation and planning discipline is instilled has a greater chance of success.

Here are pointers and advice about the challenges of an EAI migration project – right from the trenches.

Project Management lessons

1. First, if the “Replicating Behavior” migration approach is chosen, a pilot implementation of an interface would be beneficial. This allows learning a lot about the application scope, get the “big picture”, peek into many technical details and eccentricities early, and foresee upcoming challenges – not to mention planning ahead for infrastructure and performance. This Proof Of Concept is not required to be fully functional and can contain only limited amount of artifacts but should a variety of processes, workflows, operations, adapters etc. allowing to sound out different eccentricities.

2. In all large scale migration projects, it is very important to recreate the environment early. Solution partitioning, project structure, build, server topology, packaging and deployment guidelines should not be left for the last – we cannot overemphasize this. A controlled environment where SeeBeyond and BizTalk application can be run in isolation on the control data set. This is critical as there’s no other means to validate migration quality in this approach except to compare output for the known input. It takes considerable amount of discipline to stick to this plan as features get discovered, complexity grows and the team is crushed under this load – but it is important that this stays in focus as an early deliverable, not late one.

3. Early and continuous integration of the processes along with testing mentioned in 3) above helps to discover problems early and take mitigation actions. This is a key assumption that bedevils many teams who assume so-called isolated systems will not impact each other when run together on the same application server. Make sure to get the latest version of the shared code to avoid unpleasant surprises.

4. Some BizTalk features must be evaluated carefully before applying in implementation. There might be critical limitations that would slow down or even halt migration. For example, the Oracle DB adapter for BizTalk cannot return results of the joins from multiple tables. So, if you require this kind of result set then it’s time to turn back to the more flexible ADO.NET and bid goodbye to a code-free approach. Native SQL schema can be used instead of adapter generated schemas to generalize data access out of orchestrations and make them cleaner and easier to understand and maintain. When creating data access intensive orchestrations it often makes sense to consider delegating Oracle adapter task to a .Net component to get rid of large amount of transient messages and reduce performance overhead.

5. Do a careful analysis of the current code base before committing any timelines or budget. Do not assume the solution you are inheriting is either perfect or well-architected. We have found messy implementations where the management is delegated to UNIX/WMI scripts instead of being controlled from the GUI/e-Ways/Collaboration rules, resulting in business logic being distributed over areas not conducive to maintenance or good practice. When these problems are compounded by lack of documentation, then you need to increase project times by a significant amount to accommodate the pain and increased efforts of first collating logic in the code base into a sensible picture before the analysis and design can even begin.

Executive Summary of Database Management

Challenge
In the world of databases, “getting it right” is a phrase filled with ambiguity, for who can say what “right” truly is? Frankly, it’s a lot easier to spot “bad” or “not right” database schemas than it is to confirm that a database schema is “right”. While schema design is the foundation of a well-performing database, you are missing opportunities if schema
design doesn’t also take database performance, administration and backup/recovery into consideration.

Opportunity
If you haven’t done your homework or researched the corporate mission and business requirements — if you don’t understand the real-world database management processes that tie database design to performance tuning, administration and backup/recovery, then your database project is headed down the path to failure. Integrating the best schema design that you know how to do, along with best practices in, for example, performance management and properly tuned and deployed SQL code will go a very long way toward ensuring your database environment is functioning at optimal levels. It also ensures that your data architects, DBAs, database performance team and data center managers and even business intelligence and applications teams are aligned and working
together efficiently.

Benefits
Database modeling and design is at the core of a healthy database management and performance foundation. Getting it right the first time will enhance the bottom line in a variety of ways. It will:
• Eliminate haphazard approaches to maintaining data.
• Minimize maintenance and upkeep of the database schema.
• Optimize data retrieval for graphs and reports.
• Ensure data accuracy and reliability.
• Support corporate goals and evolving business initiatives, allowing the company to respond more quickly and precisely to new business opportunities and competitive threats.