USFA & Organizational Tech Upgrades

[dcmdale]

Originally Posted by Wafath

But this does bring up a good question: To what extent would the USFA be willing to use FT & AF as COTS products?

I'm sure that nobody with any real ties to the USFA would want to answer this in public, so that leaves those of us that don't have any real information...

FT seems like it offers a fairly straight-forward path for a COTS implementation if the USFA wanted to go that way. Dan needs to fix some known stuff, but then it would appear to be mostly a matter of negotiating a price for licenses and support agreement.

AskFred is more problematic. Initially, it looks like an attractive candidate for a managed service. I am going to guess that Peet would have little issue integrating with whatever solution that the USFA decides on for membership OR simply extending his data model to include membership/club/etc. management. His existing system gives me fair confidence that he could absorb that function as well. The challenge (not insurmountable, however) would be in negotiating a contract that allowed the parties to get out at the end of the contract. Peet has significant intellectual property in his datamodel and coding. If there is conflict between the USFA and Peet, one or the other may want to terminate the agreement at some point. Presumably, in that event, the USFA will want its data and Peet will want to ensure that the USFA is not just replicating his data model in a different database. Not impossible to negotiate, but trickier.

[dcmdale]

Originally Posted by ivlobane

I have some familiarity with the pricing an complexity of doing everything in-house compared to using an existing service. The difference is tens of thousands.

I think that choice of approach will make a big difference on the price here. Even assuming that the waterfall model is the correct choice, I cringe at the idea of a committee of stakeholders attempting to write requirements. Not USFA member is a lawyer--we do have access to business analysts too.

Looking over the NC paper, however, this is really a good candidate for more agile methods. Unless I am missing something in the NC proposal, this kind of database programming really isn't rocket science. In CakePHP, I'm thinking tables for members, divisions, sections, schools, clubs, and vendors (i.e., not including event management stuff), plus a few association tables, would take a good Saturday afternoon to get to a fully functional unskinned prototype including a pass at a security model and a SOA interface to allow AskFRED to verify a fencer's rating and eligibility for a particular event. It won't be right, but it will allow people to say where it is wrong.

Now, TBean's fundraising database, that is a lot more complicated. <smile>

[peet]

Originally Posted by dcmdale

His existing system gives me fair confidence that he could absorb that function as well. The challenge (not insurmountable, however) would be in negotiating a contract that allowed the parties to get out at the end of the contract. Peet has significant intellectual property in his datamodel and coding. If there is conflict between the USFA and Peet, one or the other may want to terminate the agreement at some point. Presumably, in that event, the USFA will want its data and Peet will want to ensure that the USFA is not just replicating his data model in a different database. Not impossible to negotiate, but trickier.

This is a good point. An agreement between USFA and me/FRED would probably want to specify that the USFA data content belongs to them, and that upon termination, that data would revert to their possession, in a non-proprietary format.

-p

[dcmdale]

Originally Posted by peet

This is a good point. An agreement between USFA and me/FRED would probably want to specify that the USFA data content belongs to them, and that upon termination, that data would revert to their possession, in a non-proprietary format.

Presumably, the data you send will need to be structured in some way (XML|JSON|similar) to avoid loss of resolution. While clearly you can obscure your physical data model and, to some degree, your logical model, it will be necessary (or at least would be if I were representing the USFA) to show enough of the fields and key structures that the USFA isn't losing anything. That would take a DBA a long way toward how to rebuild it.

Now much of what you've got in AskFRED is fairly straightforward. Now, admittedly I have a knack for some of this stuff, but I could throw together a fairly complete logical ER diagram of a standard fencing tournament in a couple of hours. (I tend to view the world in the third normal form, doesn't everybody?). However, when I look at AskFRED, there are a few areas where I wonder how you approached it: How you modeled the various possible event formats, for instance. I suspect that looking at the structure of the output data would give me a lot of insight.

Things to think about.

[needle]

Originally Posted by dcmdale

I tend to view the world in the third normal form, doesn't everybody?

Sorry, my world is a bunch of star-schemas

System migration is always a fun (not!) issue. Getting the data out is usually a non-issue, unless the lawyers who drew the contract were from Elbonia. The problems start when structural differences between the model-that-was and model-to-be are not resolvable (e.g., conversion is only possible one way, and it's the wrong way). Anyone who ever ran migration from Oracle Financials to SAP, or in the opposite direction, for that matter, will understand what I mean

[dcmdale]

Originally Posted by needle

Sorry, my world is a bunch of star-schemas

Typical liberal... Always OLAP, never OLTP .

Originally Posted by needle

Anyone who ever ran migration from Oracle Financials to SAP, or in the opposite direction, for that matter, will understand what I mean

I'll remember that when I put together chartware for next year's projects. <Insert Evil Laugh here>

More seriously, I am not intending to minimize the technical difficulty of moving out of a system like AskFRED once the USFA was in. From a legal perspective, Peet's intellectual property is an issue for him to think about if this were structure more like a managed service. It isn't necessarily a showstopper. The USFA, on the other hand, probably should be thinking for its part on exactly the issues you are thinking of. "We get the stupid data, but what do we do with it!" They *may* be able to do something reasonable with the membership part, but migrating the event data to something not purpose built doesn't seem likely to me. On the other hand, in that situation, Peet would be left with a perfectly functional system, but without USFA involvement, reduced income.

I guess where I am going with this is that while I think that a USFA/AskFRED relationship would be a good thing, good vibrations at the beginning of the relationship often cause problems for all parties when things fall apart.

[needle]

Originally Posted by dcmdale

Typical liberal... Always OLAP, never OLTP .

Don't go all Inmon on me
Funny enough, I found that most people who come to OLAP, bring good, solid OLTP background with them. So, getting an OLAP guy to design something in 3NF or BCNF is usually not a problem, and you end up with a quality model. Getting pure OLTP guy to design a datamart ... where do I start?

Originally Posted by dcmdale

I'll remember that when I put together chartware for next year's projects. <Insert Evil Laugh here>

Seriously dude. I went through that TWICE!!! And got a few gray hairs and lots of empty bottles to tell the tale. If you really have to do that for any decent size organization (mine was 1100 people, getting on the same platform with 70000 people as result of acquisition), be very worried.

Originally Posted by dcmdale

More seriously, I am not intending to minimize the technical difficulty of moving out of a system like AskFRED once the USFA was in. From a legal perspective, Peet's intellectual property is an issue for him to think about if this were structure more like a managed service. It isn't necessarily a showstopper. The USFA, on the other hand, probably should be thinking for its part on exactly the issues you are thinking of. "We get the stupid data, but what do we do with it!" They *may* be able to do something reasonable with the membership part, but migrating the event data to something not purpose built doesn't seem likely to me. On the other hand, in that situation, Peet would be left with a perfectly functional system, but without USFA involvement, reduced income.

I guess where I am going with this is that while I think that a USFA/AskFRED relationship would be a good thing, good vibrations at the beginning of the relationship often cause problems for all parties when things fall apart.

I completely agree. This is where Peet's and USFA interests are close, but not the same. Putting my vendor hat on, I want the contract to ensure that:
1. Relationship is long-term (at least 3 years)
2. Stream of requests for new features is predictable, allowing me to plan
3. SLA allows me reasonable leeway
4. My IP remains mine - If I want to take my product somewhere else (service Canada, UK, FIE ... who knows), I can.

Putting my IS director hat on, I want the contract to ensure that:
1. Relationship is long-term (at least 5 years)
2. SLA is in place to ensure that my business-critical activities (NACs, SNs, RYC/SYCs, etc.) receive adequate support.
3. System's high availability and disaster recovery are adequate for my needs.
4. 3rd party monitoring for security and service availability is in place and supported by vendor
5. I own the data
6. I have guaranteed development bandwidth from vendor to cover new feature requests. Time and materials basis is ok, I would prefer to have pricing locked.
7. Typical data management activities are either included in maintenance fee, or are fixed price.
8. Vendor has (or commits to a roadmap that has) adapters for data migration to at least one competitor. Availability of such adapter from competitor or 3rd party is ok.
9. I own project oversight, but project management cost is carried by the vendor (directly or through subcontractor).
10. Integration to my other systems is committed to. Time and materials is ok, but the estimate has to be in place already. I prefer fixed price.

This is just off the top of my head, if I actually spend time thinking about it, there'd be a few more

[dcmdale]

Originally Posted by needle

Seriously dude. I went through that TWICE!!! And got a few gray hairs and lots of empty bottles to tell the tale. If you really have to do that for any decent size organization (mine was 1100 people, getting on the same platform with 70000 people as result of acquisition), be very worried.

You will note that I didn't say that I planned on *doing* the project...

We have a new CIO. According to the new CIO, "we shall have but one and only one system upon which the entire enterprise shall be run and its name shall be SAP! I have declared it! So shall it be!" (How do these idiots get to be CIO?)

Of course, for me it is trivial to put together a powerpoint listing the x gazillion apps that we have and saying, "Thus he has said, thus shall it be! This application shall now be now be made SAP! Goest thou and do so!"

While not demeaning the difficulty of many of the migrations that he is planning, there are some projects where failure can be hand-waved away at the executive level. Other failures constitute the shortest path to the next CIO.

Now moving the Oracle Financials into SAP probably is a good idea (if it can be done successfully), I am not looking forward to projects like moving a 1,000 person Technical Docs group which is authoring in DITA in a Documentum environment into SAP DM.

[needle]

Originally Posted by dcmdale

You will note that I didn't say that I planned on *doing* the project...

We have a new CIO. According to the new CIO, "we shall have but one and only one system upon which the entire enterprise shall be run and its name shall be SAP! I have declared it! So shall it be!" (How do these idiots get to be CIO?)

Of course, for me it is trivial to put together a powerpoint listing the x gazillion apps that we have and saying, "Thus he has said, thus shall it be! This application shall now be now be made SAP! Goest thou and do so!"

While not demeaning the difficulty of many of the migrations that he is planning, there are some projects where failure can be hand-waved away at the executive level. Other failures constitute the shortest path to the next CIO.

Now moving the Oracle Financials into SAP probably is a good idea (if it can be done successfully), I am not looking forward to projects like moving a 1,000 person Technical Docs group which is authoring in DITA in a Documentum environment into SAP DM.

Please accept my deepest and sincere condolences. I went through almost the same 5 years ago.

Consolidating financial system really is a good idea. It will be painful, and will make quite a few people unhappy, but your work on integrating the applications landscape will be much easier, and HQ Finance will be much happier.
Moving from Documentum to SAP DM, on the other hand - this one I would fight tooth and nail.
Make sure the business owners for respective systems have full list of their business processes as they are today, and have a chance to take a look at "to be" for same processes in new system. Don't fight it yourself, you will fail; have the business owners fight it - impact on their work will be much greater than impact on yours, they should be the ones dictating what makes business sense to change.