NIST Big Data WG Use Case Survey – Version 2
The NIST Big Data Public Working Group survey can be accessed from this Krypton Brothers page, or directly from the Google Docs page. To begin, start on the embedded form below. Scroll down as needed.
NIST Big Data WG Use Case Survey
This is the second version of a use case survey conducted by the NIST Big Data Working Group. If you are working on, or planning a Big Data project, we would like to learn more about your use case.
The survey can take as long as 90 minutes to complete, depending on the extend of the deployment, complexity of applications, infrastructure and security.
[iframe src=”https://docs.google.com/forms/d/1Qp4UvGK3a2kzmkQ6CU2Q-m9iRezDHoelNeXO4m2UcnE/viewform?embedded=true” id=”nistusecase2″ name=”NISTUseCase2″ width=”760″ height=”500″ frameborder=”0″ scrolling=”no” marginheight=”0″ marginwidth=”0″]
We’re Remodeling . . .So Please Visit Our Old Site
The Brothers are working on a new site that will incorporate eLearning resources.
In the meantime, you can visit our old site in all its magnificence.
Underused: Social Science Evidence for Public and Private Policy
The term “policy” has a semi-technical meaning for systems administrators and cybersecurity analysts. Because this meaning is relatively standardized (e.g., “group policy” for Windows networks), the underlying orchestration of business rules is easily grasped. For other organizational — and political — processes, it is less obvious. For instance, violations of group policy can be automatically audited. In a more positive vein, other behaviors, such as frequency of use for information or apps, can be measured at the group level. Two groups, one used as a control group, can test initiatives (“interventions”), such as the introduction of a new technology (e.g., Facebook at work) or new policy (e.g., outsourcing of a process previously performed in-house).
Collaboration: Evolution, not Revolution
Collaboration was a goal of networked systems going back decades. For people of a certain age, a memory will be triggered by the mention of Novell Groupware (“Groupwise”). Yet, decades after this promise, increased availability of internet access and mobile computing, collaboration remains very much a manual process for many. Attempts to automate collaboration face many hurdles. The question must be asked, then: Are the limitations to e-collaboration due to technological limitations, or to something more intrinsically sociological or psychological?
Knowledge Gigs Sans Knowledge Support
They used to be called white collar jobs. At some point the concept shifted to “knowledge worker,” though that idea seems to have lost some of its luster. Regardless, apart from maximizing earning potential, the goal of a college education — or that of other time-intensive learning endeavors — is to land a position in a knowledge worker profession. In principle, such jobs are less likely to be automated out of existence, or to drift offshore to lower cost labor markets. But who is rating those prospective job opportunities on their true knowledge orientation? For a time, we did.
Capacity-based Triggers As De Facto Enterprise Rules
Here’s a de facto enterprise rule. It may be an enterprise’s intentional rule, but more often than not, it’s a de facto one.
RULE Customer-perceived rule: If you can’t reach the sales office (Carbonite) you can’t purchase the service.
RULE Enterprise rule: If inbound sales exceeds n calls / hour, push all calls to voice mail.
From an enterprise’s perspective — the seller in this instance — the sales office’s inaccessibility may be unintentionally salutary. It limits customer volume at a time when the enterprise’s infrastructure and staff may be unable to handle the volume. Of course, sales are lost, and customers must question why the sales staff is unavailable during peak daytime periods, but the enterprise rule could serve its purpose, at least as a stopgap measure during an unusual circumstance.
Later facts that came to light about Carbonite (a hosted provider of backup services) suggest that this rule may not be de facto in their case, but nevertheless a capacity-based trigger such as inbound phone sales inquiry volume remains an illustrative use case.
Slider demo pending
It’s Not Code So It Must Be Easy
Oh, that part of building software that involves talking to ‘the customer’ and making requirements spreadsheets — that’s not real programming. Show me you can use REST.
So goes the thinking of many developers, some of whom are anxious to skip the perceived tedium of business process exercises and get on to the “real work.” For many, software development’s connection to process analytics resembles the electrical conductivity of paper. One reason developers nurture this belief is that much of their income is derived from revising their own work. Imagine that we paid civil engineers to fix their own errors in bridge design. So give it a REST and start improving requirements traceability.