The EDS Fellows’ Next Big Thing blog today discusses how business applications continue moving towards less custom coding and more off-the-shelf reusable vendor components, and the impact that has on an integrator’s knowledge of the vendor components. Interesting that some of the best minds at this large SI are pointing out that their portion of any particular job is likely to continue to shrink, something that I wrote about last week, although they don’t discuss how EDS or other large SIs are going to fill the in gaps in their past business model of “build everything”.
The point of their post is, however, how can someone working on a business application have sufficient knowledge in order to understand the strengths and weaknesses of a given vendor component when they haven’t seen the source code? They go on to provide a scientific method for gaining a deeper knowledge of a component without access to the source code, but their entire argument is based on an old-style mainframe integration (which, to be fair, was/is EDS’ sweet spot) where it was fairly common to have access to vendors’ source code.
I have to say, welcome to the real world: I’ve been doing integration for over 15 years, have a very deep knowledge of a few vendors’ products, plus a shallower knowledge of a bunch of other products, and I’ve never seen a line of vendor source code. Personally, I can’t think of very many cases where access to the source code would have improved the end result; as any good software QA team can tell you, you don’t need to see the code in order to determine the behaviour and boundaries of a component.
Furthermore, their scientific method doesn’t include a vital component: vendor relationships. If you’re building a significant business on a specific vendor’s products, you have to establish and maintain a relationship with them so as to have relatively easy access to their internal technical resources, the people further behind the customer support front line. Having done this with a couple of vendors in the past (and then being accused of being in bed with them for my efforts), I know that this is a key contributor to gaining the requisite deep knowledge for a successful integration.
could you actually say what is the difference?
Nina, thanks for your comment on a very old post!
To me, deep knowledge means that you have sufficient knowledge and experience about a vendor product to know how it will behave in any given situation, and quite a bit about optimizing its behavior. Shallow knowledge is typically just a functional understanding of the product without ever having seen it in action, or worked with it directly.