Should you really worry about what’s in the secret sauce?
Perhaps it speaks more to my personality than anything else, but I hate being asked, how do you do that, or what is in there? The worst are the product label scrutineers! I am talking about culinary masterpieces in the kitchen, of course, but then you knew that didn’t you ? I know my saucepans from my frying pans and I know the temperature at which to bake a sponge cake but I am afraid that when you move from baking to cooking you’re in the world of artists rather than the world of chemistry. Some chefs and master bakers might disagree.
So too, we come to the world of providing technology to the business. Sometimes we shouldn’t have anyone worry about the ingredients that went into the secret sauce of the delivered solution, Maybe the fact that it is built out of .NET components is important, but is it overridinh? After-all, it doesn’t seem so long ago that we frowned upon the use of personal devices on the corporate network like that Palm O/S device while everyone else was lugging around mobile phones the size of packets of cream cheese. Ok it wasn’t quite that bad but you get my point. I am talking here about the way that you’re getting that data in and out of your SAP system.
There are so many different ways of accessing your SAP system today. You’d be pretty hard pressed to find any single way to do everything and although the promise of simplification in architecture is out there, it will take some time before this is fully established. In the mean-time, business goes on, orders need to be placed and fulfilled and the wheels of commerce need to keep grinding on. There are probably methods and mechanisms that are in daily use, and have been established for some time, that some might raise their eyebrows at or frown upon. The point would be though, why get all bent out of shape over the specifics of the technology if it is addressing your business need consistently and reliably without compromising your system security. If you’re discovering flaws in the way your systems have been architected then instead of raising alarm bells without any clear strategy for remediation, rather spend that energy on working on the next generation of solutions that will address the business’ requirements.
I’ve noticed a trend particularly with rambunctious enterprise architects who’ve suddenly been ‘included’ in design discussions about the enterprise stack, making comments like, “we have made it a policy not to use technology yzx’ or worse, saying things like “what if SAP changes directions and kills off …”. These types of posturing and melodramatic postulating about future technologies are important. They’re important when your business precariously teeters on the brink of making a decision to completely change their business model based on technology (moving from bricks and mortar to online selling), decides to renew their manufacturing infrastructure (switch from custom built M.E.S. to an off the shelf product like WonderWare or modifies the staffing model around a particular technology stack (offshoring call centers because VoIP is supported) but it rarely plays such a major role when you’re talking about bolting improved functionality or efficiency engines onto your existing ERP system. Such technologies, like Business Objects for analytics, Crystal Reports for report writing, Syclo for mobile or Winshuttle for process automation and UI replacement are all disparate technologies. They have similarities and major differences. They all rely on SAP as the system of record and they all bring substantial business benefits for resolving very specific business problems today.
We need to get out of the mode of thinking about technology built to last with an indefinite life and start thinking about technology that solves the problems that we have today especially when you’re dealing with .NET technology. Ten years ago there was scarcely such a thing as a smartphone, SharePoint was still an emerging technology and yet today both are pretty ubiquitous. In another ten years there will be something different. A given SAP installation’s dependency on an Oracle database today may suddenly be supplanted by a HANA RDB and then your enterprise commitment today to the big O may appear to have been flawed.