Images of the “Information Silo”, the “Data Warehouse”, “Data Management” and “Business Intelligence” could undoubtedly conjur up humorous images for the graphically or artistically endowed technologist. Traveling through farmland as I often do, I often see the farm silos and chuckle to myself as I think of “Information Silos”. I wish I had the talent to create caricatures of the images I think of when encountering these terms – I’m sure they could evoke a chuckle from somebody other than I.
Anyway, that being said, these terms are no laughing matter for those faced with the real challenge of making simple the complexity of data available to companies today. From my experience I’d say that most companies – even those single location small companies, have a multitude of information stored in a multitude of systems. The “systems” containing this data may be an individual PC, a company ERP system on a server, a sales (CRM) system (maybe on a multitude of salespersons laptops) – each its own “silo”.
There are many stories of failed BI implementations. Why? I would posit that users trust their data and information, but not necessarily that coming from say, the IT department. They know where “their” data is coming from, how it was collected, and it’s meaning – because its “theirs”! Whether it presents a complete picture, or is applicable in all instances is totally irrelevant – just ask that branch manager, or department manager … or whoever has the data.
That being said, I’d say that perhaps key to getting the most value from the data you have available is getting the buy-in of the end-users of the data in regard to data source and reliability. If a data source is to be used, do the end-users “trust” the data? No trust – Don’t use it! An interesting post suggesting 3 causes of failure for BI implementations is available here – an interesting read.
A recent post by fellow ITKE blogger John Wilder entitled “Sparking Innovation” caught my eye this morning and I just have to comment.
His statement that “…I trust my users to come up with innovative ways of using some of these new products, and I’m not so sure that IT would ever be able to envision all the possible uses…” immediately brought my mind into the many situations I have experienced where my users innovative ways of using a piece of software has resulted in their identifying ways in which IT (…or the developer/tester) certainly had not envisioned it would be used. Is it a bug when software isn’t used in a manner for which it was designed? Bug or not, the situation has often led to “changes” to the software. I believe that users, because of their innovative approaches to use CAN be the best of software quality testers — but developer beware!
John also refers to a situation where program use is resulting in a tension between a direction that IT is promoting and another approach suggested by the users. This kind of tension between application use has been a common experience for me when developing custom programs for my customers. Some users will prefer one direction, and others another. IT and the developer walk a tightrope between users every time this situation manifests itself.
It’s like the stock market – it can be risky – it can be frustrating and downright annoying – and it can be rewarding. I’ve always liked participating in beta testing of products which I find of value, or as has happend to me before, in a product that I had to use – but (let’s just say to be nice), needed a lot of work — and by beta testing (with our live data of course) we got to evaluate the latest and greatest of the software. Most of the time it was a win-win situation, but not always.
I wrote a few weeks ago about how my chiropractor didn’t realize what it meant to be a beta test site, and consequently just how much she “suffered” with the arrangement.
For me, as a custom software developer, I think I like participating in anothers beta test because I invevitably learn from the experience. There are 2 major learning opportunites that I consider to provide the value for me by participating — they are:
- The opportunity to really learn a product and understand it
- The opportunity to find out just how the software provider works
Products and companies have made it and lost it based upon my experience with beta testing their product. If a company isn’t easy to work with when you are providing beta testing, they probably aren’t a company you’ll want to work with long term. Likewise with the product.
Green IT — you’ve read and heard a lot about it recently. Green (whatever) is the color of the day, week – indeed future.
However, I can’t help but think about all the trees we were going to save by having our computers do all the work for us, and then present results without paper! Remember the paperless office? Talk about the paperless society? …and wouldn’t paperless be a good green initiative? The paperless office sounded like a good idea at the time, but I venture to say that for most companies efforts to be paperless have gone stagnant – and why is that?
Could it be that perhaps it just doesn’t work? Could it be that people still want to read or skim over printed pages rather than fuss with a mouse, or read something on a screen limited in its display, and positioned (normally) very differently than say when one reads a book or newspaper? Have you ever seen someone curled up comfortably in their easy chair reading a computer? I for one have not!
While I believe we have made great strides in some areas toward minimizing paper use with programs such as on-line libraries of scanned business documents, B2B invoicing, data warehousing and “Business Intelligence – given the increase in data now available because of our faster, more powerful computers I submit that perhaps at best we’re holding our own. The additional computing power and data analysis has meant mroe computers, which of course means more energy — so we now add in virtualization of said servers – and the cycle starts again. First we had a prolific growth in physical servers, now it’s virtualized servers – and software wanting to run on its own server spurs more growth.
Of course there’s also the other green – the long green (aka US $). We want to do all this “greening” without spending the long green. Most “green” initiatives don’t save money in the short term, and in the economy of today investment in the long term is limited due to short funds.
Finally there’s the last “green” I’ll refer to — that of the “green” with envy kind of green, also known in a previous era as “keeping up with the Jones’s”. The Jones’s have something that you perceive as good – so you want it! So what if it uses up more resources. While there is a lot at stake for us as a global society by “going green”, I’m seeing much talk, but little action. Shifting from one resource drain (such as power consumption) to another (such as serving up twice as much paper in printed documents) hardly seems green to me.
One doesn’t have to look far to find someone in their life whose work-life balance is, putting it nicely, far out of proportion – usually with the “life” area suffering from lack of attention. I must admit that I have struggled with this all of my life. My natural tendency has always been to put work at the top of my “todo” list (…that is IF I even bothered to make a list!). In my earlier years there was no question about where my priority was – work, work, work – and coming in a distant forth and beyond everything else.
Fortunately now, for those around me, I have a far better balance between my work and “the rest of my life”. The resulting change in my well-being has been significant – but there were many lessons I needed to learn before reaching some semblence of balance. (Like the trauma of a failed business and a stressed marriage to start with).
There is a high cost associated with Work-Life Imbalance – both to employee AND employer. For an individual such as an independent software developer – it can be huge! I have never seen any indications that burn-out, health issues or relational problems has ever helped boost productivity! Regardless of ones occupational position, the maintenance of work-life balance is critical for employers to recognize and encourage.
It’s NOT easy to achieve however!
A few days ago I blogged about how I was playing detective with a clients computer system, struggling with performance issues. It has been an interesting few days since that blog, and I have discovered much, and learned along the way.
One thing that I learned about is a nifty utility offered by Microsoft which can aid in the analysis of exactly what’s going on with your Windows 2003 Server. The utility is called Server Performance Advisor. The utility is particularly helpful for presentation of data which is collected by the multitude of logs kept as part of normal server operations. It also provides additional information and combines it in a much more understandable manner than just reviewing raw log data.
Starting with a system overview, it can also provide information about other common services provided by the server, like IIS, DNS, Active Directory and others. It includes useful help! Depending upon the selection of services the utlility collects data for either 100 or 300 seconds, and then creates analysis of the data.
If you have a Windows Server 2003 and are not familiar with this tool I’d recommend it highly. Follow the link to Server Performance Advisor for more information.
My search for answers this week also took me to an article on Computerworld outlining 10 Great Free Network Tools. Since the analysis of my performance issue indicated that the issue was not network related I did not follow-up with any of these network tools, but I pass the link on for what its worth. Hopefully it can help someone out.
I wrote a couple of days ago about how I thought that we independent developers had to be partially detective, and indeed not just developers, but pretty much in any IT position that we may hold. My last post really was somewhat of an example where the developer was acting more like a business consultant than developer. He had identified a process issue, and the prospect wasn’t open to the “business consultant” service he was getting from the developer. (From the owners view, there was nothing wrong with his business (process), it was a computer application problem!).
Another example of a developer becoming business consultant came to my attention yesterday. It seems that the developer was asked to come out and evaluate the clients application to ensure that it was doing what it was supposed to, and also to ensure that there were no “workarounds” that could be used by dishonest employees to “skim” inventory. It seems that there had been major issues with generic inventory shortages, and the company management suspected possible theft.
The developer went on-site and performed an exhaustive evaluation of the application and the processes in place and had found nothing out of the ordinary or unexpected. The developer was wearing his “detective” hat at that point.
Now, while waiting for management to become available to report his findings, the developer (detective) became aware of something — the phone had rung, and the counter person took an order, pulled a few items from inventory. He then excused himself to the developer saying he had to bring these items out to the shop. The developer noticed that he had done nothing with the inventory system, and upon the employees return began to question him about what he had just witnessed.
The company stocked a series of tools which were of standard sizes, but that could then be slightly modified by a secondary process to in effect provide a “custom” item. Upon further conversation with the employee it was established that it was a common practice to take items out to the shop to be “customized”, and they were then sold as a “special order” item. “Special Order” items were not inventoried.
At this point the “detective” became the “business consultant”. Records of the “special order” sales indicated that the suspected “losses” of inventory were in fact due to the movement (without any record keeping) of the items to be turned into the non-inventory special order items. Records showed that the missing inventory was completely accounted for after reviewing the special order sales – there was no theft issue. Rather it was a business process issue.
That this situation was noticed was truly due to the skill of the developer as detective and business consultant. It should also be noted that Lady Luck played her part in that since management wasn’t available for the developers “final report” he witnessed what he did that ended up identifying the issue at hand. It all worked out!
Just another day as an independent application developer!
When an independent application software developer first meets with a prospective new client it becomes very much a meeting where each party is evaluating the other. For the developer it becomes questions of “Is this an organization I can work with? Can I provide what they are looking for? Can they pay me? Do I want to do the proposed work for this organization?”. For the prospective client the questions become “Can I get what I want from this developer? Is the talent there to provide the service? Can I afford the service? Can I work with this developer? Do I want to work with this developer?” All good questions - left generally unspoken.
In speaking with a fellow developer today I was reminded of this by a story he told of one such interview where he decided that he was NOT interested in doing work for the prospective organization — and the reason? Basically it came down to the prospect being firmly entrenched in a business practice that was just plain poor. The application in question was an inventory application – the problem to be solved was to have a system that kept inventory straight. The “real” issue, quickly identified for the prospect was their practice of transferring inventory from store to store. They used hand-written packing lists for the transfers.
There were 2 locations, each keeping their own separate inventory system. Each properly received inventory, and inventory was in fact properly relieved by the sales function. The system wasn’t used at all for the transfer of goods from one location to another — no surprise that inventory was off! Since the system for each store was independent of the other, neither system “knew” of the movement of goods to the other location. So, you had a system where goods were received properly, but not properly relieved at the location shipping the goods!
My developer friend thought it best to stay away from this potentially difficult situation, and suggested that the prospect find a developer who was willing to do the work as desired. The moral of this story? Not all business processes deserve to be duplicated. In this case, the issue was not the computer application that was the problem, but rather how it was being used.
The story also illustrates very well one of the situations that I always try to become aware of at a clients site when I’m there – “What are they doing manually that could easily be in an application? Why isn’t it?” The manual packing list is in my book a BIG red flag! It signals stop, look, and be cautious.
P.S. My friend later found out that this company’s “new” inventory system didn’t work any better – at least until the business process was changed.
Sometimes I feel more like I’m a detective than programmer/analyst. Fact is, I believe, that there has to be at least a little bit of detective in every IT person who has the opportunity to evaluate software applications and their sometimes strange behaviors.
As an example of what I mean, I share with you an opportunity I’ve been presented that has surely become a mystery worthy of any good detective – or perhaps a sick mind :-). Picture this, an application that runs flawlessly and with acceptable speed on a minimally configured server when moved to a new “high-end” server slows down to borderline acceptable performance – clearly and noticeably slower than the old one. Both systems use RAID 5, both are running MS Server 2003 SBS. Main difference between new and old is that new uses more powerful chips, faster drives, 4 times the RAM and gigabit network connectivity – none of which cause me to suspect that it should run slower than the old.
The issue was called to my attention after the company “network” guys had all but thrown up their hands and said basically “…it must be the application…”. It seems very hard to believe that it would be anything other than configuration of “something” on the new server.
As yet the issue remains unsolved – but I use it to highlight one of the great challenges that we in the IT field are presented with . One need not look beyond the next IT person you talk with to find the next “detective” story or unsolved mystery. We are faced with them constantly. We need software and hardware tools, knowledge bases and lots of experience to investigate and solve such issues. Issues which cross various specialties such as security, networking, programming, application testing and design require us to be “detective” – to ask the right persons the right questions – to find the right tool to identify the cause of the problem, as well as to recognize opportunities to “check into”.
“Lots of luck” also helps!
I read with dismay and a good deal of reflection a recent article entitled “Why women quit Technology Careers” and comments posted to the article by an Anonymous (presumeably female) reader. This article caught my attention on numerous levels — the first being that somehow through my years I have become a champion for women in their jobs – be it technology or other. I’ve seen too many very capable women move on because their work was somehow devalued, considered somehow to be less than their male counterparts.
Secondly the article made some references to work-life balance. The article states that “…in tech, the average workweek is 71 hours…”. In my book this is just unacceptable – not that I haven’t done it of course! However, it still was not acceptable. I remember picking up the phrase from someone that said “…we work to live, we don’t live to work…”. I’ve always worked long hours, but I’ve also chosen work that I love to do. Enjoying one’s work in and of itself I believe provides a level of work-life balance.
That being said, I believe that in technology anyone, male or female, who leans toward a more “normal” work-life balance leaves themselves open for criticism and all too often become devalued in their workplace. For example, I remember how a worker at a vendor of mine was viewed after he took “maternity” leave to be with his wife and new baby. “Mr. Mom” lost significant respect among his fellow workers for his choice, while managing to keep his job after all the time off.
I really believe that when all is said and done the reason why tech people leave their field often has little to do with hours, but rather has to do with how they are perceived and treated in their workplace. If they feel valued, if they are not isolated, if they are trusted, if they like what they do — they stick around.