Semantics & SOA - part 1 "Survey"

Over the next month we are going to take an in depth view of how Semantic Integration is being applied to SOA. The notion that the Semantic Web and SOA might be linked began to emerge in 2005 & 2006. Since then it's been gaining some momentum. Keep in mind though that "Semantic Integration" & "Semantic IT" do not by their nature narrowly confine themselves to SOA or the Web. However, Services Oriented Architecture is a natural, ready-made proving ground for what we're describing on this Blog.

This first post reviews some interesting resources on the web that illustrate the genesis and evolution of the combination of Semantics and SOA.

Conceptual Framework:

• Bringing Semantics to Service-Oriented Architecture:Ontology-based Mediation for eGovernment

This is an excellent briefing which lays out basic concepts and potential applications for SOA, presented by the Chief Scientist at Top Braid, a semantic web technology provider.

• Managing SOA Semantics Using Ontologies and Supporting W3C Standards..."Web 3.0?"

A concise overview from the Zapthink crew.

• Semantic service oriented architecture

The wikipedia take, or one of them anyway...

Semantic coupling

An excellent assessment of why many SOA efforts are falling short...
excerpt "Unfortunately, syntactic coupling is the easy part. Semantic coupling is the harder part of the problem, and SOA does little or nothing to address this challenging issue. Semantic coupling refers to the behavioral dependencies between components or services. There’s actual meaning to the interaction between a consumer and a service."
We will be taking a much closer look at this issue soon...

Interesting Applications:

• Semantic SOA to Promote Integration of Heterogeneous B2B Services
• The Axiom Project (we will look at this further soon)
• SAIC Building Semantic SOA
• Semantic Interoperability - Revelytix
  

More links Courtesy of Mills Davis:

• Smartlogic - Semantic Middleware
• Fighting Fraud with Semantic Technology
• Business Semantics, Enterprise Architecture & Data Architecture
  

In our next post we will try to outline the architectural imperative for using "Semantic SOA."


copyright 2008, Semantech Inc.

Semantics & Governance

Someone asked me recently whether or not there some type of tangible relationship between Semantic Integration and governance - it was an excellent question and the answer is a resounding "Yes."

Let's approach this at each of the levels where it applies:

Level 1 - Understanding the Nature of Governance at a Conceptual Level

Level 2 - Using Governance as an enterprise process medium

Level 3 - Using Governance as a foundation for detailed policy management (at the technical level)

While much of the current dialog in IT has focused on SOA Governance, IT or Enterprise Governance has a much wider scope than Services Oriented Architecture. And of course all of this extends into business areas or domains that go beyond IT. One of the great things about Semantic Integration is that at its heart it is not limited to Information Technology per se, Semantics provide the foundation for Every aspect of an organization, not just its IT capabilities.

So let's return to level 1 - our first problem is that most organizations don't currently agree on what Governance is. As evidenced by our discussion thusfar, Governance can be directed at many specific areas or be viewed holistically across them all. Semantic Integration helps us determine the core definitions and relationships in this conceptual competition - at the heart of all Governance definitions lies the need to conduct "Oversight." The corollary to that is the ability to engage in active remediation of issues discovered within the scope of oversight. These are both 'management' activities.

Our next post will explore level 1 Governance in more detail...


Copyright 2008, Semantech Inc.

The Here & Now of Semantic Integration

I've read some articles again this week explaining that the promise or potential of Semantic Integration is still a bit far off from being able to engender significant impact to the enterprise. Perhaps, it is worth examining the subject more as a practice approach rather than a standards or technology dependent facilitation medium.

By that, I'm simply reiterating that "Semantic Integration" is not synonymous with the "Semantic Web." There is a quite a bit that can be done right now with the techniques being described here (in concert with a limited but growing set of Semantic tools, although they aren't always required). As our previous post highlights, one of the first places where this can occur is with Enterprise Architecture. Anyone who has ever spent the time reading through DoDAF data models or building meta-models in Metis can testify quite convincingly that the entire field of EA is essentially one giant semantic exercise. I still tend to describe myself as an Enterprise Architect or Integrator; it was specifically because of my roles that I was drawn to Semantics as a way to solve a number of persistent and related challenges.

Take that further, what underlies UML, design patterns and J2EE language syntax ?... more semantics. It's already here, it's already pervasive within IT, but what we haven't done yet is fully appreciate this linguistic tower of babel we've created (and unlike the real world where the approximate number of languages is more or less stable with several universal translation modes, IT adds new semantics EVERY DAY).

Semantic Integration begins with this realization - that all enterprises represent ecosystems or cultures with unique semantic perspectives. Furthermore these virtual ecosystems are unlimited in regard to how many relationships may develop (we not only have individual entities within communities and communities within communities, we also have dynamic re-alignment both externally and internally). So step one is simple, define our enterprise perspective - this is the foundation for all other IT efforts and can be done using any number of tools starting with pencil and paper. How many data standardization or MDM efforts skipped this step and focused on defining core data elements that were already biased toward DBMS paradigm or another?

Semantic Integration is IT's first, future and favorite natural language activity. Eventually all discovery and all IT-related capabilities will be managed using natural language rather than XML, SQL , J2EE or some other technical proxy language or syntax. The sooner that occurs, the sooner that we will recognize the benefits both of IT and Semantic Integration. So how does one get started - it seems daunting, well maybe it is if you are too tied to one architectural perspective or language but if you can view this situation with an open mind there are several ways to get started.

(Next Post - Getting started with Semantic Integration...)




This view illustrates a real-world example of how Semantic Integration was introduced into a large enterprise without requiring a radical influx of Semantic Technology...

Copyright 2008, Semantech Inc.

Semantic Integration & Enterprise Architecture

In many ways, Enterprise Architecture (EA) is as misunderstood as Semantics. Although EA has been practiced across a much wider community of IT professionals for a longer period of time, it still suffers from an identity crisis. Is EA the mandatory precursor for model driven development, or is it part of a bigger picture and if so, what is that picture?

It is my contention that the reason Enterprise Architecture is still misunderstood in many quarters and often unsuccessful in practice is precisely because it does exist within the context of a larger picture. All too often, that larger picture is simply ignored leaving those executing EA projects somewhat perplexed as to find meaningful ways to make their efforts relevant to the organization sponsoring their efforts.

Enterprise Architecture represents a practices, tools and techniques which have evolved to help define the nature and state transitions of an organization from an IT perspective. The business view of the enterprise is of course included within this perspective but EA at its heart is and always has been driven by technology. The EA perspective is of a virtual entity, perhaps even the cyber-identity of an organization. This view allows those who manage and maintain complex system of systems ecosystems through exploitation of a holistic characterization of all capability elements. However, like most things in IT, EA as a discipline suffers from a lack of clarity regarding its core principles and approaches. In other words, there is no agreed upon definition for any aspect of Enterprise Architecture right now.

Seeing a big picture - an example of a "Meta-EA view"

So, Semantics and EA come together on many different levels; first in the need for one to clarify the other, secondly in the ability to build that larger context and big picture view of where EA fits along with all of the other aspects of IT. To understand the complexity of the problem, it is worthwhile to capture some of the competing definitions that one current finds associated with the term “Enterprise Architecture:”

• Enterprise J2EE Architecture – This has been formalized within the curriculum and certification paradigm of the Sun Java Enterprise Architect designation. [http://www.sun.com/training/certification/java/scea.xml ]

• Federal Enterprise Architecture (FEA) – This has been defined by the Federal Government and supported through certification paradigms. http://www.enterprise-architecture.info/EA_Certification.htm

• Department of Defense Architecture Framework (DoDAF) – A wholly separate framework paradigm from FEAF.

• ToGAF, Zachman Architecture Frameworks – Commercially driven approaches.

• Unified Modeling Language – Often included within the context of other approaches but also often used standalone to manage EA efforts.

• Agile Enterprise Modeling & Architecture – Much more application development focused, generally less formalized than strict UML.

• Other Technical Specific Architecture – This is a long list and can include things such as .NET, Web 2.0, and literally 100’s of other software products.

• Service Oriented Architecture – This often now is bundled with business modeling using BPEL.

• Semantic Architecture – Yes, there a few people using this now although mostly within the context of semantic web technology or pure Ontological development.

So, what then is Enterprise Architecture, really? Is it a framework or set of frameworks, is it product specific skills, is it language specific skills, is purely technical or partially business focused, is it the metamodels and notation language used to characterize design?

Semantics allows us to integrate Systems & Architectures

The simple answer is that EA has been and will be what it needs to be to those who need it. There is no one approach now because no one approach will handle all of the related duties that architects are saddled with. The more important question has always been, will we find a way in which we can coordinate the various types of EA activities. This is an exact corollary to the questions that helped launch EA as a discipline (of set of disciplines) some twenty to thirty years ago. At that time pioneers in EA were looking for a way in which they could combine and coordinate the complexity of their systems environments. So, now its seems that EA has lead us to meta-integration. And what is the one approach we now have to tackle the problem at the top of complexity pyramid – Semantics.

copyright 2008, Semantech Inc.

Semantic IT Practices

As noted in a previous post, the current set of methodologies employed in the day to day IT operations of a typical enterprise is poised for perhaps its most significant paradigm shift in several decades. This evolutionary shift is not the introduction of Semantic technology or standards per se, but rather the complete re-visioning of how IT works in the context of Semantic Interoperability. Semantic IT provides us with two crucial capabilities that we simply never had before:

1 – The ability to abstract the governance and maintenance of the systems under our control in an automated fashion.

2 – The ability to link all the various disparate IT-related processes through that same abstracted Semantic governance layer.

What’s really missing at this stage are the semantically enabled methodologies and/or practices that will allow us to exploit these capabilities effectively.

So what exactly is a semantically enabled practice or methodology? The difference that Semantic Enablement brings to enterprise operations is the deliberate focus on operational fusion or merger of processes in an effort to achieve a holistic management paradigm. This means that there are no longer any “stove-piped” approaches or technologies, all efforts must have the capability to inter-relate with all other capabilities and share the same foundation.

This holistic approach will require several new or at least modified IT practices with updated methodologies designed to take advantage of both the philosophical and technical shift in thinking. It is likely that this should lead to a certain level of consolidation in the number or diversity of existing IT practices as the central tenet involved is essentially holistic awareness and interoperability. Once it is realized that all aspects of IT architecture and operation are in fact related, the need for diversification and specialization will be reduced. There should not for example, need to be separate disciplines for Master Data Management and Semantic Integration, as MDM represents a specific application of Semantic Integration across multiple data sources. In fact, many or most aspects of data architecture or integration could at some point be considered within the umbrella of Semantic Integration.

One of the real benefits of viewing IT methodologies or practices this way is the deliberate attempt to keep them technology agnostic. These practices are not driven by vendor solutions. Previous practice approaches based upon individual or categories of vendor solutions have often proved short-sided and counter-productive, leaving the enterprises which adopted them vulnerable in many ways. The application of operational IT capability (i.e. business services) doesn’t require specialization of support infrastructures, instead it should have a flexible common framework that can be redefined as needed. Our goal is not to be able to predict all possible permutations of our solutions and build that into some rigid roadmap – the true goal is to give control of that map to those who need to adapt their solution in their own context, according to their needs.

That foundation then is an abstracted governance or management layer which mediates between all others aspects of IT architecture. It is accessible to and modifiable by stakeholders, which allows for much more economical and efficient governance processes. One of the most exciting parts of this is the opportunity we now have to merge design, architecture and governance using semantic modeling. This will likely manifest itself in a blending of ontology management and EA framework or even agile modeling techniques.

I’ve taken an initial stab at defining a set of Semantic IT practices, these have all been developed to replace existing counterparts and designed to be interoperable with one another. These practices encompass most if not all current IT processes and include:

Semantic Integration (most generic in nature, next generation solution for enterprise systems integration).

• Service Oriented Integration (service & application logic).
• Program Lifecycle Management (program, product, project, portfolio, process synergy).
• Dynamic Learning Orchestration (organizational and personal learning and knowledge management).

In my next blog entry, I will describe Program Lifecycle Management, the new PLM, in more detail.

Semantic Integration & IT

In many ways the practice of information technology has changed little over the past 30 years or so. It may not seem so on first appearance - but the premises upon which our current technologies are still operating are largely based on philosophical constructs that date back 30 years or more.

Those constructs include:

• The Relational Database.
• The Data Warehouse.
• System Management (system as self-contained entity).
• "Static" Business Rules Management (more or less permanent view of the nature of rules within the enterprise) - exemplified by maturity models.
• The notion of IT service provision as separate and distinct from the elements of the business which they serve.

Of course, there are exceptions to this but in many ways these basic foundational elements still represent the core of most IT activity within the typical enterprise. Each of these areas and others has arisen to meet certain needs; there has been an ever-increasing level of specialization within IT that has more or less extended the basic model without really changing it. This has made some areas of IT management more effective but has hindered the ability to truly unify IT capability. Some people refer to these phenomena as 'sub-optimization' or 'compartmentalization.' In the government arena it is sometimes referred to as 'stovepiping.'

The dilemma is the same though, how does one make progress and get work done while solving near-term specific problems and simultaneously leverage the full potential of all enterprise assets? This can be done and can occur in the near-term using existing technologies - the problem we face now though is one of perception and philosophy. IT is used to working in its current sub-optimized mode, its relative detachment from the primary functions of the organizations it serves tends to provide a disincentive to view the big picture requirements they always receive yet never truly fulfill.

The paradigm shift that needs to occur and that will occur within the next five years is this - The realization that the enterprise is a dynamic entity. In other words, it is not something that can ever be fully coded or captured in advance. A 'pre-determined' enterprise family of systems is obsolete before it ever deploys. The other element of the realization is that the key to all integration within the enterprise is already embedded within it. The enterprise as a holistic capability will be achieved once we understand that regardless of the specializations involved, all aspects of the mission are related and that the unifying code embedded throughout it can be managed, mediated and coordinated as a single semantic exercise.

I truly believe that this represents more of a philosophical change than a technical one. It requires new methodologies and IT practices that view problems from this updated perspective. Eventually it will lead to modifications in many commercial software products and networking technologies, but those changes are not necessary to begin experiencing the benefits of the Semantic Enterprise.

Copyright 2008, Semantech Inc.

Semantic Integration - The SI of Tomorrow

Currently when people use the acronym “SI” they tend to refer to something known as ‘Systems Integration’ or specifically to ‘Systems Integrators.’ However, the nature of what a 'system' is and how that concept is evolving are going to change the way that we look at this particular term in the relatively near future. I predict that within the next ten years, ‘SI’ in the context of information systems technology will primarily refer ‘Semantic Integration.’

The Evolution of Systems Integration

What I mean when I say that Systems Integration and the notion of Systems are evolving is that new design concepts and technologies are having a radical and disruptive influence on current integration practices, processes and design approaches. What was a ‘system’ under distributed computing environments is now undergoing a transformation – taking on aspects of both the distributed model used today and centralized models from yester-year. This is largely coming about due to the advent of Services Oriented Architecture (SOA) technology and design principles. It is important to note here that SOA, like Semantics, is a practice area based upon design philosophies and technical standards – the tools being developed in relation to those philosophies standards or applied to it are not the drivers for these trends. Folks who focus on the software tools only and not the underlying principles tend to run into many difficulties in implementing these types of new capability.

Our previous or current experience with System of Systems architectures is what led to the need for System Integration and Integrators largely as an afterthought or mitigating action in response to the need for rapid deployment of multiple, new distributed technologies. Most enterprises have spent the last twenty years playing catch-up in this environment and few are truly architected in any comprehensive sense of the term. System Integration is often a tactical activity – ensuring data passes between systems silos, connecting various applications point-to-point or through limited middleware capabilities, deploying portals and unified sign-on and security management and so forth. Piece by piece, an enterprise becomes more unified under this type of scenario, but at a cost – that cost is increased complexity and expense for maintaining non-standard integration.

The future is upon us; that future is just now promising something new – the ability to coordinate architectures across tiers, across federated domains and across all related lifecycles. The new enterprise can be viewed as a single organic system, consisting of dozens or hundreds of services that operate as a single unified yet dynamic entity that is often federated across geographic and logical domain or boundaries and orchestrated at runtime. This is SOA but it is more than SOA, because SOA doesn’t yet have the necessary philosophical framework for exploitation of Semantics to help achieve this enterprise unification. That’s where Semantic Integration comes into the picture.

What is Semantic Integration ?

Semantic integration is not is not confined to or restricted to the ability to operate or configure or utilize specific semantic technology or software packages. Semantic Integration represents a specialized field of practice dedicated to using Semantic Design Principles, Methodologies and technology as a facilitating mechanism (often alongside SOA) to help solve enterprise-level problems for IT. SI as a practice area is relatively new (it is only now being defined), it is much more than the “Semantic Web” yet is obviously built upon the capabilities inherent within the emerging set of Semantic standards that can be used to express and ultimately visualize semantic entities, RDF, OWL and so forth).

Copyright 2008, Semantech Inc.