Active Knowledge Modeling

Active knowledge modeling (AKM) is a business-centric approach to dynamically reconfigurable service oriented architectures (SOA). Services are made available to users in the situation they find themselves, as captured by enterprise models, in a business level language. The role of a knowledge architecture is to bring purpose and context to the services, and to dynamically compose and configure business solutions from basic services in a manner far more flexible than a conventional BPMS.   

We here explore the relationships between AKM and SOA, through SOA reference models, reference architectures, maturity models, and standards. Several frameworks have been developed in order to capture and explain just exactly what service oriented architectures are. This post gives an overview of different frameworks, their purpose and perspectives:   

• Reference models developed to explain and create agreement about the meaning of key terms, and the dependencies between them,
• Reference architectures, template solutions for a domain, outlining typical components and subsystems, aspects and layers of services,
• Development and maturity models that describe different generations of SOA, or the path from a conventional application architecture towards a fully service oriented realization.
• Modeling architectures, presenting overviews of modeling methods, which models should be developed and how they fit together, and how the modeling languages are structured.

Web services (WS) standards are also plentiful. People have mapped them before, but the dependencies between different standards are seldom visualized. We present a WS standards map that captures major dependencies.

Reference Models

Reference models aim to create a common ground for communication, typically with a vocabulary and/or taxonomy. Such models are logical or conceptual, aiming to describe the domain, not to list software components.   

OASIS’ SOA reference model is commonly applied, e.g. by government agencies in Scandinavia. It is a pure terminology model, which defines seven key elements (in grey below) and the relationships between them. The basic perspective is service provisioning, following the definition of service as an activity performed by someone (the provider) for someone else (the client, customer, user). The emphasis is on the interface between client and provider, through concepts such as service description, visibility, context, interaction, effects, contracts and policies.   

From an active knowledge modeling perspective, the focus on different service models is interesting. At the same time, these models seem to reflect a conventional software engineering paradigm, emphasizing IT more than the business architecture.   

OASIS SOA reference model

(Figures in this post link to the source document)

Business Centric Methodology (BCM) is an earlier specification from OASIS, which represents a wider, more user-oriented perspective. It takes a structured approach, defining a pyramid with different layers and cross-cutting aspects. Core elements of service description are represented at each layer, and relevant standards are identified.   

OASIS BCM (also known as the Lubash Pyramid)

The business centric approach is followed by active knowledge modeling, and the content assembly (CAM) and template mechanisms promoted by BCM are probably the most relevant standards for our approach, alongside the recent work on dynamic business activity modeling in the OMG. Some of the standards mentioned above, like CPP, CPA and BPSS from ebXML, are representative of the eBusiness and EDI approach to SOA. That approach focuses on some of the most static and well-structured domains, where processes and information content can be fixed and standardized. This is the opposite of the knowledge intensive core processes targeted by AKM.   

Interoperability overlaps with service orientation. The European Interoperability Framework (EIF) discusses the ability to cooperate and exchange information on the political, organizational, legal, semantic, and technological levels. This model emphasizes governance and business architecture, while services are mainly covered in the interoperability chain dimension.   

European Interoperability Framework

The focus on enterprise over technology is clear in that 4 layers deal with the first, and only the lower layer covers technology. Semantic interoperability has too long been thought of as a technical problem, like we discussed in previous posts. From a knowledge architecture perspective, the 3D framework illustrates reflective thinking, e.g. in representing services and actors (administration, business, citizens) across all levels of interoperability, not just in the organizational and political contexts. Such a multi-dimensional approach is at the core of AKM.   

The Reference Model for Open Distributed Processing (RM-ODP) focuses more on objects than services, but still this standard vocabulary from ISO/IEC defines core concerns for SOA. It looks at the architecture from five viewpoints:    

RM-ODP Reference Model

A viewpoint is defined as an abstraction that focuses on a selection of concepts and dependencies, according to specific needs. The different viewpoints complement each other:   

• Enterprise purpose, scope, principles, requirements and policies,
• Information, its meaning and processing in computerized systems,
• Computational distribution and functional decomposition into objects that interoperate through well defined interfaces,
• Engineering mechanisms and functions that facilitate distributed interaction among system objects,
• Technology platform.

Representing the domain from different viewpoints, and presenting different views to different users depending on their concerns, roles and tasks, is a core feature of an active knowledge architecture. The viewpoints above do however reflect technology development roles, more than business stakeholders.   

Reference Architectures

Reference models aim to increase understanding of a domain, and to establish a common terminology. They overlap with reference architectures that show best practice solutions. While reference models typically also see service orientation as an organizational design principle, most reference architectures limit their scope to the technological aspects.   

The European Interoperability Framework (EIF)  includes a reference architecture for eGovernment services. Here we recognize the concepts from the interoperability chain dimension of their reference model. The model covers typical SOA components like portals, process integration, service composition, security, and interoperability.      

European Interoperability Framework reference architecture

The Open Group represents SOA as a layered IT-architecture with nine layers. The emphasis is purely technical, no enterprise operation aspects are included. The layers do however cover the complete lifecycle of a service, including development, usage, provisioning and governance. Different categories of services are not as easily distinguished in such layered frameworks because it is difficult to represent more than one organization principle (dimension) at a time. The depiction of four layers as planes, does however indicate that the concerns of integration, QoS, information, and governance cut across the five technical layers.      

SOA Reference architecture (© The Open Group)

Such technology centric views are suitable for categorizing technologies and standards. From our perspective, the representation of process is troubling. Processes may be found at any layer, just like information structures. The architecture above separates coded composition and encapsulation of services and components from modeled composition in processes. The notion of processes reflected here is that of BPEL, the Block-structured Program Execution Language, which has very little to do with business processes.   

Web Service Interoperability Organization (WS-I) organizes their web service standards profiles according to a layered communication model, suitable for protocol stacks. This view is simple and concrete, but less relevant for service oriented enterprise architectures. 

WS-I reference architecture (© Web Service Interoperability Organization)

SOA Alliance emphasizes different tiers of services in an integrated framework, creating one of the most detailed reference architectures. The placement of the tiers side by side, rather than layered on top of each other, reflect the many different ways to integrate services implemented by various technologies. This model also highlights management and security aspects, though enterprise operations and service users are considered outside of the scope.      

SOA Alliance reference architecture

Maturity and Development Models for SOA

SOA is a label pinned on many different technical structures, from conventional applications integrated via web services, to complete corporate architectures with extensive reuse and a structured approach to development, evolution, and management. Maturity models have been defined in order to differentiate between different SOA generations, and to present roadmaps for SOA introduction.   

The Open Group Service Integration Maturity Model (OSIMM) outlines 3 ”service foundation levels”, silo, integrated and componentized, that lead towards 4 generations of services oriented architecture, as illustrated in the table below. These levels are separated according to seven layers of enterprise and IT architectures. This model can be applied in assessing the maturity of a given company, and to identify reasonable next steps towards increased service orientation.

The final generation, dynamically reconfigurable services, is what AKM methodologies and tools aim for. The Open Group here points out a suitable vision for a future agile and business oriented SOA, which is dynamically reconfigurable, context-aware and event-driven. We do however think they get two critical technology areas wrong, business process modeling and information management through semantic data vocabularies. Conventional business process modeling is neither reconfigurable nor event-driven. Processes should be combined with product models and other knowledge dimensions in order to capture the rich context and all the interdependencies that event notifications and rules must help the users to coordinate.   

Semantic modelers look to the sky, to a general, stable, precise, objective and rational expert ontology, as the means for semantic annotation, enrichment, mediation, transformation and reasoning. Theirs is a theoretical approach to canonical data models, unsuitable even for level 3 in OSIMM. A dynamically reconfigurable knowledge architecture must remain on the ground, capture the messy realities, partially understood by different people, with different backgrounds, from different disciplines and functions, filling different roles, performing different tasks, and applying different local terminologies. Interpretation and meaning are contextual, and most classification structures are local to a view. OSIMM seems to recognize this last concern by refering to vocabularies rather than taxonomies, but semantic technologies remain obsessed with formalization, developing solutions that do not facilitate human interaction or social construction of shared meaning.   

Our approach is to replace business process modeling with holistic enterprise modeling, and semantic data vocabularies with pragmatic, contextual, and federated knowledge architectures.   

Zapthink presents a roadmap for the development of a comprehensive service oriented architecture, following similar perspectives as OSIMM. The roadmap covers steps from legacy wrapping to mashups and service oriented enterprises. They have been able to fit waste amounts of valuable guidelines into a single map.   

Zapthink SOA roadmap

IMS Global is a training company that publishes good guidelines for SOA development. They also envision a seven step process, but do not go all the way to dynamically reconfigurable services.      

IMS model for SOA development

SOA Standards

In our analysis of the many standards proposed for SOA, we have come across a few good overview maps, like the poster from Innoq, or the (slightly outdated) roadmap from CBDI forum. Below you find our attempt to cover what these overviews do not, the dependencies between different standards, from W3C (white), OASIS (light grey) and others (dark grey). In order to avoid complete spaghetti chaos, dependencies on the basic standards for XML, XML Schema, WSDL and SOAP, are not shown. We have also hidden components of composite standards such as WS-Security, WS-Notification and WS-Transaction, and dependencies that can be derived transitively, e.g. when a standard depends on both XSLT and XPath. Please drop us a note if you discover additional errors or omissions.   

SOA standards - dependencies