Interesting news article about "big data" at the World Economic Forum in Davos, Switzerland. Big data has become quite the buzz word, and now "smart data" is starting to eclipse it (at least in some circles).
Anyhow,an interesting tidbit about the need for consistent privacy policies/laws:
Earlier this week in Munich, Viviane Reding, the European justice commissioner, repeatedly talked about data in respect to privacy. Ms. Reding said there were 27 laws that apply to data in Europe, most of which date back more than a decade and don’t properly protect consumers today.
Ms. Reding outlined new regulations that were presented in Brussels on Wednesday and were designed to implement one sweeping data protection regulation that would apply to all of Europe.
No different here in the States. Each state has the right to have their own privacy laws. However, once you try to start sharing data between those states, it becomes a nightmare determining who can see what.
So is anyone in the U.S. trying to accomplish a similar goal of a "one sweeping data protection regulation"? Seems like it would be a stretch (especially to create one), but some consolidation/agreement is definitely needed.
There are no shortage of industry standards that allow for products and services to interoperate. In fact, there are so many standards that a team implementing an information sharing system can quickly become overwhelmed in determining which standard is best. Then once they pick a standard, they must determine HOW that standard will be used and ensure that the standard is used in the same manner as the other systems they want to interoperate with.
In my experience integrating enterprise level systems, the great equalizer for HOW a standard will be implemented is the Internet. I could A) read the standard specs over three cups of coffee, OR B) I can rely on the lessons learned from other implementers who have been in the same boat I have been in. To a busy implementer, which do you think they will pick?
But of course the Internet is the wild wild west, and the information gathered doesn't guarantee interoperability either. Just because I implemented a NIEM IEPD for arrest warrants recommended on an Internet forum doesn't meant that I will be able to pass that arrest data to another agency.
A first step is providing a central repository of standards, profiles, and best practices that implementers can use to collaborate on the solutions they are currently implementing and they have implemented in the past. However, it is KEY that this solution be available for more than just one segment of business or government agency. Information exchange does not just happen INTRAangency in the Intelligence Community or at DHS. It happens INTERagency between these agencies. Therefore, if each agency maintains their own repository, then we may remain in the same stovepipe problem we are now. Agency A implements Profile P of Standard X, and Agency B implements Profile Q of Standard X. Iterate this problem for 8 more agencies, and information systems are in the same boat of implementing different connectors to each system.
In addition, for a respository to work, implementers and agencies MUST contribute back to the repsository. It must be a two way conversation for it to be useful.
A repository is not the only step (governance anyone?), but it is an important part of breaking down the iron curtains between information systems and allowing for information to more freely flow to the users who need it.
Excited to be moderating a panel next Tuesday November 8th at the FOSE Enterprise Management Conference & Exposition entitled "EA and Information Sharing - From Intelligence to Assets". I will be joined by Emile Beshai from DHS, Glenn Cruickshank from Deloitte Consulting, and Sue Jaxel from the Office of the Director of National Intelligence.
The high level description of the session:
Information sharing is at the heart of every agency’s mission – whether it’s in the areas of healthcare, citizen services, or national security. This panel will include two case-studies detailing how agencies within the intelligence and national security communities leveraged enterprise architecture to achieve real-time information sharing not only within the federal government, but across all internal and external domains. The first case-study will delve into the Department of Homeland Security’s SBU Portal Consolidation, which strengthened collaboration and information exchange with key partners in the federal, state, local, tribal, territorial, international, and private sectors. The second case-study will showcase the IC Enterprise Registry and Repository, an intelligence community enterprise capability that provides IT publishing, IT lifecycle management, and human discovery and retrieval to support the sharing of community assets.
Looking forward to a thoughtful and engaging discussion!
In my role in supporting the U.S. Government in the evolution of an Information Sharing Environment, I have had the opportunity to become more exposed to the machine that is Enterprise Architecture Frameworks. Not the frameworks themselves necessarily, but the machine and engine around them. And more and more I have to wonder, what is the true value of the frameworks and the associated artifacts it produces?
To give context, it is probably useful to understand my background. I have "grown up" during my professional career architecting (little "a"), designing, and implementing information systems. This has included upgrades of email infrastructures (I still hate you Groupwise) to enterprise wide white pages/attribute services. However, when I say that I have architected these systems, I mean that I have worked with some VERY good people to actually plan the entire system from software to hardware to networks to user experiences. However, during that time, the maintenance and creation of artifacts related to Enterprise Architecture (big "A") Frameworks was NEVER a priority. Typically there was only enough time and money to actually design and implement the system (DO SOMETHING) rather than the creation of artifacts (PROCESS).
Now does that mean I was simply blind to the usefulness of those frameworks? Perhaps. But since then I have had more exposure to life in the SETA world and with agency CIOs where these same Enterprise Architectures get a lot more play. A lot of money gets spent on maintaining the associated artifacts b/c they are required for certain programs (typically over a certain dollar amount). There are relatively few people who are "certified" in Enterprise Architecture, and therefore those contractors are pricey. Anyhow, I don't have a good answer. But I do know that creating documents simply for the sake of creating them is not best practice. I think there seems to be a lot more value in concentrating on information architectures and knowing more about our data so we can effectively share it with our business partners.
I grew up as a techie and first got hooked using an old Texas Instruments programming in Basic ("Hello World" app is my fav) and then learned the fun of "integration" making my PCjr actually run the old Sierra games I wanted to play. After a lot of fun at college, I found myself entrenched in the government technology world leading projects and integrating systems for the past 11+ years. I have extensive experience in technical project management, Public Key Infrastructure (PKI), Collaboration Technologies, Information Sharing, and Secure Systems Integration.