Monday, October 26, 2009

No SAP for Me

Well, I thought about it long and hard. I'm giving up on SAP Data Warehousing and Business Intelligence.

I took four lessons on how to do it. I wanted the big-time cash promised in a recession proof endeavor.

So here's what I found out:

  • They told us we could really screw-up our client's data by doing the wrong thing. Me? Screw up enterprise data with an inaccurate click somewhere? I have my own problems without adding to them.
  • Does it scare anyone else that no one, SAP Engineers included, know everything there is to know about SAP? Sample question supporting the thesis: How do you create and perform boundary, integration and regression tests when you come out with new stuff?
  • I get there are four basic import routines for the stuff we were doing. Non-SAP data sources, Flat File and two, count 'em two SAP Data Sources. Hmmm. One for non-SAP and two for SAP sources. Is anyone else confused on how SAP abstracted the import (Extract), cleanse (Transform) and use (Load) processes?
  • SAP creates words that have nothing to do with function, I'll be generous and say its because the software is written in Germany by ex-IBM engineers (like there aren't any native speakers of English in the U.K. or here in the U.S. that can test terms with users and suggest better ones). I do not believe that just because we did it this way for x number or releases, its the best way to do it. An example (i.e. one that I was able to figure out): There's an object called an InfoProvider. So I spent an hour finding out that an InfoProvider isn't a non-SAP data source (which is still another SAP object) but is an internal SAP Object that provides data to the modeling and reporting tools. Oh yeah, some of the term definitions change between SAP revisions. It's no wonder SAP needs to certify users. As a goof, look up the word 'replicate' in an SAP 7.x version ETL (Extract, Transform and Load) Manual. It's not what you think it is.
  • Because of the bullet point above, I was confused. It was like Algebra in High School. It made sense while I was watching, but when I tried to do it, I was lost. Couldn't internalize the stuff. Labeling is important to me and when you start changing definitions willy-nilly, I get rattled. I couldn't tell the difference between the objects. Relational Databases have been using really good terms for a couple of decades now. For what we were doing, SAP abstracts the data and de-normalizes it (data delivery is not the goal- data manipulation is) from the key fields so it can pretty much let you do anything you want. I worked with something similar in a data intensive application where all the data goes into a single, two column table (just like SAP) and it used four other tables to identify, and if required, normalize the data- SAP uses an intermediate table with what's billed as a really cool feature, but is, in actuality nothing more than an automatic, system-assigned GUID (Global Uniform Identifier) table for data look-up and intermediate/abstracting tables and data. I just explained it to you in less than ten sentences with only a couple of jargon words. I guess that's why SAP can charge a gazillion dollars.
  • What's the most basic data import anyone ever does? Yes. Import a flat file. It took me over a week to figure out how to do it. The book (written by SAP) pretty much had nothing to do with the interface I was using. The latest version of SAP makes certain steps optional when importing data. Not by my sights. I had to create about 123 Objects four or five times each until I could do the import and there's no freakin' way I could replicate what I did and in what order.

Working with bean counters, executives and managers day in and out over the specifics of reports for weeks on end would be torture for me. I've seen others do it and do it well. I have all the respect in the world for them and am glad when they're on my team. I just can't do it. I'm much more interested in team dynamics, technology, helping folks to solve problems, improve processes and stuff like that.

To thine own self be true.

So I found out the State of Illinois might pay for PMP (Project Management Professional, i.e., a certification telling the world I can be what I've been doing for about ten years- be a project manager) and ITIL Foundation(I had to look this up on Wikipedia- it's a framework for software development, like this is hard) AND it'll pay for the test(s) andf first year membership in PMI (Project Management Institute, yeah, sounds dumb to me, too and its a really pain in the a^& to re-certify. Seems like a major gimmick to me). I have an appointment Thursday to begin figuring it out.

I talked to the wife and we both decided this stuff really wasn't in my line, just not a good fit. She's a developer and teacher. She's been trying to teach me .Net stuff for a long time: a. yeah, I can do it, b. it should work the first time I run it and c. stay away from me when I'm debugging, bounds and integration testing. No really. Stay away from  me.

We agreed I'm an IT BA, perhaps there's a decent Project Manager underneath the requirements gathering top veneer, but that's pretty much it. I know how stuff works, I have good communcation skills and can explain it to the business, developers, QA and end users. I can gather requirements, design/mock-up reports and am a pretty good jack-leg Information Architect. And I have a particular propensity for governance and process (in other words, I like systems analysis and I can help others learn different methodologies). And yes, I like using the word propensity. When I was on radio, it took the chief engineer an hour to clean up after me when I said on the air.
 
It was almost as satisfying as saying goodbye to a long tern, 'challenging' client.

I appreciated the chance to try. Right clicking on SAP objects over and over and over would drive me up a wall. I'm already a squirrel, so I see no advantage.



Powered by ScribeFire.

No comments:

Post a Comment