Skip to Content

Yes folks, believe it or not, there’s a job position currently advertised on Dice for someone to get involved in converting “SeeBeyond middleware” to “SAP PI(7.1) middleware”.

OK – so the “non-trivial” part of this conversion will obviously be converting from SeeBeyond’s “publish and subscribe” architecture to PI’s “bus” architecture.

But the “trivial” part of this conversion will be converting from SeeBeyond Monk or Java DTD’s to PI MT’s (and participating DT’s).

Why is this conversion trivial?

Obviously, because the syntax of the input is known and well-defined, and the syntax of the output is known and well-defined. 

So anyone with a decent flair for writing in any scripting language (Perl, etc.) can write conversion code that will probably take care of 75-80% of the DTD->MT/DT conversion problem, leaving the remainder to be handled manually.

Now I happen to know that in the context of the advertised position, there are upwards of 3000 possible SeeBeyond DTD’s that may have to be converted to PI MT’s.

Who would like to bet me that every single one of these DTD’s is going to be converted entirely “by-hand”?

I could bet every member of SDN a dollar that every single one of these DTD’s will be converted manually, and I wouldn’t have to “lay-off” any of the risk betting against myself with a second bookie.

Like I asked in the title of this blog, when-oh-when will this industry self-professionalize to the point where it’s able to look itself in the mirror when it gets up in the morning?

To report this post you need to login first.

12 Comments

You must be Logged on to comment or reply to a post.

  1. David Halitsky
    If SAP would like as many folks as possible to move from Oracle/Sun/SeeBeyond to SAP PI, wouldn’t it be worth it for SAP to write the DTD->MT conversion utility itself, and sell it as a “one-time” adapter?
    (0) 
  2. Thorsten Franz
    David,
    I just came up with the definite method of finding out whether an IT professional should be hired.
    Give them a repetitive task for half a day such as copying incoming files into four different directories and adding the file name and time to a spreadsheet, or converting DTD to MT/DT. At the end of the allotted time, ask them how they have accomplished the tasks.
    Those who haven’t written a script, or macro, or otherwise achieved some degree of automation or comfort, you should let go and not cry a single tear after them. They’d only steal your time if they were working for you.
    Embrace the other ones, they will make good techies, especially if you have used the opportunity to learn more about a toolset rather than staying completely within their comfort zone. E.g. I would give my dear colleague Tobias Trapp extra credit for using perl instead of the XML transformations he can perform in his sleep.
    As always good it’s good to read your thought-inspiring blogs.
    Cheers,
    Thorsten
    (0) 
    1. David Halitsky
      Thanks for the kind words, Thorsten.  But I feel compelled to point out that you’re thinking of the problem at the individual level, when it’s really an INSTITUTIONAL problem way up at the level of the econonmics of our friendly systems integrators.  (You may not experience the problem at this level, because I think you work for an actual company, not an integrator or consulting firm.)  To be continued – out of space

      The p

      (0) 
      1. Thorsten Franz
        Oh, I didn’t mean that so much as a statement about the state of the industry as you diagnose it here. I just wanted to give you credit because your blog made me think of the solution for a problem that has been bugging me for a while, namely an easy way to sort the wheat from the chaff in the techie recruiting process. Of course it won’t heal the industry if my company manages to pick better candidates.
        The company I work for is an Independent Software Vendor (ISV) that produces an SAP-based industry solution, and even offers consulting and implementation services for this solution, so we might be dangerously close to being an integrator or consulting firm. But our economics function indeed completely different from the “Butts and Seats” model.
        Cheers,
        Thorsten
        (0) 
        1. David Halitsky
          Glad to know your company is not in the “b and s” mode … by the way, how would you say “butts and seats” in German?  Is there an idiomatic equivalent?
          (0) 
          1. Thorsten Franz
            Hm, I’m not aware of a German expression with similar conciseness or vividness as “butts on seats”, so the closest that comes to mind is “Stunden kloppen” (colloquial, but the high German “Stunden klopfen” is uncommon). It means “to bang away or hammer hours” and I think it was originally used by miners to describe working long hours for extra money.
            (0) 
    2. David Halitsky
      Anyway – as I was saying – it’s not that the big systems integrators don’t know any better – it’s that they’re greedy and short-sighted – just like all companies in today’s world – eye on the bottom line and the next quarterly announcement and nothing else.   So they choose to have their people stupid (10 buuts on 10 seats) instead of one Perl stylist on one seat because it generates 10 times more revenue in the short-run.  Of course, if anyone of the big systems integrators would just have the courage to break this shortsighted greedy modus operandi and start working smart, I believe that clients would flock to them and the old dinosaurs who want to keep filling seats with butts to satisfy Wall Street would die out from the same kind of natural selection (failure to adapt) that always operates when there’s a new game in town.
      (0) 
      1. Thorsten Franz
        Not sure when or if at all the big system integrators are going to reach this point, but lately I was happy to see a few examples of smaller consulting firms and software companies working niche markets that bet on awesomeness: delivering exceptionally good value for not so much money, billing far fewer hours than they could get away with, and hoping for a positive impact on business in the long run: good reputation, new partnerships and customers and lots of follow-up projects.
        That’s a great trend and I hope it will become stronger because I fear that the short-sighted approach to burn hours but deliver little value is going to drain IT budgets and ultimately suffocate the industry because if spending on IT doesn’t generate sufficient value it will simply stop.
        Cheers,
        Thorsten
        (0) 
    3. Martin English
      Apart from the time you save, there’s the QA and Change Control aspects as well…

      1) Better Quality work because you have a controllable standard process.  I remember reading in one the Quality Circle / Kaizen / etc books last century that a japanese auto maker stopped doing final quality checks on a particular assembly line.  The individual processes were so standardised, with such little variation, that the QC people were finding nothing wrong.

      2) Better Change Control because if it turns out that you need to allow for one extra variable or key field, then by incorporating it once in the process means its incorporated in all instances of the process, AND all subsequent instances of the output.

      Laziness, impatience and hubris

      (0) 
      1. David Halitsky
        Hi Martin –

        It’s great to see someone (you) bring up QA and Change Control in the context of a discussion centered on efficiency vs economics. 

        About four years ago, I did a series of blogs here on something called a “Diachronic Metadata Repository”:

        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/1151
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/1290
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/4760
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/4767
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/4777
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/4783
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/4806
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/4824
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/4833
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/4878
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/4897
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/4932
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/4973
        http://weblogs.sdn.sap.com/cs/weblog/view/wlg/5022

        If you look at Figures 22 and 23 in the last post (Part 13 – #5022), you’ll see that the point I was trying to make in those figures was very very close to the point you’ve just made about how process-standardization leads to value-added economies for the client in unexpected ways.  (I listed all of the installments of the series above only because I’m not sure that Figures 22 and 23 in the final post are fully understandable without some knowledge of what went before …)

        In any event, I completely agree that systems integrators should take a more holistic view of the overall implementation process than is currently taken …

        (0) 
        1. Martin English
          thanks for the kind words.

          I take your point about the “value-added economies for the client in unexpected ways.”  As far as I’m concerned, they were only unexpected the first couple of times, now they’re an expected payoff 🙂

          One point a lot of people forget is that you can start small…  back in my MVS days, my first introduction to ‘automation’ was using a template for compilations that I changed (via a global edit command) for each compile as opposed to having to write a new job for each compile.

          Just as an aside, there’s the personal part  – I’m a cranky old SOB at heart.  If I’ve done it once (properly), I shouldn’t have to keep doing it again and again !!

          Unfortunately, though, I think a few people have been burned (or burnt their employers / customers).  Even when done well, automation adds an extra layer of complexity and abstraction to the process (hopefully only a small layer).  If it turns out that the original ‘automator’ used some arcane technique or technology, it can start getting in the way of efficiency.  The real problem is defining ‘arcane’ – I know some ABAP programmers for whom stepping outside the SAP Gui is fraught with danger.

          This gets back to Thorsten’s original point; the skills of the people doing the work.  As far as SI’s (and Customers) are concerned, people are hired (not just in the SAP practices) because the resume fits the current project requirements.  Extras like an ABAPer knowing perl or python just aren’t considered important. 

          I don’t know what the answer is, I just do my best to show how useful these extra skills can make me (even if, in my case, they’re more about where to steal per; / python / etc from, rather than writing it !!).  Hopefully, once the customer and the management see that these are useful skills, they will start looking for others who have them; Once fellow employees see the usefulness of these tools, they will start using them.

          (0) 
          1. David Halitsky
            Martin – yes – “automation of automation” is necessarily abstruse, and anything abstruse is harder to manage than anything intuitively obvious and familiar.

            But this issue brings to mind (to my mind at least) the old saying “Physician heal thyself!”

            If an SI (systems integrator) cannot sucessfully automate the production of its own product (automation), why should any company trust the SI to automate the production of the company’s product?

            By the way, I wish folks would stop saying “back in the MVS days” like you just wrote.  As you know, 4GL databases with TP monitors ran under MVS as what were affectionately called “MUSASSES” (multi-user single address spaces) in which each user was assigned a thread with certain resources and usually, a user who crashed would not crash the entire MUSAS.

            Fast forward to 2004/2005, when SAP proudly announced a flavor of the SAP JAVA stack that would allow a user to crash without crashing JAVA for everyone.

            Sound familiar?  It should – the JAVA world had rediscovered the IBM MVS world-view 30-odd years later.

            So to me, it’s always “back to the future” in this business – these ARE the good old days, at least for folks old enough to have what’s called “institutional memory”.

            (0) 

Leave a Reply