What's an Integration Programmer?



  • I'm on the market and a company has expressed interest, but they want an 'Integration Programmer' 

    <font class="messagecontent">By the sounds of it, it sounds like
    building an interface that bundles together (integrates) different
    systems and aggregates them into a common front end application. Am I
    on the right lines? They mentioned interface a lot, I take it this
    means the interface that the user sees, not as in programming
    interface, like a Facade to those disparate systems?
    </font>



  • I don't think so -- to me, an integration programmer is someone who uses tools like BizTalk to make different services/applications talk with eachother. For example, an intergation programmer might be responsible for having the expense report system export its data to the G/L system.



  • Do you think it's something someone who's mainly into software and applications development (particularly web applications) would enjoy?

    To be honest I'm thinking of turning it down, although the money is good, I think it's not exactly what I'm looking for.



  • Usually integration programmers are going to take 2 good products and write (crappy) interfaces between them so that is it seamless.

    Like...taking an HR system and having it setup domain/email accounts in Windows/Exchange for new hires...or having a College Student registration system automagically setup courses/faculty/students in web based courses in Blackboard, WebCT, or even Moodle.

    What technologies are you supposed to be integrating?
     



  • Job Description:

    They are looking for a technically-minded person with programming skills (either via Work or Higher Education) to work on the implementation of successful messaging middleware products, mostly carried out at client sites.  This may involve working on projects abroad.  When occasionally working at Head Office some second-line support of existing clients is expected.

    Implementation is likely to include bespoke development of TCL or Java scripts for individual sites, configuration of the site using GUI Configuration tools and setting up and using database connections.  Their clients are all major blue-chip financial institutions.  The products run under both Unix (Sun, AIX) and Windows platforms.  There is ongoing opportunity to learn new skills and new technologies.

    Initially, some or all of the following skills / experience are necessary:

    <!--[if !supportLists]-->·         Java or other programming / scripting language experience<!--[endif]-->

    <!--[if !supportLists]-->·         Experience of Linux, Unix or Windows<!--[endif]-->

    <!--[if !supportLists]-->·         SQL / relational database skills<!--[endif]-->

    <!--[if !supportLists]-->·         Knowledge of ODBC/JDBC<!--[endif]-->

    <!--[if !supportLists]-->·         Experience of XML based systems<!--[endif]-->

    <!--[if !supportLists]-->·         Experience of messaging systems<!--[endif]-->

    <!--[if !supportLists]-->·         Understanding of software development principles<!--[endif]-->

    <!--[if !supportLists]-->·         Some experience of team leadership / project management would be beneficial<!--[endif]-->

    <!--[if !supportLists]-->·         Finance industry experience is an advantage but not essential.<!--[endif]-->

    The successful candidate will probably have eighteen months to two years programming experience (via either work or Higher Education) and either an IT-related degree or Post Graduate qualification, in fact they have had significant success in this role following applications from post graduates.

    Technical competence, flexibility and an interest in learning are highly sought after characteristics.  Many clients are City-based in central London, but a willingness to travel and possibly work abroad for periods of time is required.

    Interpersonal and communication skills are important, as client contact is an essential part of this role. 

    Full product training will be provided.

     

     

    They use in house systems mainly it seems. To me it feels more like an admin type role (maintaining existing systems, configuration, setting up etc.) with some programming stuff.



  • On any given day, my team does the following:

    Write a web service to expose some set of functionality (such as taking in an ACORD-formatted request for a party search, querying our operational data store and formatting the results in the appropriate ACORD format).

    Write BizTalk orchestration services to handle complex / long-running transactions between systems.

    Write Informatica ETL jobs to move data between systems.

    Integration programming is nebulous, but it pretty much involves wiring systems together. It's sort of like being an electrician or plumber but with less ass crack. Sometimes you're invovled with defining canonical message standards, sometimes you're just the fall guy because one system is an utter piece of crap and they'd rather blame you if their stuff never works, sometimes it's your code that suddenly caused a few hundred thousand dollars of business to disappear into the ether.

    It's a mixed bag, just like any specialty... you can make it fun, just like any other specialty. We end up being the firefighters for a lot of other systems and technology, but that's more due to the skill set of our team rather than anything else.



  • I do this sort of work:

    Aggregating various performance and event data into reports, or as a pass through filter to external systems (provisioning, billing, marketing data etc...) - terabytes worth of data flows through.
    Conversely, taking external data from various legacy systems into our system for integration with reporting and provisioning.
    Building tools to support tech support, network operations center and system and network admins (via openview, stand alone, or remote) - including backup and restoration (disaster recovery) automation.
    Build and manage a CMS website to hold the reports in addition to other operational data/documentation.  Architect and manage various support systems housing my team's applications (production, development, version control repository, various LAB/test systems).
    Fixing all of the above as the architecture of the overall platform changes and new products/services rolled out.

    I am called a 'Senior Systems Developer'  - a better term would be 'GLUE'.  I will say I've learned more about computing in this environment than any other.  I wouldn't change a thing... :)  The cool thing is I drive standards (tools, protocols) for this area.  The main thing is the trains must roll on time - every time...so there is some exposure from high up the food chain when things don't go as planned - which could cost thousands or even millions of real dollars of loss.

    Very rewarding on many levels - I highly recommend it if you are serious about understanding all facets of IT and its relationship to the operational side of your business.  Also, there is so much work to do, even if I tried to automate myself out of a job - I don't think I could do it (something new everytime I walk into the office).  Maybe not as interesting as being a video game programmer or research lab developer - but right up there.
     



  • "Integration programmer" is generally synonymous with "scapegoat". Their job is to take the fall when it turns out that the systems needing integrating aren't actually compatible in any meaningful way.

    I'd avoid roles like this unless you have some particular reason to think this company is any different.



  • @asuffield said:

    "Integration programmer" is generally synonymous with "scapegoat". Their job is to take the fall when it turns out that the systems needing integrating aren't actually compatible in any meaningful way.

    I'd avoid roles like this unless you have some particular reason to think this company is any different.

    I've been doing this work for 10 years and have yet to be made a 'scapegoat' or 'take the fall'.

    If that is what happens at your company - I wouldn't want to work there either...

    And just so you know - we share data between incompatible systems, we don't try to integrate their functionality in one application - that would be unnecessarily complicated and prone to error.  Of course, this is also why we still have systems in the dusty corners of the operation that were written in the 1970s - and are still chugging along fine today; if it ain't broke, don't fix it.
     


     


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.