Applications Integration 1

[Ahssan]

Hi All,

Merry christmas to every one .

Well i have been given a task to integrate the currently running applications in our corporte with surely doing ammendments in all of the applications. We have 4 different applications running independently which do not communicate with each other at all. all of the applications have back end database 3 of them MS sql server 2000 and one has oracle 8i. Now i need to know what approach and methods should i use to make all these applications running independently but communicating with each other and sharing info with each other which is necessary to have from each system. I have been reading some articles about ERP related methods but still a professional advise from professionals is always appreciated. I would love to have comments from who ever is interested in this subject.

Thankyou and happy new year to u all

 

[BNPMike]

Asshan

As a project manager you should always avoid thinking in terms of connecting back end servers, or whatever. This is this biggest single mistake that project managers make.

What you are actually doing is eg 'allow orders taken in Helsinki to be fulfilled in Brussels or St Johns Newfoundland depending on certain criteria about size and availability' ie a purely business objective. Only start talking about technical options when you have to. And then as little as possible.

In your case there is (we assume) some business driver that needs some connection between the processes served by your systems. You need to be very explicit about all the criteria before you move even an inch forward.

The answer to your question might be anything from send a few FTPs on a daily basis, to install SAP.

 

[Ahssan]

Thanks BNPMike for your swift reply.

Well the situation in my case is just not so simple. If i will explain little bit more u might get the whole idea. I will put each system and brief it to you and then you might give me your professional advise.

1 Service provisioning (In house developed)
This system was developed totally in asp with back end as sql server. all it does is covers the whole workflow of service provisioning covering all departments. Main info in this system goes is as:

customer profile, service info and other departments tasks.

2 Great Plains (Microsoft Product)
This system is used in Finance department for accounting purpose. Modules in it are out of the box solutions. back end is sql server which is different from the service provisioing.

3 Remedy AR System (Remedy product)
This system is used by HelpDesk Department for trouble tickets for our customers, back end is Oracle 8i.

4 CRM (Bought package Web Interface)
This system as from the name is CRM used by sales only and back end is Sql server again which is again on different system independently.


so the equation is

sqlserver + sqlserver + sqlserver + Oracle8i

In such different environment of applications and different back end databases how is it possible to make one common interface which is surely not a right answer isnt it ? my idea was that if we can make some common info available from each databases to each applications mainly customer info, services , invoices info, installations. We are and ISP company by the way (Duh totally forgot). anyways this is what im facing to integrate. And if try to make databases talk with each other what problem can it cause anyways ?

Big story aint it but would appreciate alot ur comments.

Thanks

 

[edelwater]

First of all : this is not a project management question this more an EAI question...

Second: you might think first in sketching a few scenario's for solving your problem.

- do you want each of the interfaces to be real-time or e.g. nightly/weekly batches ?
- see what native interface support the CRM system, the helpdesk system, etc.. has, try to work from there using the build in Application Integration support, will save you some stressfull moments.
- treat each interface as a seperate project with its own milestones
- think about fail-safe systems and how to recover from errors
- get an expert from each system and let them sit together, they should be guys who can dream the data model
- forget all existing methods just use the ones you are aquainted with
- let a microsoft expert review the plan for the great plains interface and for each interface get an expert/consultant
- get a good project manager









Edward@de-leau.com

http://www.de-leau.com

 

[cjowsey]

Asshan,

BNPMike has asked exactly the right question which I don't think you have really addressed. The fact that you have separate systems with different or the same technology and presumably on different servers is neither a good nor a bad thing. It is just the way your company has implemented its technical solutions to a set of business problems.

Before you talk about integrating databases (which may as edelwater suggests make it an EAI project) you need to define (or better have the business users with the cheque books define) a strong business reason for doing this.
[ul][li]Is there information in one or more database that you need to share with other databases?[/li]
[li]Do people in different departments need access to a database they don't normally use?[/li]
[li]Is there duplication of data between databases that is costing the business time and money to verify and control?[/li]
[li]Are the separate databases costing the business money or damining its reputation through operational errors?[/li]
[li]Is there an operational cost in having separate databases that you could recover by combining servers or databases?[/li]
[li]Do the separate databases create a disaster recovery and business continuity risk by not having a common checkpoint to roll back to and restore from if you have problems in your primary data centre?[/li][/ul]

I obviously don't know your business, but those are a few questions which might be sufficient to identify the business reason for making the systems talk to each other.

To treat this as a project management exercise you need to go through the following steps.
[ul][li]Identify the business drivers for the project.[/li]
[li]Identify and approximately cost possible solutions.[/li]
[li]Calculate if the benefits outweigh the costs and how long before the benefits can be realised.[/li]
[li]If there is a mandatory business driver (eg legislation changes) or important strategic driver the project will probably go ahead even if it doesn't make money. Otherwise it is a business decision as to the best use of the company's money.[/li][/ul]

If you get through the steps above, you have a project and you can start talking about how you integrate data and databases and defining what data needs to be shared with which application.

Hope this helps,
Clive

 

[BernardErtl]

I suggest you look at Pectra Technology's business process management (BPM) solution. It encompasses both business process integration (BPI) & enterprise application integration (EAI). Marcelo in the Houston office is very helpful:

Marcelo Kreindel
VP of US Operations
Pectra Technology, Inc.
Phone: (713) 335-5562
Fax: (713) 297-8864

http://www.pectra.com/

Bernard Ertl
www.interplansystems.com - eTaskMaker project planning tool

 

[BNPMike]

It certainly looks like you would get benefit from being able to connect some of the data. I must admit I thought CRM was supposed to do this. I think CRM is used nowadays to mean any old thing that lists customer contacts. So Option 1 is buy Siebel (a snip at 50 million).

The other approach I would look at is using a product that can take views across different databases. Given that all your databases are SQL I would think you could choose from loads of products. I might look first at Business Objects (I only assume it can run across databases/machines).

Actually merging the databases would not give you what you want which is some application than presents and manipulates the combined data. I suspect you will find that almost as easy to do with the separate databases as with one merged one.

 

[Ahssan]

Hi Mike,

Well what you are saying is also right and its not the only right solution to merge the databases together. Well the thread of my problem has grown day by day i can see which gave me quite good ideas in how to deal with the problem. just recently i came to know that Great plains which is a microsoft product has its own way of handling tables in sql server or any database when i checked the great plains database i couldnt find a single meaningful table name so i got lost this is same as in Remedy helpdesk system where there is a schema inside a schema hard to deal with. now merging the database will not give me anyway to deal with this problem then either i have to asynchronously update the database at time intervals of find and EAI product which would come over all these applications and give a common layout and that also i dont know how it will be done and how much time it will take. Have any of you ppl used any EAI product before? if so then is it feasible to have it and surely enough are trainings needed to develop user requirements with these products.

 

[BNPMike]

Ahssan
I sympathise with you. Your problem looks like incompatibility of data models rather than platforms. Why do vendors design horrible databases? But they generally seem to do so.

I may be cynical but I suspect EAI is just CRM on steroids ie instead of spending millions with some vendor, they'll rip you off for hundreds of millions. For there is no shortcut to merging disparate data sources.

My advice is go right back to the start of this thread. Project Management is about achieving specific business goals so forget strategies and just write a list of the specific things you know someone wants, and how much they want them. Then just address each of those individually. Ignore anyone who says you can save money by moving over to their new world. Unless of course they agree to not charge you a cent until it's up and running...

 

[Ahssan]

Thanks Mike,

Well im not planning any project too man the condition is more pity ful as the guy behind the development and integration and knowing technical stuff about databases and applications is me and only me my IS manager (he thinks he is) knows none and what ever i say he says ofcourse yes i told u , i agree with u and bla bla bla. So its me only who has to come up with some solutions or solution. But sure i agree with u products coming now a days are like in compatible with others , such as great plains as it is on sqlserver and i thought it will be easy to atleast sycnronising the database with others but the damn database structure is not understandable in anyways i cant even find one table which is linked with other table seems every relation stuff happens with in the application damn these microsoft products. anyways man thanks again for ur comment hope i will end up some where or i will just end up .

 

[BernardErtl]

Have any of you ppl used any EAI product before? if so then is it feasible to have it and surely enough are trainings needed to develop user requirements with these products.

Yes, it is feasible. Despite BNPMike's cynicism, there are solutions that work out there. I already mentioned one possibility above. Good luck.

Bernard Ertl
www.interplansystems.com - eTaskMaker project planning tool

 

[cjowsey]

Berbard Ertl is right. There are a number of products and organisations that are good at bringing data together from disparate sources (Enterprise Application Integration). This normally involves an architectural layer of file based transfer or messaging between applications and databases. If you don't need close to real time interaction, you can build it for almost no external software expenditure using products like Perl or SQL Server's replication tools.

In my limited experience the process is never cheap as the analysis and design process is always very complex and you need to get the architectural design absolutely right. If you are getting external integration experts in to help you, they need to be given the business requirements and be taught how the systems all work and how you use them before they can make any significant progress. Remember that you will be hiring them for their technical skills not for their knowledge of your business.

Although many software vendors use relational databases, they do not often do it to make the data more open to the customer. They do it for performance, scalability, portability and ease of upgrades. There is a reason they deliberately obscure their database schemas. It is to stop people looking inside the database and making changes without using the front end application. Many (probably most) application licenses are invalidated if you try to reverse engineer or change the database without approval from the software vendor.

Having said that, many application vendors provide export and import utilities to transfer data in a safe way between their system and external systems. Many vendors will also give or sell you a fully documented database schema if you speak to them and tell them why you want it. They are keen to both protect the integrity of their product and keep the customer happy and they can do that best by working with you.

Note that if you are taking data from several databases, you will almost certainly need to store it somewhere to allow it to be merged together. I strongly doubt if any of the application vendors would allow you to change their databases. This means that you will need to design a new database or make changes to your in-house service provisioning system to hold the merging process.

After all that, I go back to the point I made a few days ago and which I don't think you have addressed. You need a very clear business requirement before you go much further in this process. This integration will cost money which should be spent in obtaining a business benefit o improvement of some kind. For example, one very simple question that needs to be resolved is how frequently the data is to be extracted from each database. A clear answer to that will resolve a number of basic architectural issues. Another question is whether you will rebuild your merged database every time or apply all the changes (inserts, updates and deletions) to it. The first option is simpler but more data intensive, the second option is more complex to design, build and test.

My suggestion is that unless you have a very strong set of business requirements, don't worry about integrating systems at the moment. The fact that you have a number of different systems with similar architectures is not a reason to merge them. In my house we have two cars and four bicycles. I would gain no benefit and enormous disadvantage from joining them all together. You may get the same effect from trying to join your systems together.

Hope this helps,
Clive