Life for Yours Truly isn't all about slogging through investment conferences. I throw in the occasional trade show in the hope I'll learn something new and meet attractive women. DataWeek 2013 and API World fit that bill for me last week.
I didn't have time for the entire conference because it's really a code developer's show and I'm Mr. Finance. I could only attend a select few sessions because I was too cheap to pay for anything but an Expo pass. I noticed that many of the paid seminars had no gatekeeper at the door, so anyone could have walked into a paid session. I hope the conference organizers weren't losing money from freeloader coders wandering around Fort Mason Center.
My first free session was an overview of how SQL queries and Java apps running in a Hadoop ecosystem feed Big Data streams into ERP systems. I don't know code but I know a business problem when I see it. Hadoop apps interact with both transactions and analytics, completing the CRM / Big Data / ERP integration that so many IT pros say they want. This leads me to the belief that knowledge management pros must understand Hadoop. There is no other way for them to ensure that the enterprise's business intelligence effort and predictive analytics are available to the C-suite. That's how tools channel data up the decision chain to support strategy.
Hadoop reminds me of Salesforce's approach to offering cloud ERP solutions, except Hadoop solutions are built on demand. Both types of solutions can be scaled down for small enterprises that can't afford big iron computing. My first take-away from DataWeek is that startups doing manual, customized apps or analytic solutions for B2B customers will fail. Data ecosystems like Hadoop are growing too large for anything but machine learning that automates analytics. Only top-layer KM, heuristics for predictive analytics, and corporate strategy should be subject to manual manipulation. The KM focus should be on structural design, with decision criteria that trigger manual intervention.
I patrolled the Expo floor prior to the heavily advertised beer tasting. I was pleasantly surprised to see several attractive women staffing the booths. Disqus gal, you were the best, and thank you for filling out those jeans so well. The women attending were also cute. It's good to see more women pursuing tech careers. They should pursue me too but I understand if they're focused.
I attended a talk from IBM Analytics about the most important factors in data visualization. I started visualizing what the hot blonde woman in the back row would look like at my place but then I remembered I have a blogging job to do. It turns out there are four pillars governing how analysts should publish visual representations of data: purpose (why), content (what), structure (how), formatting (everything else). Knowing the purpose for assembling a presentation lays the foundation for an iterative design checklist.
Purpose for me means knowing what actions I want to prompt in my audience, such as uncontrollable rage at my opinions. Content covers the data and relationships that matter to me and my audience, like IQ comparisons that demonstrate my intellectual superiority to most of humanity. The IBM guy showed a simple bar chart of how Apple's iPhone revenue was greater than all of Microsoft's revenue, so even two data points can show something powerful. Structure governs the meaning of axes and layouts that reveal relationships, like my relationships with numerous female admirers. That would take too much time to graph so I'll just relate IBM's best practices here. Using 3D graphs distorts data and you can't see intersections with axes when the front 3D thingy obscures what's in back. The human brain is better at comparing angles than circles, so charts with long bars on a common baseline are easier to perceive. Horizontal bars showing binary (either/or) breaks in continuous data frees the vertical axis to sort categories by ranking. Finally, formatting data to show what's important accounts for how users will consume the data. Callouts in geodata reveal something that matters. Using color to indicate quantity forces readers to keep glancing at the legend, which is bad. Color also has cultural context; red-/white/blue means something in the US and France. "Redundant encoding" puts the same data into different visual channels, driving the point into viewers' brains in case the format doesn't translate perfectly. Labeling highlights things, so either make it possible to label outliers (if they reveal something significant) or use them to orient viewers when you label axes. IBM's white paper on successful visualization sums up all of this stuff and so does the author's handy diagram. This knowledge makes me think about the graphs I've seen in oil and gas investment presentations. Formatting the wells' decline rates means everything if scale de-emphasizes the steepness of the decline curve. Readers fooled by logarithmic scales may think declines are gradual in shale wells. I'll look for scale the next time some shale energy promoter shows me his projections.
The only other seminar I had time to check out was on how security architectures can be unified across mobile, cloud, the Web, and APIs. Typical APIs aren't exposed to the general public and API security is enterprise-specific. The security landscape is so broad that it open up APIs as a potential portal for intrusion. Enterprises that support tiered access from public users and internal users (like financial service institutions) must support multiple credentials. I think authentication protocols will have to be built into APIs prior to launch, just like analytics. APIs must do much more than run apps. They collect use case data, feed analytics, provide a security barrier, and define the user experience. Integrating all of these things will require more effort from programmers than ever. I'm glad I'm not a programmer.
I took the above photo at the Rackspace / Codame / Geekdom SF Dataweek afterparty. The photo captures a computer-generated video with parts of the image melting and morphing. I'm the dark suit and white shirt in the middle foreground holding my camera. One aging hippie near Fort Mason maligned me as a "suit" while I walked to the conference center that day and I took it as a compliment. I represent money, knowledge, and style, thank you very much, and that's why hot women gravitate to me and not aging hippies. The Rackspace party reminded me of the articles I read in the late '90s about dot-com startups living wild on VC money in San Francisco's SOMA district. This afterparty was my chance to relive what I missed by not being around for that scene. It looked more like a rave, with a contingent of "club kids" in high-soled shoes and glittery leggings. I noted several of the hot Expo booth babes letting their hair down but I was too busy admiring the tech on display to get their hotel room numbers. Twentysomethings owned the future, in the '90s and today. I'm not in my twenties anymore but I own the future now.
I didn't have time for the entire conference because it's really a code developer's show and I'm Mr. Finance. I could only attend a select few sessions because I was too cheap to pay for anything but an Expo pass. I noticed that many of the paid seminars had no gatekeeper at the door, so anyone could have walked into a paid session. I hope the conference organizers weren't losing money from freeloader coders wandering around Fort Mason Center.
My first free session was an overview of how SQL queries and Java apps running in a Hadoop ecosystem feed Big Data streams into ERP systems. I don't know code but I know a business problem when I see it. Hadoop apps interact with both transactions and analytics, completing the CRM / Big Data / ERP integration that so many IT pros say they want. This leads me to the belief that knowledge management pros must understand Hadoop. There is no other way for them to ensure that the enterprise's business intelligence effort and predictive analytics are available to the C-suite. That's how tools channel data up the decision chain to support strategy.
Hadoop reminds me of Salesforce's approach to offering cloud ERP solutions, except Hadoop solutions are built on demand. Both types of solutions can be scaled down for small enterprises that can't afford big iron computing. My first take-away from DataWeek is that startups doing manual, customized apps or analytic solutions for B2B customers will fail. Data ecosystems like Hadoop are growing too large for anything but machine learning that automates analytics. Only top-layer KM, heuristics for predictive analytics, and corporate strategy should be subject to manual manipulation. The KM focus should be on structural design, with decision criteria that trigger manual intervention.
I patrolled the Expo floor prior to the heavily advertised beer tasting. I was pleasantly surprised to see several attractive women staffing the booths. Disqus gal, you were the best, and thank you for filling out those jeans so well. The women attending were also cute. It's good to see more women pursuing tech careers. They should pursue me too but I understand if they're focused.
I attended a talk from IBM Analytics about the most important factors in data visualization. I started visualizing what the hot blonde woman in the back row would look like at my place but then I remembered I have a blogging job to do. It turns out there are four pillars governing how analysts should publish visual representations of data: purpose (why), content (what), structure (how), formatting (everything else). Knowing the purpose for assembling a presentation lays the foundation for an iterative design checklist.
Purpose for me means knowing what actions I want to prompt in my audience, such as uncontrollable rage at my opinions. Content covers the data and relationships that matter to me and my audience, like IQ comparisons that demonstrate my intellectual superiority to most of humanity. The IBM guy showed a simple bar chart of how Apple's iPhone revenue was greater than all of Microsoft's revenue, so even two data points can show something powerful. Structure governs the meaning of axes and layouts that reveal relationships, like my relationships with numerous female admirers. That would take too much time to graph so I'll just relate IBM's best practices here. Using 3D graphs distorts data and you can't see intersections with axes when the front 3D thingy obscures what's in back. The human brain is better at comparing angles than circles, so charts with long bars on a common baseline are easier to perceive. Horizontal bars showing binary (either/or) breaks in continuous data frees the vertical axis to sort categories by ranking. Finally, formatting data to show what's important accounts for how users will consume the data. Callouts in geodata reveal something that matters. Using color to indicate quantity forces readers to keep glancing at the legend, which is bad. Color also has cultural context; red-/white/blue means something in the US and France. "Redundant encoding" puts the same data into different visual channels, driving the point into viewers' brains in case the format doesn't translate perfectly. Labeling highlights things, so either make it possible to label outliers (if they reveal something significant) or use them to orient viewers when you label axes. IBM's white paper on successful visualization sums up all of this stuff and so does the author's handy diagram. This knowledge makes me think about the graphs I've seen in oil and gas investment presentations. Formatting the wells' decline rates means everything if scale de-emphasizes the steepness of the decline curve. Readers fooled by logarithmic scales may think declines are gradual in shale wells. I'll look for scale the next time some shale energy promoter shows me his projections.
The only other seminar I had time to check out was on how security architectures can be unified across mobile, cloud, the Web, and APIs. Typical APIs aren't exposed to the general public and API security is enterprise-specific. The security landscape is so broad that it open up APIs as a potential portal for intrusion. Enterprises that support tiered access from public users and internal users (like financial service institutions) must support multiple credentials. I think authentication protocols will have to be built into APIs prior to launch, just like analytics. APIs must do much more than run apps. They collect use case data, feed analytics, provide a security barrier, and define the user experience. Integrating all of these things will require more effort from programmers than ever. I'm glad I'm not a programmer.
I took the above photo at the Rackspace / Codame / Geekdom SF Dataweek afterparty. The photo captures a computer-generated video with parts of the image melting and morphing. I'm the dark suit and white shirt in the middle foreground holding my camera. One aging hippie near Fort Mason maligned me as a "suit" while I walked to the conference center that day and I took it as a compliment. I represent money, knowledge, and style, thank you very much, and that's why hot women gravitate to me and not aging hippies. The Rackspace party reminded me of the articles I read in the late '90s about dot-com startups living wild on VC money in San Francisco's SOMA district. This afterparty was my chance to relive what I missed by not being around for that scene. It looked more like a rave, with a contingent of "club kids" in high-soled shoes and glittery leggings. I noted several of the hot Expo booth babes letting their hair down but I was too busy admiring the tech on display to get their hotel room numbers. Twentysomethings owned the future, in the '90s and today. I'm not in my twenties anymore but I own the future now.
