Public Sector Open Data via Information Sharing and Enterprise Architecture

Recent government policies and public demand for open data is rapidly exposing both opportunities and challenges within government information-sharing environments, behind the firewall – in turn a fantastic opportunity and challenge for the Enterprise Architects and Data Management organizations.

Public Sector Open Data via Information Sharing and Enterprise Architecture

The title of this article is quite a mouthful, and three very complex and broadly-scoped disciplines mashed together. But that’s what’s happening all over, isn’t it, driven by consumer demand on their iPhones – mashing and manipulating information that’s managed to leak through the risk-adverse, highly-regulated mantle of the government’s secure data cocoon, and instantly sharing it for further rendering, visualization or actual, productive use. Mostly a “pull” style information flow, at best constrained or abstracted by public sector EA methods and models – at worst, simply denied.

This demand for open data, however, is rapidly exposing both opportunities and challenges within government information-sharing environments, behind the firewall – in turn a fantastic opportunity and challenge for the Enterprise Architects and Data Management organizations.

The recent “Open Data Policy” compels US Federal agencies to make as much non-sensitive, government-generated data as possible available to the public, via open standards in data structures (for humans and machine-readable), APIs (application programming interfaces) and browser-accessible functions. The public (including commercial entities) in turn can use this data to create new information packages and applications for all kinds of interesting and sometimes critical uses – from monitoring the health of public parks to predicting the arrival of city buses, or failure of city lights.

But there isn’t an “easy” button. And, given the highly-regulated and tremendously complex nature of integrated, older government systems and their maintenance contracts – significant internal change is very difficult, to meet what amounts to a “suggested” and unfunded (but with long-term ROI) mandate, without much in the way of clear and measurable value objectives.

That doesn’t mean there aren’t whole bunches of citizens and government employees ready, willing and enthusiastic about sharing information and ideas that clearly deliver tangible, touchable public benefit. Witness the recent “Open Data Day DC“, a yearly hackathon in the District of Columbia for collaborating on using open data to solve local DC issues, world poverty, and other open government challenges. Simply sharing information in ways that weren’t part of the original systems integration requirements or objectives has become a very popular – and in fact expected behavior – of the more progressive and (by necessity) collaborative agencies – such as the Department of Homeland Security (DHS).  

The Information Sharing Environment is the nation’s most prominent and perhaps active federal information sharing model – though its mission really generates “open data” products for a closed community (vs. the anonymous public) – i.e. those that deal with sensitive national security challenges. For information sharing purposes, however, it’s a very successful and well-documented, replicable model for any context that includes multiple government entities and stakeholders (whether one agency or department, or a whole city or state). A pragmatic Information Sharing Environment – with enthusiastic, knowledgeable and authoritative champions – is also the first, most important leg of the stool that supports successful Open Data initiatives.

The second leg is Enterprise Architecture – thinking of “open data” as the “demand” side of the equation, and “information sharing” as the conduit and source of “authorities” (i.e. policies, rules, governance, roles; internal and external) – EA can represent the “supply”. “Represent” the supply, not “be” the supply; the “supply” are the actual agency assets, including data, budget, contracts, personnel, etc. EA can inform regarding what data is available where and when, with what constraints, in what format or representations, via which IT interfaces, and via which business or technology resources. What can or needs to be changed, or what will be impacted, for the supply to meet the demand? Perhaps reusable IT exists that can be fully leveraged to meet the requirements, perhaps existing Oracle SOA, BPM and WebCenter assets?

The third leg of course is the inventory of data assets available – data assets include not only the raw data, but the metadata and registries, data access functions and APIs, data models and schemas, and the information technologies and systems that produce, manipulate, manage, protect and store the data. Plus really neat, useful commercial and open source open data tools to help. Whether they exist already, or need to be created.

So it conceptually works as follows, very abstractly-mirroring the well-known “People, Process, Technology” business model;

  1. People – An information-sharing environment and culture develops, enabling productive dialogue and guidance about proactively or reactively creating “open data” from enterprise assets to share with the public;
  2. Process – An Enterprise Architecture method and framework is leveraged, to define and scope the “art of the possible” in leveraging enterprise data assets, in terms that enable compliant program and engineering planning; and
  3. Information Technology – Useful, standards-based data products are cataloged and exposed to the public (better with some initial protoyping), meeting requirements and expectations, appropriately constrained by law, policy, regulations and investment controls. 

 Significant open data, and open government initiatives can’t succeed and persist without all three perspectives, all three domains of organizational expertise.

#INFOARCH – INFORMATION OWNERSHIP

While I am preparing to publish my next article on Information Management and taking the opportunity of a email discussion with Jean Evelette – the author of the very interesting website MARS – Metadata And Repository System – I realized that a clarification regarding information ownership was needed. Here is the famous question: Who is owning the information? I […]

The Chief Marketing Technology Officer – CMTO – and the EA

Admittedly, it’s a bit of a leap – addressing the converging roles of the CIO and CMO (Chief Marketing Officer) with an Enterprise Architecture perspective, particularly when a CMO’s “Enterprise” ranges far and wide of the actual organization they serve. The Internet does extend now into outer space a bit, after all.

The classic scope of the Enterprise is that which is contained within both an operating and investment budget (OPEX and CAPEX) – the assets and resources that are produced, consumed and used under a common business (or mission) strategy.  Perhaps a company or agency, a department or line-of-business, or some other facility or organization segment. Enterprise Architects (EAs) most often influence these sorts of enterprise contexts.

A CMO certainly runs a business segment, investing in people, assets and consumable resources – most of which can be touched, inventoried or governed in some way to align with the segment’s business strategy (make revenue, deliver goods or services, be a public steward, contain costs, mitigate risk). A CMO’s “Enterprise”, particularly in this digital age, is also that of the online, networked audience. Social media profiles, data feed providers, branded communications channels, publisher networks and web app platforms – these also are part of the CMO’s “Enterprise”, and require some degree of monitoring, governance, investment control, integrated standardization.  Digital marketing campaign assets and advertisements aren’t usually just thrown to the wilds of the Interwebs (unless they are) – they’re carefully planned, tested, optimized, controlled, monitored and analyzed – both their original forms and any derivations.

Note that, for purposes of this blog, the “CMO” is readily compared to the “Government Services PR Lead” or “Constituent Relationship Communications Lead” – or basically any other leadership position in charge of outreach, communications and basically marketing of Public Sector capabilities or services.

“Traditional” EA doesn’t seem to address the Internet of things, stuff and services as something to be modeled, or deemed compliant, or aligned with standard reference frameworks. This isn’t unlike trying to apply one EA’s influence across an SOA interface boundary – while there are certainly very useful, open standards for both to leverage in delivering SOA success, one organization’s EA model compliance and content isn’t necessarily usable or useful to another organization.  

Can or should one’s Enterprise Architecture scope and framework be applied to all those 3rd-party Internet-hosted products and services a CMO relies upon?  Why not – particularly if this “External Interactive Marketing” business domain is scoped according to some kind of “services taxonomy” (that may likely have parallel definition back within the organization).  For example “Data Publishing” services (like Equifax), “Search” services (like Google), “Information Sharing” and “Community Management” services (like Facebook and LinkedIn).  While these Internet capabilities aren’t owned by the organization, how they’re used can certainly be modeled and approached from the same architectural principles, standards and experience as a already found within the organization.

Enter the “Chief Marketing Technology Officer” (CMTO), a role that combines digital marketing practice and Internet services technology knowledge, with the classic IT investment, management and operations knowledge of a CIO (or CTO). The CMTO not only understands what’s necessary to secure and control information within his organization, but also understands what does or can happen to this information on the public Internet – planned or not.  
Below is a proposed standard “Domain Reference Architecture” for the CMTO role, depicting also the intersection (and expansion) of the traditional EA role.

Chief Marketing Technology Officer Domain Reference Architecture

Helping the CMTO apply architectural principles, governance and repeatable methods for the information lifecycle external to the organization – that’s a worthwhile and appropriate role for the Enterprise Architect…and may be all the more relevant as programs and lines-of-business holistically outsource their information management capabilities to 3rd-party providers and cloud services.  Full-scope alignment of the EA practice to the CMO/CMTO’s domain is probably inevitable, as more industry analysts point to the rapid and dominant global enterprise demand of marketing departments on their organization’s IT investment portfolio.

As written on the Oracle Social Spotlight Blog, “CMOs must see the science behind the art. CIOs must see the art behind the science”.  EAs must align the art and science to meet the business case.

The Chief Marketing Technology Officer – CMTO – and the EA

The Chief Marketing Technology Officer (CMTO) is recently an
often-proposed role, that combines the interactive marketing savvy and
experience of a Chief Marketing Officer (CMO) and the traditional
information technology operations, management and investment knowledge
of a CIO or CTO. More and more often, digital marketing requirements of
an organization need a healthy integration of both marketing and IT
skills. A good deal of the CMTO/CMO’s “enterprise” scope to address is actually
outside of their organization, i.e. dealing with Internet-based
services, tools or 3rd-party sourced data and information.  This expanded, external scope can effectively, and should be addressed by the Enterprise Architect.

Business Architecture

Tom Graves recently participated in an Open Group TweetJam on Business Architecture. You can read about the results of this at http://weblog.tetradian.com/2013/03/20/opengroup-on-bizarch/ Unfortunately I didn’t hear about this in time to participate but I thought I’d record my own thoughts here. The questions were: How do you define Business Architecture? What is the role of the business architect? What real world business problems […]

#InfoArch – Post 2. The starting point

As often, we needed to start somewhere. The main idea here was about “marking the starting point” and formalize it, in order to be able to come back and measure what has been achieved later on during the journey. So, as a starting point, we performed a survey, involving stakeholders across every different main organizations […]

#InfoArch – Master Data – Short definition

Master Data is the core information, that is needed, to Manage and Operate the Company businesses. Master Data is a Core asset for Enterprise/Company. As such, it has to be Governed and Managed properly. Customer, Product, Supplier and Financial information entities are typical examples of some very essential Master Data. They need to have a […]

#InfoArch – Post 1. Information Architecture – Our definition

Introduction Within all major industries — including automotive, banking, healthcare, energy, telecommunications, insurance, and government— organizations from around the world are beginning to understand the importance and tremendous value associated with ensuring the accuracy, consistency, and timeliness of their own information. To this end, companies are gaining a better appreciation for Enterprise Information Management and […]