AboutLarry Miner Expertise I can answer a wide range of questions on the Project Management of Software Development Projects. The broad subcategories of PM would be;
1. The design, development, delivery and integration of the software development process.
2. The staffing process onshore and offshore.
3. The Software as a Service model
Experience I've been a Project Manager/Application Development Manager for 20 years.
Publications 1. BusinessWeek.com
http://www.businessweek.com/smallbiz/content/feb2004/sb20040218_6502.htm
2. Cleveland Craintech.com
http://neohio.craintech.com/cgi-bin/article.pl?articleId=3876&a=a&bt=Larry Miner
3. Completed book on business and technical aspects of building a software development firm. Made available to all members of the New York City Software Industry Association.
Education/Credentials Degree in Computer Science.
Past/Present Clients My clients have been NASA, GE, E&Y, Limited Brands, Huntington Bank, Microsoft, Diebold, Key Bank, and General Services Administration to name a few.
Expert: Larry Miner Date: 6/27/2008 Subject: Strategy for Managing Development of Independent Interfaced Applications
Question QUESTION: Hi there! I work in an IT organization as a business analyst. We are currently having a development management issue that we are going to be brainstorming solutions for in the next few days. As a means of researching prior to that discussion, I thought I would go online and see if I could find some information about others' strategies for dealing with this, as this is not a new or unique problem.
My particular team is responsible for a specific application, Software A. That application has independent clients, deliverables, and deadlines. Software A interfaces with two other applications, B and C, each of which has its own independent clients, deliverables, and deadlines. We recently received requirements that require a basic architectural change to Software A -- which will require B and C to change how they consume the interface if the want to continue working with us. But of course, B and C have their own deadlines and cannot absorb the extra time it would take to change the interface, so they have asked us to maintain the "old" interface even after we are on the new architecture, to give them more time to adapt.
Thus, the concern is this -- we are never going to all three be on the same timeline (and other apps will be interfacing with us soon, which will just expand the problem). Are there proven strategies out there for how to deal with this type of situation, when applications interface but can't always keep up to date with each other's current versions? We don't want to have to keep multiple versions of code to accommodate the different versions the interfacing apps are using...
If there are any white papers you can point me to, or tips you can provide, it would be greatly appreciated!
Thanks.
ANSWER: Sorry, been out of the country, but back. Do you still need help on this. Sorry it took so long?
---------- FOLLOW-UP ----------
QUESTION: Yes, I still do need your help! We had to postpone the "brainstorming" meeting, so this is still very timely! Thanks.
Answer I would suggest everyone has this issue in one form or another and it's difficult to deal with especially if there is some value to retaining apps B and C.
Would I would suggest, and you have to tell me whether this is even feasible, is to treat each of the interfaces to old or new like a driver, even if in the new architecture you have to write a place for them.
We deal with this all the time and we treat the interfacing with new and old as if they were drivers that can be plugged in or taken out, actually they're always there just not accessed. This way all the customers are happy, you don't lose any revenue from leaving someone behind and it gives your markeintg the ability to say just how many other apps you work with.
