Managing Third Party Interfaces of Large System Conversion

Business/IT alignment
Lifecycle development
Microsoft Exchange
Online transaction processing
Third-party services
Good morn, This is more of a PM question, but I'll throw it out there ... any feedback would be greatly appreciated? What is the best method for managing 3rd Party Interfaces of a large system conversion? The company is converting its core mission critical system which has an immediate impact on all related interfaces. Several teams have been formed to manage the various different modules of the system -- including an Interface team. What would be the best collaboration between teams, including managing the scope of their project to include interfaces in their discovery and data gathering phases, as well as acquiring their respective resource managers and subject matter experts? Additionally, we would like to add a line item within their scope documentation referencing said interfaces, but would like a rather generic statement. Any help in this area would prove helpful as well. Thanks in advance ...

Answer Wiki

Thanks. We'll let you know when a new response is added.

Have your Interface Team TRY to figure out a Least Common Denominator (remember fractions?) approach. Almost all interfaces will convert to something else with relative ease. Put as many of your ‘various types’ on to whichever conversion platform would be possible. This will reduce the bulk of the headache.

In the future, only accept bids from vendors that will accomodate what you already have in place. Makes life much easier.

Discuss This Question: 3  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • CityArchitect
    If I get your question right, I think that what you need is Configuration Management; a tool that you can use to capture your Applications, Interfaces, Servers, People, Projects and Documents all in context and all collected and maintained in a collaborative environment. I don't think a comprehensive solution exists (and I've seen a few from the major vendors), so I have designed and prototyped my own. If you want details, send me a private message.
    0 pointsBadges:
  • Solutions1
    In 2004, this is an important question, while by 2007 or it will be a crucial question, because service oriented architecture and xApps to SAP-speak is all about interfaces. Ideally, in managing this conversion, you not only will succeed, but better position yourself for the next one. Two immediate points. Careful data change management is critical (and typically not "in scope" for interface teams). Of particular concern are changes in data "granularity" - e.g., one item code in the old system perhaps becomes two or more in the new one or one data field (pen, red) becomes two "pen" in one field and the attribute color in another. The other is to try to avoid radical surgery on both ends simultaneously. If your old interface was based on, say ANSI EDI or some spreadsheet format, but your new system implements some XML alternative, you probably want to at least temporaily use a translator product or service in the middle so that on day 1 the trading partner is still sending ANSI or whatever. If you tightly couple both sides to a simultaneous cutover to something new on both sides, debugging gets difficult, risk increases and you have to expose your own project fits and starts to external parties.
    0 pointsBadges:
  • Speekna
    You need to understand the data in the interfaces. Do a data model that represents all the data in all interfaces - so you have a common definition & understanding of the data across those interfaces. Most data modeling tools allow you to view a portion of a large model in a subject area - create subject areas for each interface. What you now have is an environment that allows you to define the same data the same way no matter what interface it's in - and to understand what data is shipped where across the different systems. In this environment, if a data item structure or definition is changed, the change is apparent in all subject areas where it is used. This model is the tool by which a common understanding is achieved across teams, while allowing each to work independently, and to investigate the impact of changes on the other teams.
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: