Close the Loop: Measure the Effectiveness of Change Investments using Capability-Based Planning

The previous article in this blog series covered how a Capability-Based Planning approach informs the Strategic Roadmap. We covered the Plan and Assess phases of Capability-Based Planning. In this blog, we’ll link the Plan and Assess phases to the Control phase of this process. To measure the effectiveness of change investments, you need a way…

How Senior Management Can Use Business Capability Maps To Make Better Investment Decisions

Today we live in a rapidly changing world. Senior management is faced with various change initiatives to improve the different functions of an enterprise. All of these change initiatives are backed by well-informed arguments and compete for budgets. Although strategic management has access to a vast amount of information and tools to support strategic, tactical,…

Improving Communication between Business and IT with Enterprise Architecture Information

Olga Lucia Salgado, a senior enterprise architect at a privately held manufacturing company, used to rely too much on Excel and SharePoint for enterprise architecture (EA) information. She and her team came to the conclusion that an EA tool was needed to help them mature and organize their information and analysis. After evaluating a number…

Gossip, Trust and the Information Revolution

Our massive use of IT (the information revolution with its information inertia and its fast but stupid behaviour) is enabling our innate behaviour to surge against our learned behaviour and that is severely damaging the social structures we humans have created. Why is this happening and what can we do about it?

A Technology Roadmap for Regis College

When Regis College, a private university in greater Boston offering undergraduate and graduate programs, sought to create a technology plan to support their performance goals, they turned to Systems Flow. Like many higher education institutions, Regis was grappling with a series of questions regarding the ability of its technology environment to manage data and information […]

An Architecture for a Customer-Centric Healthcare Information Infrastructure

1.    Healthcare IS: The Obsolete and Broken Infrastructure

The healthcare Information Infrastructure is both an obsolete and broken system.  It has at least four major problems.  The total system is technologically fractured between paper-based systems and computer-based; and the computer-based system is shattered among competing technologies, (for example, PC versus smart phone).  The number of health-care information regulations and standards militates against a coherent information infrastructure. 

The Fractured System

Any system in a technology change process will be fractured between the old and new technologies.  However, the healthcare system is particularly fractured because of overburdening federal regulations for insurance, for care, and for HIPA. 
Then there are the interlocking state regulations and insurance policies and procedures.  All of these make creating a healthcare information infrastructure difficult and complex.
Additionally, a significant portion of the medical professionals are the opposite of tech-savvy.  So they stick to paper—lots and lots of paper.  Compared with electronic storage, the simple storage of paper is expensive.  Then there is the time and expense of retrieving a patient’s medical records.  All of these costs are absorbed in the cost of healthcare.
But there is yet another, potentially life threatening expense; the loss of records and the inaccessibility of records when patients are on travel.  When people move for a new job or other reasons, the medical data contained in their records is more frequently than not lost.  
When they travel and have an accident or medical problem, their medical records contained in this fractured infrastructure are normally inaccessible.  The inability of onsite medical personnel to have access to a patient’s medical record can be an unnecessary death sentence for the patient.

Number of Regulations and Standards

There are other problems caused by this fractured healthcare information infrastructure.  As noted, there is a large increase in office staff to manage the paper records caused by the regulations supporting the “affordable care act”. 
This is in addition to the HIPA and state regulations, and insurance company’s policies and standards. Is it any wonder that doing paperwork is the single largest expense in a doctor’s office or medical center?

Non-linkage to Research

One of the most significant challenges in medical research on various diseases is tracking a disease through generations to determine if the disease is caused by environmental factors, or by a person’s generic heritage.  Given a set of standards and regulations (not over regulations) an integrated healthcare information infrastructure could provide the necessary information to enable much better insight in a much shorter time, at much less expense.

Non-linkage to Technology

There is another very expensive problem caused by the highly fractured and fragmented information infrastructure.  Currently and increasingly, there are many digital sensors on the medical device market.  These sensors include, X-ray, MRI, and cat scan machines.  There are also digital thermometers, blood pressure sensors, heart rate monitors (including Fitbit, Garmin, and Apple watches).
Additionally, they include a host of equipment for evaluating eyes, ears, blood, nervous systems and the hundreds of other evaluation sensors.

2.    Customer (Patient) Centric healthcare Information Infrastructure Architecture

A goal of a customer-centric healthcare information infrastructure architecture is to enable the customer to have complete access control over his or her health data and information in an ultra secure data network (USDN) while providing a high-level access to non-personal (i.e., aggregated) data for research and development.
I recently posted a high-level architecture for such an USDN; having said that I will now the healthcare information infrastructure as an example.

Customer ID and HIPA

The first component of this USDN is the user (customer) interface.  The key concept embedded in the HIPA rules and regulations is to keep access to the customer’s data to only those with a need to know.  Currently, the person who gives written permission is the customer [Sidebar: I don’t like the term patient because of its implications and connotations.]
With the USDN, the user/customer would give permission to medical personnel by inserting a smart card.  This card would contain biometric data.  The user/customer would then use the sensor on the medical terminal to confirm that they are who they say they are.  For example, put their finger on a fingerprint reader. 
If the biometric information on the card matches the information given by the user/customer then the medical personnel can get to the portion of the customer’s medical record and history they need to do their job.
If a customer comes into an emergency room unconscious the medical personnel can get authorization in much the same manner.  This could save the customer’s life.
In a hospital, the access to the customer’s record and history could be systematically extended to all appropriate personnel through the use of authorization or entitlement meta-data.

The Bridge/Portcullis

A second unique feature of the Ultra-Secure Data Network is the network bridge with portcullis.  The bridge converts the standard Internet communications protocols (that are well known to hackers and which malware uses to attack computers) into a set of network protocols much less well known. 
The portcullis allows only a limited set of formally defined data in formally defined data formats across the bridge.  The portcullis has other functions that are somewhat arcane, but which are important for security. [Sidebar: A high-level description of these is found in my post on the Ultra-Secure Data Network]

Centrally Organized Geographically Distributed Datastore

The data storage software will be what is currently being call “in the cloud”.  That means that the data is stored in data centers that are protected by the USDN including the bridge/portcullis.  Additionally, the operating system and application software will be customized to accept only data that is in the authorized formats.

Datastore for Research

The Medical Information Infrastructure is a cornucopia of data for medical research.  Currently, this data is, in the main, inaccessible to medical researchers due all of the rules and regulations for the current fractured system and to the nature of gathering data from a fractured system.
With the functions and features of using the USDN, data from the Medical Information Infrastructure could be made available to researcher without destroying the privacy of the customers of the system.  In turn, this would reduce the cost of medical research significantly.

3.    Building the USDN

Because of the size, scope, and complexity of the Medical Information Infrastructure it will take at least 10 years for the initial build out.  I will describe the major tasks of the build out, as I envision them, currently.

Setting up the Governance of the Infrastructure

The key to the USDN is setting up the processes for defining data, meta-data, governance, and infrastructure management.  Without these, the infrastructure will either be hacked immediately or be completely ineffective.

·         Governance

As I see it, the governance of the infrastructure will make or break both the security and utility of the infrastructure.  This governance sets the data, meta-data, and infrastructure management policies, standards, and rules for the infrastructure. 
That is why it needs to be the first task; though it will run concurrently with other tasks.
As I envision it the board of governors (guiding group, whatever the name) should be made up of medical professionals, medical researchers, insurance personnel, and IT professional from business and academia.  Getting that eclectic group moving in the same path will be difficult.  Therefore, I think an Enterprise Architect with a Systems Engineering group will be needed. 

·         Data

There will need to be a process set up for defining the data that should be in the USDN, the format for communicating that data and for creating, updating, and deleting data formats and structures.  Once set up this will be one of the key governance processes; changing data types and the actual data formats as technology changes.
One key to the USDN is that no unformatted data, like e-mails and e-mails with attachments will be allowed.  This cuts off one prime access points for hackers.

·         Meta-Data

For security purposes, the definition and delimitation of the infrastructure’s meta-data is of seminal importance.  It is what enables authentication, authorization, and access to the data of the Medical Information Infrastructure.  The governance body together with the Enterprise Architect and the Systems Engineering group will need to make decisions as to what is and what is not allowed, always with an eye to securing the data.
For example, the terminals connected to the internet, in turn connect to the USDN through the Bridge/Portcullis.  Each of these terminals will have a specific and static Media Access Control (MAC) address.  I would recommend that these terminals also have a static Internet Protocol (IP) address and other static information tied to that particular terminal.  This would make is difficult to spoof the bridge/portcullis into allowing a hacker through the gateway.
Additionally, there are many other ways this static (or infrastructure management only) meta-data can be used. But they will be guided by the rules and policies set by the governance board.

·         Infrastructure Management

The infrastructure management team will manage the hardware, software, and meta-data of the Medical Information Infrastructure as the prototype is rolled out and the operational version is built out.  It will be under the guidance of the governance board.

Developing the Bridge/Portcullis

The design requirements for the bridge/port will come from the standards and policies set by the governance board as architected by the enterprise architect and the functional and component designs will come from the Systems Engineering team.
There are several technical innovations required for an operational USDN.  I would recommend that a series of prototypes be developed using a cyclic process, like the one I developed and was patented by the Northrop Grumman Corporation.  That is, design, create the prototype, test, and repeat until all of the requirements are met.  I would expect that this development effort will take a minimum of one year and can be started about three to six months after the governance board begins their work which will identify the requirements for the equipment.
The first is the Bridge/Portcullis.

·         Designing

Designing the bridge/portcullis can be divided into two functional designs.  The first is the design of the network bridge.  This should not be as much about creating a design as resurrecting a design of a network bridge from the late 1990s.
The second is the design of the portcullis.  This is a wholly new functional and component design, though based on many standards.
When these functional and component designs are complete, then the entire bridge/portcullis will need additional functional integration design work.

·         Prototyping

A series of prototypes will need to be constructed, in following the Technology Readiness Level (TRL) characteristics.  I expect that the bridge can be prototyped at level 7 or 8 right from the start.  However, the network portcullis starts as a TRL level 1 or 2.  It will need to cycle through a number design, prototype, test cycles before it will be ready for integration with the bridge.

·         Testing

All prototypes will be evaluated against the metrics as defined by the requirements.  This means that prior to testing the systems engineering team will need to establish metrics for each requirement.

·         Rollout

When all of the cycles of design and functional testing and requirement evaluation of the bridge/portcullis are completed, the unit will be replicated two or more times for use in the pilot testing effort.

Developing the User Terminal(s)

The user terminals for the Medical Information Infrastructure are an interesting combination of advanced technology being used for a single purpose terminal (a throwback to the 1960s).  Some of the functions of this terminal type are discussed in my post on the USDN.  One key function will be enabling automated medical sensors (X-ray, MRI, etc. machines) to report results of tests through the terminal to the Medical Information Infrastructure.

·         Design

Again, the design of this terminal should start as soon as its requirements are identified (3 to 6 months.  In this case, the design is really more in terms of a system integration of functions rather than the development of new technology.

·         Prototyping

Constructing prototypes of the terminal should not nearly as difficult as the development of the bridge/portcullis.  But again, it is likely that several prototypes will be needed to get the functions and form factor correct for the terminal.

·         Testing

Likewise, testing should be relatively straightforward.  The most extensive set of tests will be those associated with terminal and network security.

·         Rollout

When all of the cycles of design and functional testing and requirement evaluation of the terminal is completed, the unit will be replicated several times for use in the pilot testing effort.

Datastore

The datastore, the hardware and software for storing the customer’s data, is by far the simplest of the functions/components that will need to be developed.  The reason is that commercial off the shelf hardware and software is available.

·         Design

In this case the challenge is to write custom code and define the parameters of standard database software and the operating system such that the data is secure from hacks inside individuals (the technical staff) and to provide the access for the various functions of the infrastructure.  For example, giving access to researchers to summarized or anonymous data would be one such function.
This development exercise would use a cyclic process, like the one I developed and Northrop Grumman patented.

·         Prototyping and Testing

Even while a software service is being coded it will be evaluated on a daily basis and formally tested at least once a month.  Frequently, the testing will not only reveal bugs and inconsistencies, but also additional governing board requirements and technical risks.

·         Rollout

As opposed to the bridge/portcullis and terminal, I expect that the datastore appliance (the combination of hardware and software) will be rolled out as an Initial Operating Capability (IOC) with a minimum number of data structures and software functions.
Additionally, I expect that one a one to three month cycle, new versions of the software will be integrated into the appliance.

Pilot Testing and Updating

Once the governance board has decided that enough of the bugs, defects, and other “gotchas” have been worked out of the system (likely after about one and a half to two years), the infrastructure will need to be acceptance tested.  For this type of system pilot testing is the only procedure guaranteed to clearly demonstrate all of defects in the total system from the various users’/stakeholders’ perspectives.
Ideally, this would be a progressive slow roll out, first to a single site, then to three sites, then to 10 to 12 sites with at least 3 data centers.  Ideally, this piloting phase will take one to two years.
At the same time there should be a significant increase in the types of data the infrastructure can store and the number of functions the infrastructure can perform for the various stakeholders.

Build out of the Infrastructure

Within six months of the start of pilot testing, the build out of the infrastructure can begin with user/stakeholder education about the infrastructure.  These educational activities will prepare the medical and medical IT professionals to deal with the coming changes in a more orderly manner.
As the pilot testing is coming to an end, hardware and software companies should be invited to start building products to the infrastructure’s specifications.  These would be sent to a test environment for certification as meeting all of the specifications.
These competing products could then be sold to the medical community as the infrastructure is built out across the nation.

4.    Issues

I would forecast that creating the Medical Information Infrastructure will reduce the total medical bill paid by customers, insurance companies (including governments) by 10 to 30 percent while producing much better outcomes.  This is a significant reduction in cost (hundreds of billions of dollars per year).
However, there are powerful groups that will oppose the infrastructure’s creation.  Some of their arguments will be economic and some emotional (in terms of politics or organizational culture).

Implementation Costs

Many in the current medical establishment point that the implementation of this system will be very expensive.  It will; there is no doubt of that.  It may run into $100 billion over ten years, but it will likely save more than $10 trillion over that same period.  That seems like a good investment for the country.  With the added bonus that it will save lives.
From a hospital or insurance company’s CFO perspective, this will turn into a gigantic expense for which there will be no immediate ROI. [Sidebar: This turns “short-term cost conscious” CFO type financial engineers nuts—I know.]  Again, they are correct.  But there will be a significant ROI long-term.

Politics/Cultural Issues

There are also many political/culture issues

·         The Affordable Care Act, Medicare/Medicaid, HIPA

[Sidebar: The US Constitution specifically states that governmental healthcare, like other social entitlements are within the purview of the states, not the federal government; an attitude that my ultra-left leaning “social responsible” friends find distressing.  However, since we’ve already entered this financial black hole that lead to dystopia, I think we need to find a way out of it or at least to ameliorate many of its worst effects.]

These federal laws mandate a great many enforcement rules and regulations.  These rules and regulations will be unnecessary with the Medical Information Infrastructure.  However, many federal and state bureaucrats will have to find other employment if they are removed.  So, politically they will lobby for most of them to remain.  This will cause a great deal of process friction and greatly reduce the benefits of the infrastructure.

·         Pilot Testing

[Sidebar: “The first instance of a superior principle is always inferior to a mature instance of an inferior principle”.]

Critics of the Medical Information Infrastructure will have a field day with its pilot testing.  Like many complex military systems, (three being the B-52, the M-1A2, and the CVN 78) and like many versions of software in beta testing, the system will have many hiccups and gotchas when first brought up in a pilot.  Even if the program, describes above, is followed there will be technical defects.  And like the critics of other complex systems, there will be many that will say the Medical Information Infrastructure will never live up to its hype or its promise.  In the short term they will be correct, but wrong in the long term [Sidebar: The Gartner Group calls this the hype-cycle, I call it the path that the way the future becomes the now.]

·         Medical Culture

There are three cultural issues associated with implementing the Medical Information Infrastructure.  The first is the current medical culture.
The Medical Information Infrastructure is being proposed as part of the conversion of the medical information system from the Age of Print to the Age of the Computer (as I discussed in a previous post). 
As such, people brought up in the age of print have much greater difficulty in dealing with this type of change.  That is true for medical personnel as well as everyone else.  Consequently, they will resist any automated system.
Even in medical facilities that have automated the records management this change will be difficult.  It’s like learning how to use a tablet after only using a PC.

·         Insurance Culture

Insurance is the transference of the consequences of a risk (an unknown) from the customer to organization insuring.  This comes at a price, the cost of insurance.
The cost of insurance is based on the probability that something bad will happen.  The probability is based on statistics of how often the bad thing happens within a population.  That, in turn is based on data—data that would be stored in the Medical Information Infrastructure instead of now, in a huge collection of digital and paper files spread across the country.
This means that there would much less cost in gathering and maintaining this information, but it also means that the culture of insurance selling, and adjusting would change.  And as with the medical professional, cultures resist change.

·         Customer Acceptance

One of the major challenges will be acceptance by the customer base.  In the pilot phase, customers, not fully into the computing culture will be very anxious about the processes, where his or her records are stored, and why the change is necessary.
Additionally, the customers will be anxious about the necessary changes in law to enable this system to function effectively and cost efficiently.  This stress will be hyped in the media and transmitted to congress.  There is no way to stop it, but education/marketing will be able to ameliorate it to some extent.

Meeting the Issues

Meeting these cultural issues will require significant education, training, and marketing to  create initial grudging acceptance.

The Technology Landscape

The need of the technology landscape IT-departments need to know the technology for which they are responsible. Operation need to know both the infrastructure and the applications they are operating, and so they register the technology from an operational perspective (preferably in a CMDB). In projects, you often see sketches of a technology mapping, as […]

Categories Uncategorized

Enterprise Architecture: It’s Not Just About Technology Anymore

bg outline

Ben Geller, VP Marketing, Troux

renaissance opt1 071614 2 (2)In our last blog post, The Next Chapter of Enterprise Architecture: Self-Service, we examined the change in mind-set that seems to be occurring in all corners of the enterprise when it comes to EA. We wrote about EA tools as a catalyst to empower stakeholders all across the enterprise with quality decision-making information available whenever needed:

“With digital and technological disruptors firmly rooted in our world there is a massive mind shift at play in how we interact with technology as well as how we expect to get things done.”

In this post we will further explore why the timing now seems right for EA to go through this renaissance.

To start, EA has evolved. It is no longer an IT-centric discipline focused on creating a set of artifacts in the form of complex maps and models only understood by a few with limited ‘actionability’ in terms of driving measurable business outcomes. To serve the evolving needs of decision-makers EA has evolved as well. With the rise of digital business and the rapid pace of change in the market it is more important than ever for decision-makers to not only know exactly where to invest in their business, but to also better understand the impacts of those investment decisions.

“While many biz & IT execs are aware of disruptive innovations in IT (such as the nexus of forces and digital business), they often struggle to identify the impact and implications of these innovations to their business model.” – Gartner

With the most comprehensive understanding of how every piece of an organization is connected, enterprise architects are poised to take the lead in how the enterprise responds to disruptive forces and change, whatever their origin.

When we talk about disruptive forces we mean consumer expectations, digital business, new technologies, regulatory demands, social media and more. EA in a leadership role helps organizations navigates these disruptors while staying focused on its strategic goals and vision.

In this new era enterprise architects still have to maintain their knowledge of IT, but they have to move beyond those contributions and activities, introducing themselves as strategic advisors who communicate EA’s value to all parts of the business. Today, enterprise architects are also looked to for strategic budget decisions. They must be able to vet how a new investment will support corporate outcomes and transform the business. Further, they must assimilate the integration costs and process to assure the company realizes the value.

This renaissance of EA has only just begun, but some big wins are already in the marketplace. Read how Troux customer HSBC is undertaking a massive program to simplify operations through EA. Find the complete article on Computer Weekly, HSBC makes executives responsible for application consolidation.



New Call-to-action

Categories Uncategorized

Beyond Technology: How Enterprise Intelligence Supports Business Strategy and Change

bg outline

By: Ben Geller, VP Marketing, Troux

keep up 041014 blogOur last post introduced the concept of enterprise intelligence (EI), the CIOs answer to business intelligence (BI). EI is a relatively new concept in the world of strategic technology planning and the more we explore it, the more opportunity we see for its applicability beyond technology and into other parts of the C-suite.

This post takes a look at how change affects strategic business planning, and the role EI plays in mitigating risks in a climate driven by constant and rapid change.

Paul Boag said it best: “The problem is that the very nature of change is changing.”

Today chief strategy officers (CSO) and similar functions struggle with gaining the insight needed to make strategic decisions, because those decisions must happen quickly and the information needed to evaluate risk factors is often difficult to obtain or takes too long to aggregate. Strategic planners are often tasked with identifying and evaluating market expansion opportunities, M&As, divestments and the like, but it’s not as easy as pouring time into due diligence anymore. Nowadays, immediate attention and nearly quick decisions are required if a business wants to capitalize on fast moving market trends. The challenge for the CSO is to make decisions at the speed of the market while mitigating business risk. Doing that successfully means planning is no longer an annual exercise – it is now a continuous function and the corporate transparency EI delivers makes it possible.

A world of constant change demands enterprise intelligence

Whether it’s contemplating how to leverage game-changing disruptive technologies like social media, mobile, analytics, and cloud to develop a new business model or charting a new market expansion strategy, EI gives CSOs much needed line-of-sight across the enterprise.  From this vantage point CSOs can understand how everything works together and impacts each other – from Goals and Strategy to Business Capabilities to Applications and Technology. This means that opportunities and risks can be evaluated in the context of the entire enterprise and decision-makers become equipped with the insights they need to make business investment decisions faster and with greater confidence. As a result, EI becomes an integral part of the strategic planning process  

Changing with Change

Until now, CSOs have struggled to gain the enterprise-wide insights needed to set strategies and make key decisions at the market’s rapid pace. EI changes all that because it arms them with the decision-making information they need to have a meaningful dialogue about the business at a moments notice. The insights produced by EI tools allow CSOs to quickly and methodically maneuver the business as the market changes by delivering enterprise transparency that shows the cost, impact and benefits of change across the connected enterprise.

It’s true, change is changing. And, so are business models, technology and the competition. Doesn’t it make sense to adopt a strategic planning approach that delivers insight into the best way to anticipate and address these changes?

We think so.

Learn more about continual planning in Forrester’s white paper, Connecting The Dots: Building An Integrated Strategy And Execution Plan.

Key Takeaways include:

  • Market conditions can change so rapidly that strategic direction may change by the time a final decision is made.
  • A company’s mission may not vary frequently, but market changes force business models to change with greater frequency.
  • Strategic planning has become a continual exercise that, when closely integrated with adaptable delivery strategies, enables companies to anticipate opportunities and, based on the right balance of innovation and operational effort, deploy minimum viable products, which allows them to mitigate risks that accompany large, drawn out project cycles.

     



    New Call-to-action

     

Categories Uncategorized

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.