Like watching two vastly different galaxies collide
As data science has grown in importance, it has increasingly encountered the Information Systems (IS) department. Observing these encounters in some organizations is like watching two vastly different galaxies collide. There are many loud explosions, fierce disagreements, blinding thunderbolt flashes and a lot of misunderstanding.
What is the source of these vastly different viewpoints? Nearly everything. The culture, education, work practices, organization expectations, attitudes, reward systems, and reputation of the two communities couldn’t be more different.
Below are some examples of the profound differences between the sometimes inflexible IS department and the often swashbuckling data scientists. Narrowing these differences and building mutual understanding will deliver more value from data science for organizations.
|Data analytics adds significant business value
|Analytics becoming the new normal in business
|Is big data success eluding you?|
The IS department starts projects with a comprehensive project charter that has been thoroughly reviewed with the project sponsor and key project stakeholders.
Data scientists start projects with a barely-legible hypothesis scrawled on a whiteboard and large PLO letters in a messy workroom.
The IS department expects business analysts to develop a formal Business Requirements Document (BRD) with detailed descriptive text and diagrams. The goal is to elaborate on the high-level requirements statements in the project charter and confirm the detail with the project sponsor. In addition to functional requirements, non-functional requirements receive lots of attention.
Data scientists collaborate informally to develop the requirements using an online collaboration environment, lots of whiteboard space, and many emails. The goal is to bring leading research and data science experience to bear on proving the hypothesis. Non-functional requirements are an unimportant distraction.
The IS department wants project teams to elaborate the requirements statements into comprehensive end-user stories and then prioritize those stories for development. The goal is to fill in the inevitable gaps in the initial requirements and to ensure the most critical functionality is developed first.
Data scientists add to the design of their model iteratively as each execution reveals problems and new opportunities to converge on the hypothesis. The goal is to apply the latest data science thinking to prove or reject the hypothesis irrefutably.
Software development methodology
The IS department applies its accepted and sometimes overly bureaucratic software development methodology to the characteristics of the project to ensure quality in the planned solution.
Data scientists view development methodologies contemptuously as straitjackets that constrain creativity at best or as a crutch that helps dullards produce useful work at worst.
The IS department expects project teams to include data structures and data quality in the design to ensure that the planned application contributes to enterprise data management.
Data scientists scour the organization for data with the ferociousness that V’Ger consumed stars and planets in Star Trek: The Motion Picture. They create new columns and tables as their usefulness arises from the detailed analysis of existing data with no thought to data modelling best practices.
The IS department develops application software with rigorous peer reviews and comprehensive testing. The goal is to deliver software with as few defects as possible.
Data scientists like to keep coding until they see something they like. The goal is to fail fast and often on the road to a viable and defensible solution.
The IS department views success as delivering functional, stable applications for routine, no-drama use by the planned end-user community. If the project is reasonably on schedule and budget, that’s a bonus.
Data scientists view success as discovering breakthrough and actionable insights in the organization’s data. Error checking, disaster recovery, and data integrity are not part of the success criteria.
The IS department is proud of its detailed Information Technology Infrastructure Library (ITIL) procedures. These implement the operational methodology to achieve a high-availability computing environment that ensures superior customer satisfaction.
Data scientists never think about operational methodology. They’re looking for hidden insights to outsmart the competition and advance the company’s business plan by leaping over tall buildings. They’re only building code for themselves, never others.
The IS department plans the deployment of the new application with careful attention to people change management issues and the smooth cutover from the previous application.
Data scientists don’t expect to deploy their software to anyone else, so they don’t think about deployment. Awareness of the idea that the software should be designed to run again next week or next month without much babysitting or further development is generally absent.
Project elapsed time
The IS department tries to minimize the project elapsed time but achieving scope and quality typically take precedence.
Data scientists understand how critical first-to-market is and focus on the shortest possible project elapsed time. Considerations of software stability, ease of use, data quality, and deployability take a backseat.
Yogi Schulz has over 40 years of information technology experience in various industries. Yogi works extensively in the petroleum industry. He manages projects that arise from changes in business requirements, the need to leverage technology opportunities, and mergers. His specialties include IT strategy, web strategy and project management.
For interview requests, click here.
The opinions expressed by our columnists and contributors are theirs alone and do not inherently or expressly reflect the views of our publication.
© Troy Media
Troy Media is an editorial content provider to media outlets and its own hosted community news outlets across Canada.