How Silos in the Marketing Organization Thwart Alignment with IT

According to a global survey of marketing professionals by Teradata, 74 percent of the respondents said that marketing and IT are not strategic partners in their companies

Data is an asset that should be shared across the organization to discover patterns of behavior and pinpoint areas of opportunity to be leveraged by sales, marketing and customer service. While data collection has historically occurred most often within the IT organization, the analysis of that data is often the responsibility of customer insights managers or data scientists, who must work cross-functionally with both marketing and IT. Greater collaboration and partnership between the worlds of marketing and IT power deep, actionable understanding of the customer—and companies who drive their businesses with customer data are best positioned to win.

However, using all the data together is what drives a great customer experience, and according to a McKinsey study, 70 percent of customers buy based on how they are treated. As for how IT can assist, it is truly about collaboration between marketing and IT, or between CMO and CIO, and the broader strategy of the company being driven by the C-suite. You might point readers to a post written earlier this year by our company president about why this need is so critical.

http://www.itbusinessedge.com/blogs/from-under-the-rug/how-silos-in-the-marketing-organization-thwart-alignment-with-it.html

Doherty Threshold

Update: The original version of this post incorrectly stated that the Doherty Threshold was not a real thing. That was incorrect. Here's the Doherty Threshold, listed on the IBM website, as described by author Walter J. Doherty in 1982. As shown in this episode of Halt and Catch Fire, it is when a computer has a response time of less than half a second:

When a computer and its users interact at a pace that ensures that neither has to wait on the other, productivity soars, the cost of the work done on the computer tumbles, employees get more satisfaction from their work, and its quality tends to improve. Few online computer systems are this well balanced; few executives are aware that such a balance is economically and technically feasible. In fact, at one time it was thought that a relatively slow response, up to two seconds, was acceptable because the person was thinking about the next task. Research on rapid response time now indicates that this earlier theory is not borne out by the facts: productivity increases in more than direct proportion to a decrease in response time.

Source: http://gizmodo.com/halt-and-catch-fire-episode-four-donna-is-here-to-solv-1594879529


The Economic Value of Rapid Response Time

A transaction consists of a user command from a terminal and the system's reply. It is the fundamental unit of work for online system users. It can be divided into two time sequences (Figure 1):
User Response Time. This is the time span between the moment a user receives a complete reply to one command and enters the next command. People often refer to this as think time.
System Response Time. This is the time span between the moment the user enters a command and the moment a complete response is displayed on the terminal. System response time can be further divided into:

• Computer response time, the time the computer actually spends processing and servicing the user's command
• Communication time, the transit time for a command to go to the computer and the time for the reply to come back

...
He and Richard P. Kelisky, Director of Computing Systems for IBM's Research Division, wrote about their observations in 1979, "...each second of system response degradation leads to a similar degradation added to the user's time for the following [command]. This phenomenon seems to be related to an individual's attention span. The traditional model of a person thinking after each system response appears to be inaccurate. Instead, people seem to have a sequence of actions in mind, contained in a short-term mental memory buffer. Increases in SRT [system response time] seem to disrupt the thought processes, and this may result in having to rethink the sequence of actions to be continued." 
...

But, bring system response time down to 0.3 seconds and the number of transactions the programmer can execute in an hour jumps to 371, an increase of 106 percent. Put another way, a reduction of 2.7 seconds in system response saves 10.3 seconds of the user's time (Figure 3). This seemingly insignificant time saving is the springboard for sizable increases in productivity.
...

Cost/Benefit Illustration

To bring the potential benefits of rapid system response into perspective, consider an illustration. Based on the data Thadhani published (Figure 2), the average user can complete 180 transactions per hour at three second response time (Figure 9). For simplicity, then, assume a task that involves 180 transactions and takes an hour to complete. Any one user can complete eight such tasks in a day. Further, assume the burdened value of the user's time is $35 per hour. These numbers will be held constant for the purposes of this illustration.
 

*  Based on Thadani's data (Figure 3) 

Figure 9. Computation of the Time a User Saves in a Day as System Response Time Improved from 3.0 Seconds to 0.3 Seconds

System Response Time (Seconds)	Transactions per Hour*	Task Time (Minutes)	Time Saved per Task (Minutes)	Time Saved per Day (Minutes)
3.0	180	60.0	-	-
2.0	208	51.9	8.1	64.8
1.0	252	42.9	17.1	136.8
0.6	279	37.7	22.3	178.4
0.3	371	29.1	30.9	247.2

As system response time improves, the time required to complete a task drops from the original 60 minutes to only 29.1 minutes. Since the average user completes eight such tasks in a day, the maximum amount of time that can be saved is 247.2 minutes, or 4.1 hours. In a month of 21 work days, the value of these saved minutes is $3,028. 

The number of simultaneous users an online system supports varies from organization to organization as does the amount of improvement in response time which is needed. But, in all cases in this illustration (Figure 10), the financial incentive for bringing system response time from three seconds into the subsecond range is substantial, ranging from $150,000 per month when only 50 people use a system at any one time to $908,000 when 300 people use the system simultaneously.

Source: http://www.vm.ibm.com/devpages/jelliott/evrrt.html

Architecture sketching

Three types of Architecture:

Application Architecture: Th internal structure of an application (classes, components, design patters)
System Architecture: High-level structure of a software components/services)
Enterprise Architecture: Structure and strategy across people, process and technology

Simon Brown considers software architecture as both Application and System Architecture

Architecture represents the significant decisions, where significance is measured by cost of change.

The C4 model (static structure):
System Context: The system plus users and system dependencies

Containers: the overall shape of the architecture and technology choices

Components: Logical components and their interactions within a container

Classes: component or pattern implementation details

A common set of abstractions is more important than a common notation

Tips:

Keep audience in mind when developing diagrams: non-technical, semi-technical, technical


Checklist for an effective sketch (diagram):

1. I can see the solution from multiple levels of abstraction
2. I understand teh big picture (context)
3. I understand the logical containers
4. I understand the major cmponents used to satisfy the important user stories/features
5. I understand the notation, colour coding, etc used on the diagrams
6. I can see the traceability between diagrams
7. I understand the major technology decisions
8. I understand the implementations strategy (frameworks, libaries, API's, etc)

"Sketches are Maps"

Just enough up front design to create firm foundations for the software product and its delivery:

From: https://skillsmatter.com/skillscasts/5109-simple-sketches-for-diagramming-your-software-architecture

Recruiting goes High School

http://www.bloomberg.com/news/2014-07-08/silicon-valley-s-talent-grab-spawns-high-school-interns.html