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 ...
Software/Hardware used:
ASKED:
October 25, 2004 7:48 AM
UPDATED:
October 29, 2004 2:46 PM
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.
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.
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.