Category: Uncategorized

I’m Chalon Evert, currently a student at Michigan State University in East Lansing, Michigan. My studies include a major in accounting and a minor in philosophy and law. I recently developed a particular interest in information technology, spurred by a course on accounting information systems, which covered topics such as enterprise relationship diagrams and data flow diagrams.

It was a side of the accounting program unlike any I had seen in previous classes – I felt compelled to find out more beyond my one required major course on the subject. A brief meeting with my professor enlightened me on Michigan State’s information technology minor, which turns out to have too much programming for my liking, but intrigued me enough to enroll in at least one of these courses. The most valuable point of guidance from my professor about accounting information systems was that many jobs were available in the information technology sector that weren’t necessarily based in programming and would provide me with the opportunity to learn the things I needed to know outside of the classroom setting.

Approaching the summer before my so-called senior year (I plan for five years) I was still quite undecided regarding the direction I wanted to take my accounting major. I had no desire to really be an accountant, as far as the tax or audit portions are concerned. Although I find a definite advantage to knowing the practice of accounting – due to how prevalent it is to every business – sticking with the major was something I was set on. Following the advice from my professor, I was looking at local internships for technology jobs that may be available, as posted on MySpartanCareer, a site dedicated to Michigan State students seeking employment. It was from this site I discovered a posting seeking an intern at Superior Data Strategies. Thus, so it all began. (Well, after an interview process and such, of course.)

Beginning at Superior Data Strategies, or SDS, my background in database design, information technology and really computer work in general was fairly brief and surface level. I had done a few class projects with Access, Excel, Cognos and drawing E-R designs for databases, yet did not have any real experience creating databases or programming myself.

My current responsibilities at SDS can be summarized as ETL programming. ETL programming (meaning extract, transform and load) for me means to receive a data file or set of data, stage the data so it can be ready to load into a database, and then load the data into the database.

Extracting, for my purposes, has been not so much extracting but rather reception of data. How I have been tasked with this, more times than not, constitutes an email with instructions for what I am being given and what it should be. Other times, extracting involves exporting Access files to Excel.

Overall, extracting from my perspective is making the data I need or desire to have show up in an Excel workbook.

Transforming has always been done in Excel for me. The transformations are probably the most assistance I have been able to provide in my time here. This involves making the data I have extracted into something usable for our database.

As an example, say our database has a list of colors such as red, white and blue. Red could have a primary key or alias so to speak of “1,” white as “2,” and blue as “3.” The transforming process of ETL makes our Excel file display red as “1,” white “2,” and so on for all colors contained in our database. The importance is our database would not recognize “red” as an input, however, it would instead recognize “1” as representing red. Yes, this can be confusing at times!

Loading is often a quick and easy task as long as transforming has gone well. The loads, if done on Access, are as simple as a one import from Excel and saving the new table. For other loads, such as using SQLWorkbench, it can involve writing a SQL script that loads the file to the specified location. For all intents and purposes (from my perspective), the loads are predicated from how well the transformation goes, then it is just a matter of a few set guidelines getting the data to the desired location.

Any job will have its learning curves and interning at SDS is not an exception. However, I would have to attribute two separate learning curves to my position at SDS. The first was the general learning curve of the technology, terms and skills needed to be successful. As I previously mentioned, I had some experience working with Excel, Access and so on but not necessarily for the purpose of my role at SDS.

The second learning curve somewhat plays into the first. The second learning curve is on a case-by-case basis. Not all of the databases will be the same or even similar. Different steps are often needed in processing the data throughout the ETL stages. It is not uncommon to need a brief lesson or time to research before approaching a task. Patience and practice have been vital. SDS and everyone here have proven very helpful in guiding my learning. Time for my questions has always been made no matter how simple or complex. Not only the time to explain the answers if they have them, but the time to explain how to approach finding an answer or where to look. I must say I have done a countless amount of Google searches looking for insight to the difficulties I experienced.

My professor from the accounting class I brought up was correct, the outside the classroom learning experiences were vast at SDS.

Now, what I have been waiting to talk about: the office culture. I absolutely love it. One of the first questions I had talked to Aaron, SDS’s principal consultant, about on the phone was what I should wear. His response was whatever you would like to wear is fine. Personally, I prefer a baseball jersey, cotton pants and sneakers, although there are times to look nice when a client is in the office. I think this is very representative of the office culture.

Everyone is himself or herself around the office and it makes for a very comfortable setting. Whatever your music taste is, I would assume you’d hear it to some degree while there. Something I still find amusing about the office is hearing three different genres of music coming from three different offices all at once.

Aside from the differences in personality that are displayed, ideas are shared fluidly and you really feel as though your voice matters. That has been very instrumental to my development into feeling helpful. It never seemed as though my question was irrelevant no matter how far behind I truly was. I would have to imagine that the office experience at SDS is unlike any you will find elsewhere.

Without a doubt my time at SDS has been a pleasure. I am glad my professor had such valuable advice for expanding my outlook. Not only have I learned so much from everyone at the office, I have enjoyed my time here. The most rewarding aspect is seeing the final output of the projects and how it positively affects the clients’ business needs.

As a teacher, SDS Principal Consultant Aaron Fuller gets asked all kinds of things in class. We’re looking forward to exploring the top questions as a series in the SDS blog.

When talking roles and responsibilities on teams – what’s okay and what’s not?

There isn’t one right answer, because there isn’t one right way to delineate roles and responsibilities. There is a mistaken impression in our industry that there is a structure that is the best practice and everything else not correct. This is just wrong.

Your choices about roles and responsibilities are a series of trade offs between goals and challenges. Best structures for roles and responsibilities, organizational structure and titles are the ones that are best at balancing competing goals and challenges.

I’d like to offer a starting point: try to inventory what type of work needs to be done and what resources you have. In the end, all the theory, roles and responsibility and organizational structures should be secondary to putting people in the right job. Recognize that people helping people is the priority.

Too often organizations try to design their way to success – you can’t do that. You can only make it have less roadblocks. Don’t lose the view that everyone is individual. Remember that the user creates the value of the investment.

How does your team approach developing roles and responsibilities? Weigh in below!

I’ve been very pleased with the great response I’ve gotten to my recent BI This Week article, “The Big Data Honeymoon Is Over.”

Since I wrote it, I’ve continued to see and hear about more examples of what I discussed in the article. Our old struggles for good governance, architecture, design, documentation and sustainability are back again. (Well, really, they never went away.) We need to get better at continuing the practices that have always led to success while simultaneously integrating new technologies and approaches as they emerge.

Haven’t had a chance to read it yet? You can check it out here.

Let’s keep the conversation going – please weigh in in the comments below!