July 3, 3012. The concept of building information systems to serve the enterprise as a whole is no longer a new idea, but for many years we have designed and built systems for specific purposes that serve only a portion of the enterprise. Businesses often wind up with a host of stovepipe systems that are not at all connected, may well have duplicate functions, and are almost always an inefficient solution to enterprise computing. The core idea behind enterprise information systems is to consider all of the departments and functions that IT has to serve in an organization − even the functions that go across organizational boundaries. The result is almost always more efficient.
This more intelligent approach requires that careful requirements analysis be conducted. That analysis would involve looking at the potential for the data collected in one department being useful to another unit in the organization, and ensuring that cost and effectiveness are considered across the enterprise as a whole. We have actually invented a career for a whole new breed of designer called an enterprise architect, whose function in life is to ensure that the design of systems is optimized across the entire enterprise.
Where this impeccable logic more often than not fails is at the edge of the enterprise; that’s where a specific enterprise ends, and where there has to be an exchange of information with another enterprise. An example is the police department enterprise providing data to the prosecutor enterprise.
This is probably the most neglected area of careful design, and one of the most powerful ways to improve the efficiency and effectiveness of both enterprises. Too often, the edge of the enterprise is not specified to the degree that it can contribute to overall greater functionality or effectiveness. RFPs, for example, too often include statements like “there must be an interface to system x,” which tells the system developer absolutely nothing about what functionality is required at the edge of the enterprise.
Enterprise architects and requirements analysts need to be as careful in defining the processes for handling information exchange between systems as they are in delineating processes within the enterprise.
We are now engaged in a great war on stovepipes. A considerable movement toward more intelligent information sharing is underway, along with a desire to figure out how to describe the edge of the enterprise in a way that will reduce the cost, risk and time it takes to create an exchange of information between enterprise information systems. For the first time, we have created standards, like the National Information Exchange Model (NIEM), designed to foster cross-disciplinary exchanges. People have generally accepted the concept of loosely coupled systems where the edge of each enterprise is the key to the exchange of information, thus eliminating the need for costly one-of-a-kind interfaces.
Now that the Supreme Court has ruled for the constitutionality of the Affordable Care Act, more of this kind of attention will be paid as states and local governments move to implement the new law. Agencies at all levels of government are realizing that the effort to implement these changes offers a singular opportunity to consider the edge of the enterprise as various systems are converging. Issues of healthcare insurance eligibility under this new law have led many agencies to consider implementing a new, integrated processing of eligibility across multiple agencies and enterprises. Doing so will inevitably lead to a more careful definition of the edge of the enterprise.
The same kind of thinking is already being applied across such boundaries as child welfare and juvenile justice, where distinctly separate enterprises have important edges to define.
Defining the edge of the enterprise as carefully as the middle will allow us to effect the kind of information sharing that improves the functioning of government within as well as across organizations.
For an audio commentary on this topic, please click here: The Edge of the Enterprise