Enterprise Architecture (EA) captures “what is happening” in the enterprise: how the enterprise’s activities, processes, capabilities, systems and components, information resources and technologies relate to the enterprise’s missions, goals and measurement system. The objective of EA is to be able to understand the relationships between these elements -- analyze and continuously adjust them to align with business strategy, improve effectiveness and quality of service. This is an important goal critical in today’s enterprises where business functions are inseparable from the technologies supporting them. However, the implementation of EA typically falls very short of the goal.

Enterprise Architecture (EA) captures “what is happening” in the enterprise: how the enterprise’s activities, processes, capabilities, systems and components, information resources and technologies relate to the enterprise’s missions, goals and measurement system. The objective of EA is to be able to understand the relationships between these elements -- analyze and continuously adjust them to align with business strategy, improve effectiveness and quality of service. This is an important goal critical in today’s enterprises where business functions are inseparable from the technologies supporting them. However, the implementation of EA typically falls very short of the goal.

 
In many organizations, EA is captured in PowerPoint presentations, Word documents and collections of spreadsheets. In some cases, UML models are created. While the underlying information is captured and available, the approaches used to document it make it very difficult to utilize it effectively. By utilize we mean ability to get specific, up-to-date answers to core business questions such as “If a Call Center goes down what business processes will be affected?” Or, an even more actionable answer: “how can those processes be supported by alternative systems?” Consequently, only select people, typically Enterprise Architects and Modelers, look at the EA information. The rest of the organization typically views EA as a set of fairly static models maintained by the ‘high priests’ of the architecture and irrelevant to their own daily needs and activities.
In contrast, an active Enterprise Architecture is one where the information can be accessed by anyone who needs to know how the data and processes flow within the enterprise and how technologies support this flow. Information sought and questions that can be answered may vary from simple policy management (Which data sources have current information? Which ones are being phased out?, to integrated information (What are all the things I know about this business function?), to sophisticated analytics (What systems will be impacted if I change the technology that implements this information source?).
Semantic Web technology offers a number of unique capabilities making it an obvious choice for implementing an active Enterprise Architecture.
Flexible Modeling Language
An enterprise’s structures, activities and the connections between them change frequently. The way an organization may want to describe and capture these information objects and relationships can also change. For this reason, rigid data models do not work well for EA.
RDF/OWL data models are flexible and easily evolvable. The models and the corresponding data are expressed in the same way, as subject-predicate-object triples. Multiple triple statements get linked together by matching on the subject, predicate or object. This way, more complex statements can be expressed. As triples get connected, a network structure emerges, known as the RDF graph. Merging new information simply means adding more triples. Changing the model means adding and removing triples. In most cases, changes in models do not require porting of existing data.
Integration, Distribution and Federation
Enterprise information comes from multiple sources – databases, systems, files. In the context of a large enterprise, it is not practical to expect that a single system will be used to define EA models and to capture the relevant data. Different business units within an organization may already use established tools that fit their specific needs and processes. Even if they could all be required to move to a common new system, such a move would entail significant costs. As organizations go through mergers, acquisitions and restructuring, such costs will be recurring.
With RDF, models and data expressed in different formats can be seamlessly integrated. Simplicity of RDF data model (triple statements) means that it can be easily used to represent other data structures. RDF provides the infrastructure for creating a connected web of information, whether on the public internet or within enterprise intranets. Like the familiar World Wide Web, the Semantic Web is easily extensible, enabling enterprises to break out of information silos once and for all.
Globally Unique Identifiers
All RDF resources -- that is anything referenced as a subject, predicate or object of any triple -- have unique identifiers or URIs. URIs are Web-compatible and Web-scalable.
Globally unique identifiers make it possible to reference model information (schema) and corresponding data irrespective of their source. This feature is an important aspect of how RDF-based infrastructure supports the distribution and integration of information.
Modularity and Re-use
Ability to reference and aggregate schemas and data means that models can be modular. In fact, modularity is considered to be a best practice for developing complex enterprise models in RDF/OWL. Modularity means re-use as well as an ability to agree on some things while disagreeing on others.
For example, two different business units of an enterprise may define their sales regions in a different way. One may include Texas in their South region, while another considers Texas to be part of the West region. Using RDF, each organization can define their own versions of South and West sales regions while referring to the same shared resources such as Texas. This approach makes it possible to describe and compare business practices of two organizations using a common vocabulary even if the borders of their sales regions are different.
Query Language
Information expressed in RDF/OWL is intended to be accessed in real time by people and systems. Just as relational databases have a standard query language (SQL), so does the RDF data model. SPARQL , the semantic web query language, is supported by all the leading vendors of RDF databases and tools.
 
Standard Semantics
RDF, OWL and SPARQL standards are managed by the World Wide Web consortium (W3C). A powerful advantage of these standards is that their semantics are expressed in a mathematically precise and unambiguous way. Early in the evolution of the standards, the W3C placed significant focus on constraining all the definitions to ensure interoperability. As a result, today one can easily take information from one RDF database or tool and view it in another without any loss or misinterpretation of the meaning. This means that EA models are no longer locked in any proprietary format and can be easily interchanged across different tools or systems.
 
Business Rules, Constraints and Policies
OWL provides a logical language for describing semantic relationships between the different elements of EA, including relationships between different data sources. Connections that previously had to be accomplished with custom software can now be described in a standard, declarative way. In addition to the built-in semantics of RDFS and OWL, enterprises can use SPARQL to add domain and organization-specific business rules and constraints. SPARQL has CONSTRUCT and ASK operations (as well as the SELECT operation) making it into a rules language that is supported by every RDF system.
 
Those interested in implementing an active Enterprise Architecture using the Semantic Web standards will find a growing number of resources to bootstrap their projects. For example, there are tools that enable enterprise architects to easily harvest schemas and data from any data source into RDF - including spreadsheets, databases, XML, and UML. There are also a number of ready to use EA ‘patterns’ or modeling modes already expressed in RDF/OWL including:
Federal Enterprise Architecture (FEA):
BRM, PRM, SRM and TRM taxonomies describing lines of business, performance measurements, services and technologies:

• https://osera.gov/web/guest/projects/fea-rmo (original, corresponding to FEA 1.0)
• http://www.topquadrant.com/resources/FEA.html (updated for FEA 2.0)

Policy models for WS-Security and WS-Reliability standards: https://www.osera.gov/c/portal/layout?p_l_id=PUB.1.46
Increasingly, the demands of modern enterprises to both optimize their day-to-day operations and develop strategic capabilities in their organizations, processes and infrastructures are driving the need for what we have characterized as an active Enterprise Architecture. Semantic Web technologies can be quickly harnessed to provide all enterprise stakeholders flexible access to actionable information that was previously locked in proprietary and siloed formats. This makes EA a good candidate for a first Semantic Web project. It provides an immediate ‘quick win’ value to an organization while establishing the infrastructure and skills to use this important emerging technology for many other applications.