IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Web Services Certainly NOT! Cheaper Labor And Attitudes!
Most of the industries I'm tracking (banking, healthcare, travel) are either not using XML (without considering WDDI/SOAP/etc.) or are only using it for "tactical" and "closed" implementations.

Especially since 9/11, most companies are very rapidly becoming very closed about their transactions, what's in them, and what they do. Open Standards are quickly going out of vogue because companies don't want other companies deciphering their messages (or counting the frequency of how many they get per hour, or figuring out which messages are being sent to what vendors, etc.)

Banks/finance are the most progressive of the IT lot, and they are probably the furthest along in implementing XML. However, with 9/11, RAS (recoverability, availability, security) have become their mantra, so many "new" XML projects are on hold.

In my industry (pharmacy claims), we're about to implement another proprietary protocol, completely ignoring XML. Medicare/Medicaid are about to standardize on some ANSI protocols for HIPAA that have nothing to do with XML. Once these products are built late this year and early 2003, then there will be 10 years of ROI that must be produced by all these pharmacy/health companies before they will change again. (Will XML be around in 10 years for the next round?)

Hospitals are using government ANSI protocols, as well as the airline industry with UN/EDIFACT.

So, I think the answer is that with the government's large and growing influence in our lives, web services aren't a threat at all. Web Services will only be implemented where the government will decide to standardize on them or some commercial implementation with no government involvement will allow progressive programmers to use them. Since most big software companies aren't very progressive, that leaves, dot.coms and startups, and we all know how well these have fared recently. The InfoWorld's of the world can rave on for years about how great XML, SOAP, and WDDI are, but until these protocols become part of government standards, and established industry standards, many companies are just going to ignore them because they aren't "strategic".

Cheap software/IT/programming labor, however, IS the mantra of companies today. The goal is to get software developers and IT laborers out of the white collar (ie. "professional") labor pool and turn them into modern day low level salaried slaves with wages just slightly better than someone answering phones at a call center. (Probably worse if you account for unpaid overtime.) Many folks I know of (through church and companies I used to work for) making what I consider to be reasonable wages are currently under fire, either with promises that when their project ends that will NOT get a chance to be redeployed in new roles, or with outright layoffs. Many of these companies want to move the jobs to India, or at least get enough software skills out of work to bring the wage structures down to where software professionals make $40-50K a year.

<rant on>
Funny, we ( a small pharmacy benefits claim processing company ) have put together a really nice Java/Unix/DB2 Medicare claims processing system for a multi-billion dollar pharmacy insurance company, and the multi-billion dollar pharmacy company can't even send us Medicare claims on a regular basis to process. This is occurring because the multi-billion dollar company has few employees left who understand Medicare, who understand pharmacy benefits, and who are paid well enough to care. We spend lots of time training their employees, and begging for these claims, explaining the Medicare process, and showing them cost justification after cost justification for why we process these more efficiently than they do. They don't get it. Many of these multi-billion dollar companies want to pay slave wages and treat people badly, then expect them to care about their business.
<rant off>

The old adage is still true, "You Get What You Pay For", but I would amend "If You Know What To Ask For."

<rant on>
I'm astounded by the small number of people who understand or want to learn (you have to learn them to improve them) the business processes that companies use to get their products and services to market. I'm still very afraid that in 50 years we'll end up with the Soviet or Italian economy, where noone knows how to do anything, where everyone has a political agenda, and where 2-3 giant companies pay dreadful wages to demoralized employees who don't really care.
<rant off>

Glen Austin
New I think there are two problems here
First is that companies don't have their processes straightened out. In every reasonably large project I've worked on, the greatest bottleneck has been trying to write the business rules. For instance: The company directory that couldn't go online because the phone numbers, department assignments, secretarial assignments, office locations, etc. etc. etc. were all maintained by different people, in different formats ranging from databases to spreadsheets to WordPerfect files. No one would give up their little piece of control (power) over "their" information.

Computer systems rely on concise, or at least unambiguous, rules. When the existing business practice doesn't fit these criteria, it's not ready for automation.

The second problem, which depends on the first, is that software vendors tell companies that they can replace expensive, experienced personnel with some new product. The reason this works is that no business wants to believe they are guilty of the first problem I mentioned. "Since our processes are well thought out, they can be automated."

Your multi-billion dollar pharmacy company has gone to step three -- replace the experienced people with shaven monkees -- without going through steps one and two -- standardize the process and automate it.
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
New Perhaps I should have qualified....
"Where companies have their business processes worked out (a small minority)."

The rest of the companies just run what I call chaos centers. A Director or VP who realizes that they need to get enough organization together to survive long enough to get their extended severance package (golden parachute), applies band aid after band aid and hack after hack to existing systems and business processes to survive until another company hires him/her away or he gets laid off with a 2 year severance. No system, just chaos, and maybe you get lucky once in a while, and the rest of the time you play the "blame game".

The turf battles are the worst, and I left a great technology beta in 1997 at SABRE, knowing that the turf battles would rage on for years. Three YEARS after I left the company, the company finally accepted my technology as the standard for the entire company. The technology took about a year to create, and three years to adopt. Funny, I wonder if they even still have a programmer left who knows how it works.

I think the second problem you see is the reality at most companies now. The new MBA/VP who arrives is told to reduce costs and just goes after the heads with the largest salaries and bonus (who don't have some kind of "insider knowledge" on one of the owners of the company ). In other words, if you're a good worker, and you're not hoarding technology or keeping the secret of who the boss's "extra" children are, then you're sacrificed.

So, the new MBA/VP cuts the people familiar with the business processes who don't have an "insider card", and leaves the rest and the low salary new hires, and the Indian outsourcing company with the remaining mess. When it all falls apart after 2 years, he blames his peer departments and business partners who could not provide him with "good service" and walks away with a 2 year severance, only to play golf and scan out his next victim.

Sorry, I'm a little bitter about this now. Instead of a 2 year severance, I think they should get two years in Huntsville or San Quentin (prison).

Glen Austin

New Health care
Especially since 9/11, most companies are very rapidly becoming very closed about their transactions, what's in them, and what they do.
Though 9/11 has had an effect, the main impetus for companies guarding their data and processes more closely is just simply due to the business cycle. When times are lean, companies tend to become much more defensive, trying to hold onto whatever advantage they can - real or perceived.

In my industry (pharmacy claims), we're about to implement another proprietary protocol, completely ignoring XML. Medicare/Medicaid are about to standardize on some ANSI protocols for HIPAA that have nothing to do with XML.
I work on the front and back end sides of medical benefits (setting up eligibility and doing the expensing on our self-insured plans), and I just don't see that XML and web services is going to revolutionize the field. For our medicare people, most of the providers require paper for each and every little thing - having a disdain for anything electronic when it comes to dealing with government agencies. They want that signed piece of paper in their files for their own protection.

The HIPAA requirements aren't so much a standard on how to share information, as they are policies for protecting data from prying eyes - privacy . As such, HIPAA regulations are not intended to improve efficiency of information exchange so much as they are to provide a means where the necessary stuff can be exchanged without divulging too much. That's not to say that it isn't a positive move. In the past, many of our vendors received their data via email or http uploads in raw text files. Nowadays, more and more of them are setting up secure ftp and requiring pgp encryption - a good thing.

As for the file formats themselves, there is currently a certain amount of inefficiency due to each vendor having a different file layout. But even with XML, you have to cater the data to each vendor because their plans are structured quite differently. You also get into the trap of universality with the XML formats. For example, BCBS used their own proprietary format until very recently which was described in a 50 page document. Starting next year, they are shifting to an XML format for their eligibility files that is much more generic. Unfortunately, the document for creating these XML files is well over 250 pages long and leaves many unanswered questions about what is (a) required; (b) optional; (c) deprecated or irrelevant.

The beauty of flat files is that they have been trimmed to the bare necessities over the years. With XML, it seems that the vendors are using the kitchen sink approach - because it doesn't cost anything to make them optional in the DTD, they see no need to filter out the inane. Problem is that some of the optional stuff is necessary for our business - so we have to spend an inordinate amount of time dissecting the file layout to determine what is safe to ignore. In the end, you still have to make educated guesses about how the information is used by the vendor in their claims processing software and how it impacts the data that will be returned to you at the other end.
     Possible effects from any drastic changes to IT - (dmarker2) - (20)
         This reminds me of COBOL in the 60's. - (a6l6e6x) - (2)
             Re: Just ask a Smalltalk programmer - 'ST is sooo simple' - (dmarker2)
             Sort of - (orion)
         What is IT, and how does this make them obsolete? - (ben_tilly) - (12)
             Re: Am sure we agree, issue is the question - (dmarker2) - (10)
                 XML can't kill IT - (ben_tilly) - (9)
                     Re: I am sure that is agreed (?) - (dmarker2) - (7)
                         To quote one writer on the subject . . - (Andrew Grygus) - (6)
                             XML is a container for content - (orion) - (5)
                                 Re: XML is ... Some of the definitions - (dmarker2) - (4)
                                     Gracias. - (Ashton) - (1)
                                         Re: XML is ..., WebSvcs are ... (part 2) ... - (dmarker2)
                                     Not so analogous to containerization, then. - (CRConrad) - (1)
                                         Re: Actually from several aspects - (dmarker2)
                     Re: A couple of points you raise ... - (dmarker2)
             Well, it won't affect my job - (tonytib)
         Web Services Certainly NOT! Cheaper Labor And Attitudes! - (gdaustin) - (3)
             I think there are two problems here - (drewk) - (1)
                 Perhaps I should have qualified.... - (gdaustin)
             Health care - (ChrisR)

Truly, you have a dizzying intellect.
44 ms