In my last post Executive Summary: Strategic Data Science, I have summarized what Data Science is and what it consist of. Moreover, you need to deploy a strategy that helps you manage transformation to a data-driven business.
Today, you will see that a strategy for data science can be handled just like any data strategy. And if you already have a data strategy deployed, e.g. as part of your governance or architecture initiative, then you will see why and where it is affected.
As written in Executive Summary on EA Maturity, having a map knowing where you are and where you want to go to helps a lot in finding a way.
Maturity
If you are working with maturity models, you typically do this on a yearly basis. For chosen capabilities you identify current vs target maturity e.g. ranked from level 1 to 5.
The first thing you need to understand is that introducing data science for the first time reduces your overall maturity at once. Why is that?
Maturity is measured in terms of capabilities. And if you take a look into those capabilities you will find that you need to adapt them. There typically are a dozen or so like vision, objectives, people, processes, policies, master data management, business intelligence, big data analytics, data quality, data modeling, data asset planning, data integration, and metadata management.
I will pick only a few as examples to make things clear. Let’s pick vision, people, and technology.
Selected Capabilities for Explaining Maturity of Data Strategy
Vision
Say you have a vision like: “Providing customer care that is so satisfying, that every customer comes back to us with a smile”. That’s a very strong statement, but how about: “Keeping every customer satisfied by solving all problems before complaining”. Wow, even stronger. It is possible because Data Science allows you to predict what others can’t.
People
Probably, you already have a data architect. But, the classic data architect focuses on architecture, technology, and governance issues. This is OK, but you also need some data advisor focusing on unseen solutions for the business. Someone telling you to combine customer data with product usage data increasing your sales. And perhaps even telling you from which of your precious data you can create completely new data-driven products you can sell.
Technology
Probably, you also have an inventory telling you which data sources are used in your applications. Adding Data Science as rapidly growing discipline to the equation, you may find that you will have to revise your technology portfolio. It is rapidly growing and changing and, therefore, needs to be governed to a certain amount (freedom vs standardization).
Following list shows selected technologies that are most often used in Data Science (ranked from left to right).
Programming Languages: SQL, Python, R
Relational Databases: MySQL, MS SQL Server, PostgreSQL
Big data platforms: Spark, Hive, MongoDB
Spreadsheets, BI, Reporting: Excel, Power BI, QlikView
Moreover, there is a shift in who is actually using these technologies like Leadership, Finance, Sales, and Marketing. And more often without dedicated enterprise applications because data analysis is very dynamic and has a lot of try and error to it.
Conclusion
From these view capabilities out of a dozen+ it has become clear that Data Science Strategy easily fits into an overall Data Strategy. There is no need to reinvent the wheel. Instead, adapt your existing or favorite Data Strategy to incorparate Data Science.
If you as C-level are already using or plan to use data science you probably pursue the goal to increase your market share by making predictions that others can’t. You might think that there is no need for strategic management of data science. Actually, that’s as far from the truth as it can get. But, why is that? It is because there may be a lot of complexity indicated by the figure below and discussed in the following.
The Flower of Complexity
Definition
First, let’s take a look into the definition
Data science is an inter-disciplinary field that uses scientific methods, processes, algorithms and systems to extract knowledge and insights from many structural and unstructured data.
source: wikipedia
There are a lot of keywords in this rather short definition that should raise your eyebrows: inter-disciplinary, methods, processes, algorithms, systems, many.
Basic Method
Now, let’s pick a keyword from above and dig deeper e.g. recall the basic scientific method:
Find a question
Collect data
Prepare data for analysis
Create model
Evaluate model
Deploy model
Doesn’t sound overly complex, but let’s finally deep dive. Which of those phases do you think is responsible for most of the effort spent? It is the step that roughly amounts to 80% of the overall process! There are even several synonyms for it like data munging, data wrangling, and data cleaning or cleansing. You guessed right, it is phase three. Its complexity is mainly driven by the number of different data sources, the number and complexity of involved data structures, and sometimes also mixed with unstructured data.
Conclusion
We can go on like this for a while, but I do not want to bore you with the details. So, let’s summarize first and I will deliver a compressed list of further aspects afterward which you may take note of or skip altogether.
Forecast: If you do not strategically manage data science in your enterprise you may expect another area of proliferation which you should urgently avoid!
Solution: I can help you with that. My approach is to combine data science with an architecture development cycle. Proven methods and tools will help you to master the inherent complexity and get the most out of data science for your business. You can leave the details to me.
The Details
Data science as a discipline delivers methods like the one we have discussed above. Yet, it also
combines subjects like
computer science
math & statistics
business domain knowledge
involves interdisciplinary roles like
Data Engineer
Data Scientist
Business Analyst
Product Owner / Project Manager
Developer
User Interface Specialist
implies many skills like
programming
working with data
descriptive statistics
data visualization
statistical modeling
handling Big Data
machine learning
deploying to production
is done with many tools like (only top 3-4 in each category named here)
programming languages
SQL
Python
R
…
databases
MySQL
MS SQL Server
PostgreSQL
Oracle
…
Big data platforms
Spark
Hive
MongoDB
Amazon Redshift
…
Spreadsheets, BI, Reporting
Excel
Power BI
QlikView
…
And the list is growing steadily. A little exhausting, isn’t it? At this point latest you should be convinced that data science needs strategic attention.
If you have the impression that your enterprise architecture is viewed as an ivory tower from the viewpoints of various stakeholders then read on.
In this post, we first try to understand why and identify the causes of the ivory tower syndrome. Then, we will address how to tear that ivory tower down or ideally not even build one. These findings will be picked up again in follow-up posts. Stay informed.
Carrot and Stick
Bonus and fear drive many things, in other words, reward and penalty, carrot and stick. Bonus systems are e.g. used in target agreements promising some factor of a defined bonus when achieving defined targets to certain degrees or percentages. Fear works the other way round, also psychologically, like “promising” a penalty when breaking defined rules, or warning you on risks if not complying to security rules.
Now, in practice, both approaches are typically combined and may vary in terms of weight or focus. Let’s take a look into some examples. The third example might look like being out of line, but I promise you will get the connection and probably also draw some conclusions on your own without further explanation.
Scenarios
Scenario 1: Lisa is CIO of passend AG and Jonas is the Enterprise Architect reporting to Lisa. They have a rather small concise set of rules and a community for sharing the transition of strategic thoughts into budgeted initiatives. A lot of projects do already stick to the rules which is mainly driven by sharing services and cutting costs.
Scenario2: Karl is CIO of AusPrinzip GmbH and Julia is the Enterprise Architect reporting to Karl. While they had some quick wins with a target architecture and road map to get there everyday, live has become tedious. Many of the defined rules are broken by a significant number of products (e.g. applications). Jutta can only deal with a few projects at the same time. A lot of executive force is missing not to talk about jurisdicative.
Scenario 3: Elena is major of some city in Germany and Johannes is head of urban planning reporting to Elena. There are plenty of building laws and a building authority which employees inspect all building plans as well as construction and finished buildings on site with respect to those laws. Non-compliance gets fined or even brought to jurisdicative.
Urban Planning
The first two examples are typical scenarios you may find in any industry while scenario 3 stems from urban planning – constructing cities, streets, and other infrastructure that we are so used to. While some concepts from urban planning cannot simply be transferred to enterprise architecture, we can understand and learn a lot by comparison from this more mature discipline. Roughly, enterprise architecture is to software architecture what urban planning is to construction planning.
Analysis of Scenarios
While scenario 1 rather reflects a sunny day, scenario 2 comes with a lot of dark clouds, metaphorically speaking. But, why is this?
Well, rather than focusing on more wins after the quick wins, Julia gave in to the grand idea of having an architecture law from §1 to §999. So beautiful, but unfortunately doomed from the beginning to be only a paper tiger. If you are neither providing for an adequately equipped “building authority” nor a jurisdiction, you’ll end up toothless. Without adequate authority you do not have sufficient control. Without jurisdiction you can neither dispence justice nor punishment.
Improvement
What are the options for improvement?
Create an adequate authority.
Cut down architecture laws to a few.
Balance authority with architecture laws.
Combine authority with other disciplines like revision, portfolio, security, quality management.
Mostly forget about jurisdiction.
An enterprise has no internal jurisdiction.
You might integrate with revision, but revision only recommends actions to executives which in the end can cut budgets as interpretation of punishment.
What else can you do besides authority and jurisdiction?
Align with objectives of managers.
If you succeed in implanting architectural objectives as personal objectives for managers then you create a win-win situation.
Implement cost saving services for architecture laws
E.g., you would like to enforce some software like CRM as standard to use for a defined context like customer care.
Ensure a good contract with the vendor.
Set up scalable infrastructure.
Provide licenses that make projects happy (cutting costs).
Build up know-how.
Include employees feelings.
Learn from good management principles.
Things in a company mostly work well because of well motivated employees.
Make the doers feeling great about their work by making their work visible and showing their relevance.
Easy example nowadays: your cloud gurus.
Make one or few architecture laws with them together.
Mr CIO calls me second time and tells me that Mrs IT Governance and Mr Lead Solution Architect have given very good feedback regarding our first meeting call. We had to do it remotely, but why not, cams were working and was safe – my home is my business castle. In consequence, they would like to get started with me boosting Enterprise Architecture. So, we discuss some points relevant for my offer which I deliver at noon.
In the evening, I ask myself: “New clients, new situation, now where do we start?”.
Since architects are librarians too, I scan all I got. Best matches first. Slides. Questionnaires. What not. One of those slides contains a diagram from some tool, even better, start it, open the model, and holding my breath while faded memories are being recovered back into my 1st level brain cache. There it is, the EA maturity model, gotcha. And better yet, it is just a puzzle piece of something even bigger – the EA handbook! I just love sustainability.
In the meantime, my brain floods itself with new questions and ideas: what about this agile transition, what about this different industry, what about mergers, what has been good, what can be improved, …
Let’s take a break. Back to that maturity model. I really like it because it has been so successful. It solved the issue of varying expectations and especially the expectation of reaching what I call level 5 in the very same year.
While there are many such maturity models around, let’s stick to this selected example. It makes things more clear.
Before we can reach level 5 Optimizing to the right we need to climb level 4 Quantitavely Managed. And before that, we need to climb level 3 Defined, level 2 Managed, and level 1 Initial far to the left if not yet already climbed. But, we can soften the climbing. I will come back to this later.
The title “Increase maturity by repeatedly …” tells everybody that we need to repeat. We repeatedly test promised benefits. Define a few objectives, work towards those, test promised benefits, report. Repeat.
In addition, there are selected success factors. Theoretically, there may be more. But, let’s start somewhere and get commitment. We do not want ivory towers. Therefore, we build EA to the customer. It is OK to think big (remember level 5) as long as we start small and agile, step by step. EA itself is lame and its power only unfolds with integration into the organization and already established processes. And please do not skip levels! Now, if you take a closer look into adjacent levels you will recognize that some contained objectives are similar but not the same. There is step-wise improvement to repeating aspects. E.g., we may learn that our application landscape is a little patchy. So, next level for this might be to close the gaps. And the level after that might be establishing a process that our application landscape remains “unpatchy”. You get the idea.
Let’s take a look at those *-annotations for selected objectives inside the levels. An objective is annotated with a ‘*’ if it shall be achieved by end of year (or any fitting end of time window). What you may also have recognized is that beneath the levels there are some percentages given. Each percentage tells you how much of the level shall be achieved. Breaking the levels down into objectives for evolving aspects allows us to work on more than one level at the same time. This is a very important aspect for the client and pays a lot into acceptance since we do not necessarily have to achieve one level completely before peeking into the next and the next after. It is not a computer game in the end, no final bosses to beat. In this example you can easily see that the client wants to drive things along an up-to-date, consistent EA database being convinced that it might be the very basis for everything else regarding the EA discipline. That is clearly a data-driven approach. While the overall benefit of such a database might not be easy to measure, I at least and in retrospection of my work as project and application architect can savely say that it saves a lot of time and easily allows you to deliver your milestones. Why reinvent the wheel all the time? There are many other approaches than this data-driven one in the given scenario. It is only one possible outcome in a multiverse of outcomes. The conclusion may be that the maturity model might be viewed as a loosely coupled matrix of objectives and provides a lot of options to choose from. Finally, options mostly are what architecture is all about.
