Gregory Maciag

Insight Driven Organizations

I'm interested to see Deloitte's John Lucker using the phrase IDO, or insight driven organization, when talking about the future for analytics. He makes a useful distinction between the data driven organization, which everyone has been busy trying to build, and the insight driven organization – which is what they really need.

He identifies a set of components that need to be in place before the IDO is realized. The headline is about being a joined-up organization. He says “IDOs have a solution that connects successes across the enterprise” and “the insight-driven culture values a single version of the truth”.   Lucker's model is an important perspective for decision makers and business leaders. It will help them analyze their investments and processes with greater clarity. Many technology disappointments could be avoided if managers asked themselves whether a project is serving data centricity or insight centricity.

Yes, data is the stuff we're dealing with. But insight is the reason we're dealing with it.    Data Informed
   

Agile Adapters

There were many insights at a recent Innovation Forum held at ACORD's London offices. One that I want to pick out is how the insurance industry often benefits from R&D, piloting, and proof of concept projects carried out by other industries – notably finance. Insurance organizations can succeed as “fast followers”, exploiting the investments and learning of those with the stomach to be at the bleeding edge.

I want to say this doesn't make insurance any less creative. Insurers didn't invent paper, ink, or telephones, and I don't think they should feel bad about that. NASA didn't invent seats, but they still put them in their vehicles.

Insurers are investing in blockchain technology, using a by-product of digital currency developments to create distributed ledgers with the potential to change the way our business gets done. This is a different use of the technology than in currencies. It's closer to the utilization of blockchain for complex financial instruments, but it's not a duplication. Insurance players still need to invent a pile of new stuff to make blockchain useful in the industry – and to make it pay.

Reuse is innovation. Taking something from one context, recognizing its potential application in another field, and making that translation work – these are absolutely elements of innovation. Every organization and every industry benefits from the accumulated invention, labor, and experience of the entire human race, through all its generations. There are no clean sheets, no green fields.

I want to reserve the term “fast follower” for people who take an existing idea and do it better than the pioneers. How about we call the people who spot the potential for shifting an idea into a new realm the “agile adapters”?

Data Driven Government

I didn't know this – and I suspect I'm not the only one:

A somewhat surprising bi-partisan effort is Speaker Ryan and Senator Murray (D-WA) having submitted bills in each chamber of Congress to develop a Commission on Evidence-Based Policymaking. (It's passed in the House.) This commission will be charged to “determine the optimal arrangement for which administrative data on Federal programs and tax expenditures and related data series may be integrated and made available to facilitate program evaluation, policy-relevant research, and cost-benefit analyses”.

It will make recommendations on how data infrastructure and statistical protocols should be modified” to achieve this. This Commission will be a big deal and, unless you are among the most skeptical or a conspiracy theorist, this commission will turbocharge the awareness of the power of data at all levels of government.'

This information comes from the first in a series of blog posts by Robert George about the public sector's use of data to improve well-being. If this law passes, government will become a data-driven enterprise by default. That will be a great advance.   govloop

Where is the Pain Point?

In a short blog post, Randy Connelly of Utopia asks: “How do you convey the importance of data standards and governance to distant managers?” His answer starts: “It’s going back to identifying the real business challenge or pain point and then driving out what the value is to getting the data corrected.”

There's a lot of sense in this – it's always important to get the conversation back to the business. Despite the continuing digitalization of business, managers' default idea about data is usually that it's just a technical concern.

There are a couple of things to chew on here as well. How long are organizations going to tolerate “distant managers”? I guess we mean managers who are several steps away in a hierarchy, rather than managers who happen to be located at a remote site. Or maybe we mean managers who are distant in the sense of aloof from what they regard as technical matters.

Either way, there's a problem here. If you need the go-ahead of managers who know or care little about the importance of your data-centric project, these people are blockers. You should maybe go around them. If it's your job to educate and get them on board, then I feel for you. Maybe work both ends by running an educational campaign while getting on with your project.

As Connelly says, if you really need people to care then you've got to get to the pain. Unfortunately, there's rarely a single, obvious, costed pain point you can wave in front of an unengaged manager. The business case for standards is usually multi-faceted. The most salient aspects of such a business case may not necessarily play to the interests of your target blocker. Also, I have every sympathy with people who say asking for a business case for standards is like demanding an argument for hygiene, or for having locks on the doors of the building, or for requiring staff to wear clothing to work.

And I think more and more people are getting the systemic point of data standards, which is that the pain isn't at one, or any distinct number of, discrete points. The pain is diffuse. The pain is shared.  Failure to use data standards affects the whole organization – and the ecosystem of which it is a part. Without data standards, inefficiencies multiply, potential connections remain unmade, and constraints to innovation continue to loom over every creative impulse. It's a world of pain.   Utopia

Guidance for Standards Implementation

It's one thing to build a data standard. Getting it implemented is a whole new ballgame.

The Government Accountability Office (GAO) has taken a long look at the 57-element data standard prepared by OMB and Treasury to enable the DATA Act. GAO identified 13 best practices for data standards and found all the data elements in the set met at least 9 of the criteria, with 12 meeting all the criteria. But they found some real problems in there.

For example, there's an entity called Primary Place of Performance. You need to be able to say where money is being spent. But the definition includes the phrase “where the predominant performance of the award will be accomplished”. What if the project is a road? You could interpret the Primary Place of Performance as the town hall or state capitol, depending on whether the road is considered local or statewide. Or you might think it's the contractor's worksite, or the contractor's business address. Or you might have a geolocated mileage marker close to the project and use that.

Developers can interpret ambiguous definitions like this in ways that make perfect sense for their systems and their stakeholders' needs – but which undermine the ability to share data across agencies. So data standards bodies need to issue guidance about how the standards are to be interpreted. They also need to invite feedback and experience reports so new use cases can be tested against the standard.

It's hard enough working against organizational inertia, stressed budgets, and not-invented-here syndrome. Get the guidance out there if you want to get implementation. And accept that every standard will need to adapt to changing needs and growing awareness.    GAO

Buried or Embeded

FedScoop lists five tech projects “buried” in the President's current budget proposal. Whitney Blair Wyckoff's piece includes anti-encryption research – a topic which is getting a lot of attention in the media because of the FBI's requests to Apple about unlocking an iPhone – using jobs data, self-driving cars, body-worn cameras, and precision medicine.

So look – “buried” is the word used by the headline writer. Wyckoff herself uses “tucked away” in the story. Since I'm commenting here for wider purposes than the news cycle, I want to abstract away from both images and develop a larger point about the role of technology in government initiatives. And I'd opt for “embedded”.

The tech issues highlighted in the budget proposal call attention to the central role of data in our civilization. Data is now crucial to the way we live. It's not going back in the box. Data communications are embedded in society.

Government will increasingly need (or want) to make policy around the creation, communication, and consumption of data. Legislators must take this on board. They need to scrutinize data-related proposals with care. They may need the advice and guidance of specialists, but they must not abrogate their responsibility.   FedScoop

Data Standards for Water Flow

Better flood prediction for the U.S. is arriving thanks largely to new data standards. Modeling previously done by 13 regions using their own approaches is now being integrated into a single, comprehensive model of the continent. Now the relevant agencies can estimate the flow of water through 2.7 million stream segments, each about 2 miles long, across the entire continental U.S. with forecasts updated every hour of every day.

This is another good example of how data standards can transform the way we manage our resources and safeguard our communities. The new data stream will also be useful to the insurance industry.   Data standards like these represent big, doable wins for government. They also act as stimulants and exemplars for people in other complex domains who have yet to remove their own barriers to data flow.    OGC

Data Lakes

Sean Martin pens a great piece on data lakes, explaining what they are, their advantages and disadvantages, and how he sees the field developing over the next year. It's useful orientation for anyone who is negotiating the growth of big data in their organization or responding to increased demands for fast access to raw data.

Martin is clear that too many data lakes are being populated with data that's effectively unusable because it lacks context. Some organizations have traded the slow but structuring bottleneck of the data architecture team and the DBAs for rapid availability of inconsistent, untrusted, and even unintelligible, data. It's cheaper to hold all this stuff than it was under the old data warehouse regime. But if you can't exploit it, what have you gained?

The answer to the problem is semantic modeling, which adds context and meaning back into large data contexts without falling back to older technologies. Although Martin does not cover semantic modeling and ontologies in depth in this piece, I don't think he means to imply reinjecting these structural forces is trivial. You still need smart people to do this. It's a matter of using established skills in a new technical environment.

If you wanted to go deep on this issue, you could say it's an example of the age-old struggle between order and chaos – or maybe, more accurately, between the privileging of foresight over insight. We used to value centralized organizations which planned ahead and imposed order. Now business moves faster than ever before, so we value organizations that are distributed and empowered to make their own futures – using their creativity.

The reality is, you've got to have both. It's hard, because they're forces that naturally want to oppose each other. Harnessing and directing both impulses in the service of the organization's goals is right at the heart of contemporary leadership.

Analytics

Pressure for Standards

Some of today's best advocacy for data standards comes from the real estate sector. This is a great headline from The Real Daily: “Brokers and agents are losing time, money by sitting back and waiting on data standards to change”. Elsewhere in the article Matt Cohen says: “Data is a valuable asset, and one that brokers and agents are letting fall to the ground to spoil... [B]rokers and agents aren’t getting the value out of their data because that data sits in individual product silos when available at all, inaccessible as data to others. Why? Because brokers and agents haven’t done the work – or applied the pressure on software vendors to do the work – to create and adopt data standards.”

Cohen goes on to cite specific examples where the absence of standards is failing the industry. The new RESO standards need more support from agents and brokers.  I know real estate is a different business than insurance, but at a high level there are similarities. Both industries have brokers and agents. In both sectors, you find a highly dispersed community of smaller businesses interacting with large companies. Cost containment and efficiency are absolute must-haves. And the internet has disrupted both industries in complex ways that are both positive and negative.

Getting standards implemented takes work. The ACORD community has invested many, many person-years in achieving the high rates of adoption we see today. Players in the real estate world can take inspiration from ACORD's success. In insurance, brokers, agents, carriers, and vendors have learned to collaborate on standards – so they can collaborate in growing the business for everyone.

The Real Daily