Showing posts with label NIEM. Show all posts
Showing posts with label NIEM. Show all posts

February 21, 2010

Common Language for Enterprise Architecture

What happens when one set of enterprise architects can’t read another’s enterprise architecture “artifacts”?

This may sound ridiculous, but this is a very real problem at the Department of Defense (DoD) and at many other agencies.

Government Computer News, 1 February 2010, has an article on “Primitives and the Future of SOA” about how “DoD looks to develop a common vocabulary to improve system design.”

Dennis Wisnosky, the chief technical officer at the DoD Business Transformation Agency came face-to-face with this problem:

“We were building a business enterprise architecture when the whole team changed because the contract [that the work was being performed under] was won by different people…The new company came in and, all of a sudden, their people had different ideas for how the architecture should be built…Their way might have been a good way, but we had already invested hundreds of millions of dollars in another way, and it seemed to be a wiser course of business action to get these new people to learn the old way.”

Mr. Wisnosky tackled the problem head-on:

Like the periodic table of 117 core elements that make up everything in our world, Mr. Wisnosky set out to build the DoD architecture using a set of primitives or basic building blocks. “Primitives are a standard set of viewing elements and associated symbols” based in DoD’s case on the Business Process Modeling Notation (BPMN)”—a graphical representation for processes in a workflow. Armed with the set of primitives, DoD was able to get “the business process architecture, so that they are described in a way that the meaning of this architecture…is absolutely clear to everyone.”

Wisnosky aptly compared using a common language (or set of primitives) for EA, so everyone could read and understand it, regardless of their particular EA methodology to how musicians anywhere in the world can read standard music notation and similarly how electrical engineers can read electrical diagrams based on standards symbols.

This is a big step for EA, where traditional architecture artifacts are not as user-centric as they should be and often leave their readers/audience questioning the purpose and message intended. In contrast, the use of a common EA vocabulary and set of symbols is right in line with developing a user-centric enterprise architecture that is easy for users to understand and apply, because once you know the standard set of primitives you can read and understand the architecture better than an architecture based on a proprietary or ever changing vocabulary.

As Wisnosky points out, primitives are also a nice fit with Service Oriented Architecture, because you can use primitives or patterns of primitives to represent standard business processes and these can be used over and over again for the same services that are needed throughout the business.

This use of primitives for business process notation is consistent with the use of the National Information Exchange Model (NIEM) for information notation. “NIEM enables information sharing, focusing on information exchanged among organizations as part of their current or intended business practices. The NIEM exchange development methodology results in a common semantic understanding among participating organizations and data formatted in a semantically consistent manner. NIEM will standardize content (actual data exchange standards), provide tools, and managed processes.”

While, we need to leave a certain amount of flexibility in EA for architects to apply their trade to meet specific agency requirements, there is a huge benefit to standardizing on a common vocabulary, so architects can speak the same language. This concept is all the better when the language and design methodology selected for EA is simple and clear so that even non-EA’s (our regular business and IT people) can read and understand the architecture.

Building EA with primitives and clear and simple vocabulary and design represents a user-centric EA moment that I for one, applaud loudly. Another way to say this is that an EA without primitives is a primitive EA.


Share/Save/Bookmark

June 13, 2008

Preventing Another 9/11 and Enterprise Architecture

From the tragic events of 9/11 came the Intelligence Reform and Terrorism Protection Act, the findings of the 9/11 Commission in 2004, and the Presidential memoranda in 2005 and 2007 to better share information.

ComputerWorld Magazine, 26 May 2008, reports that “nearly seven years after 9/11, information-sharing problems that hobble law enforcement are just beginning to be solved.”

What is the information sharing problem in law enforcement?

There are “20 federal agencies and 20,000 state, county, local, and tribal enforcement organizations nationwide.” The problem is how do you get this multitude of varied law enforcement organizations to share information to identify the bad guys?

While 75% of police agencies use automated systems to manage incident report data, only 25% of those systems are capable of sharing that information.

What’s being done to fix the problem?

First (not mentioned by ComputerWorld), the Office of the Director of National Intelligence (ODNI) is establishing common terrorism information sharing standards (CTISS) to drive and enable information sharing among Law Enforcement, Homeland Security, Intelligence, Military, and Diplomatic information domains.

Additionally, the Department of Justice is developing a data dictionary/schema to establish a “common vocabulary and structure for the exchange of data.” First, this took the form of the Global Justice XML Data Model (GJXDM) in 2003, and later took form in the National Information Exchange Model (NIEM) in 2005 that extended the effort from “law enforcement to other areas of justice, public safety, intelligence, homeland security, and emergency and disaster management.” (Note: Defense and the Intelligence Community have a comparable data standard initiative called U-CORE.)

This past March, DOJ and the FBI’s Criminal Justice Information Service (CJIS) division “began rolling out the National Data Exchange Initiative (N-DEx), a NIEM complaint database and data sharing network.” N-DEx provides “federated search capability across incident reports residing in state and local record management systems nationwide while allowing those records to be updated and maintained by their local owners.”

The goal is to have “the majority of the country participating” by 2009. The biggest obstacle is that many agencies’ systems have been so customized that integration is now challenging and expensive.

According to the FBI’s website, NDEx will be accessible via the internet and “includes several basic but vital capabilities, including searching and correlating incident/case report information and arrest data to help resolve entities (determining a person’s true identity despite different aliases, addresses, etc.). N-DEx will also create link analysis charts to assist in criminal investigations and identify potential terrorist activity.”

According to the NDEx brochure (available online at the FBI website), law enforcement agencies who participate in NDEX will:

  • “Sign an operational Memorandum of Understanding (MOU)
  • Identify and map incident/case data to the N-DEx Information Exchange Package Documentation (IEPD)
  • Obtain network connectivity through an existing CJIS Wide-Area Network (WAN) or connect over the Law Enforcement Online (LEO). “

The architecture concept here is summed up nicely by Linda Rosenberg, Director of the Pennsylvania Office of Criminal Justice: “Now you don’t have to go back and build these data warehouses and totally redo your entire infrastructure.”

Instead, you plug in to the NDEx and share information that’s been mapped to the common data standards. NDEx provides the target infrastructure, while NIEM provides the data exchange standards. Together, we can share information for better achieving our law enforcement mission—protecting the American people.


Share/Save/Bookmark

June 6, 2008

Information Sharing Standards and Enterprise Architecture

In response to the 9/11 Commission’s recommendations, the Intelligence Reform and Terrorism Prevention Act (IRTPA) of 2004 called for an Information Sharing Environment (ISE), “an approach that facilitates the sharing of terrorism information” and that requires the President to designate a Program Manager for the ISE and to establish an Information Sharing Council to advise the President and the Program Manager.

The Common Terrorism Information Sharing Standards (CTISS) Program Manual is a construct for ISE. It defines both functional standards and technical standards.

  • Functional standards—According to the CTISS Program Manual, these are “detailed mission descriptions, data and metadata on focused areas that use ISE business processes and information flows to share information.” From an enterprise architecture perspective, I believe this would correspond to the business and information perspectives of the architecture as well as be extended probably to the performance perspective. In other words, functional standards correlate to the three business perspectives of the Federal Enterprise Architecture. These are the standards that define our requirements, in other words, how we measure performance (for example, Balanced Scorecard), how we engineer business processes (for example, Lean Six Sigma), and how we describe information sharing requirements (for example, NIEM or U-CORE, and Information Exchange Package Descriptions).
  • Technical Standards—“methods and techniques to implement information sharing capability…[for] acquiring, accessing, producing, retaining, protecting, and sharing.” From an enterprise architecture perspective, I believe this would correspond to the services, technology, and security perspectives of the architecture. These correlate to the three technical perspectives of the architecture. The technical standards include how systems will interoperate or share information (for example, J2EE, .NET), what technology standards will be employed (for example, XML, SOAP, UDDI) and how security will be assured (for example, various from NIST/FIPS, ISO, IEEE, and so on).

What I like about the CTISS is that it attempts to define a comprehensive framework for the ISE from the highest-level being the domains of information (such as intelligence, law enforcement, homeland security, foreign affairs, and defense) and drills down to the security domains (SBU, Secret, and US-SCI), reference models, (FEA, DoDAF, IC EA…), standard types (metadata, data, exchange, and service), standards bodies (NIEM, W3C, OASIS…), and then the standards themselves.

As an initial impression, I think next steps are to articulate how I share information with you or you share with me. Currently, we are still defining techniques for future sharing of data, like developing metadata, creating a data dictionary and schema, defining exchange standards, and service standards to discover data through registries. It like responding to someone who asks, how do I get to your house, by saying, we need to pave roads, design and manufacture cars or buses, install traffic signs and lights, and so on. That’s all infrastructure that needs to be built. That still doesn’t tell me how I get to your house. While we are making huge progress with information sharing, we’re still at the early stages of figuring out what the infrastructure elements are to share. But it seems to be a running start!


Share/Save/Bookmark