Net-Centricity, SOA, and Web 2.0

Redefining Mob Mentality

My Photo

About

Search


  • Search This Blog

Recent Posts

  • Net-centricity, Web 2.0, and SOA relationship
  • Top Heavy SOA
  • Grady Booch is Mistaken
  • SOA and Modularity
  • The Truth About SOA
  • Enable Net-Centric Interoperability Prototyping and Design Testing
  • Brokering Shared Services
  • Facilitating Community Service Interface Specifications
  • Promoting The Use of Open Industry Standards
  • Using CoIs to Promote Net-Centricity and SOA

Categories

  • Bandwidth
  • Communities of Interest
  • Design Approach
  • EAI
  • Modularity
  • Net-Centricity
  • Web 2.0
Subscribe to this blog's feed

Enable Net-Centric Interoperability Prototyping and Design Testing

While the SOA architecture greatly reduces the overall Net-Centric system complexity through the decomposition of system functions into modular services and the development of Community Service Interface Specifications, it does call for increased attention to the process of prototyping, testing, and validating system design decisions.  These efforts are best completed within a joint prototyping lab that is chartered to focus on systems integration through effective interoperability architecture and design. This is necessary because:

·                     To achieve overall system agility and adaptability, system functions that were once performed by a monolithic component are now implemented as a set of loosely coupled services interacting with one another.  Each individual service interface must effectively enable many-to-many interoperability. Some more difficult and challenging service interface specifications require prototyping to enhance the design prior to development. This will enhance the quality of the design, reduce the need for subsequent modification, and decrease the interoperability implementation schedule.

·                     Net-Centric systems shift focus from application-centric performance to the “composite” system behavior where capabilities on the Net are orchestrated together to deliver a mission capability. The prototyping environment enables enhancement of system interoperability design through the investigation of expected aggregated system behavior.  It also enables the testing of  how services behave when orchestrated in multiple configurations to meet several mission threads in a dynamic environment where mission needs may change rapidly.

·                     A prototyping environment with simulation capabilities enables experimentation and prediction of aggregate system performance in a variety of Net-Centric physical environments from fixed sites with significant and reliable bandwidth to edge computing with bandwidth constraints and occasional connectedness. This will enhance interoperability design and also provide valuable information on the computing hardware and software infrastructure required to achieve Net-Centric systems success throughout the GIG.

·                     The prototype environment also provides a means to demonstrate a Net-Centric system in a controlled environment. This capability is crucial for gaining senior leader champions of the Net-Centric SOA approach and in building momentum and enhancing the change management aspects of this critical technology transformation initiative. 

Although service interoperability testing is normally the job of the service consumer in a large and open marketplace, in smaller communities a leveraged CoI prototyping and testing environment can significantly advance SOA/Net-Centricity adoption. However, this capability is basically shared infrastructure and therefore faces all the challenges associated with funding and managing shared infrastructure that supports cross organization utilization.

August 01, 2006 in Communities of Interest | Permalink | Comments (0)

Brokering Shared Services

Creating and exposing services on the Net is a critical and significant achievement but success does not end there. True Net-Centric success is measured in the numbers of service consumers and the leverage achieved. An important value-added activity for the CoI leadership involves brokering the leverage of services across the CoI participants and other potential organizations outside the CoI. This activity reaches beyond the design and development phases to the consumption of operational services available on the Net. Value-add activities includes supporting services discovery and efforts to facilitate use of existing services available on the Net versus buying or building new. Some of these are:

·         Ensure the services discovery infrastructure is in place and properly utilized so that organizations can readily find, understand, and effectively consume services on the Net.

·         The CoI leadership can facilitate cross-organization requirements for Net-Centric service enhancement. A service that is built for a primary user base may, with relatively minor adjustments, become more valuable to the Net and consumers that were unanticipated when the service was originally designed. The CoI can utilize their work with the DCGS Service Interface Specifications to recommend service changes to enhance leverage-ability in the Net-Centric Environment.

·         The CoI leadership can provide assistance to CoI participants by delivering education and outreach assistance, documentation, collaborative capabilities, and human expertise targeted at promoting understanding, awareness, and leverage of existing services. Changing organizational behaviors in this transformation initiative is crucial to the success of Net-Centricity. This involvement is necessary up front and may subside as the transformation matures and the culture of service discovery and utilization emerges.

·         Assist CoI component organizations in the development of cross organization security and data access policy and procedures. A more centralized group such as the CoI leadership can support inter-agency interoperability by establishing standard policy, shared processes, and best practices for cross-organization service access.

·         Assist CoI component organizations in building cross organization relationships and in establishing and maintaining memorandums of understanding (MOU) and memorandums of agreement (MOA).

·         The CoI leadership can represent the community as a whole in facilitating interoperability with other communities such as national agencies and coalition organizations in DoD's case.

August 01, 2006 in Communities of Interest | Permalink | Comments (0)

Facilitating Community Service Interface Specifications

Promoting Web Services industry standards is a first step. Developing a set of standards-based Community Service Interface Specifications that describe how systems share functionality and data with each other and the Net-Centric GIG is the primary endeavor of the CoI. Accomplishing this involves establishing a multi-level CoI structure that develops and evolves the service interface specification enabled by a more centralized team that manages the CoI and the interoperability architecture artifacts. The centralized team is divided into the management team and the design team.

The CoI management team is responsible for determining the multi-level CoI organization and managing the productivity of CoI efforts. The multi-level CoI involves organizations and members that participate at varying levels including a core team, an extended team, and the general participation. The CoI management team must carefully determine the make-up of the CoI to ensure productivity and rapid returns. The core team must be chosen strategically. It should only consist of those organizations that are required to gain critical mass and no more. In industry service interface specifications are often established by a single organization like Amazon and E-bay who are large enough in themselves to drive a service interface specification into wide spread adoption. Although the DoD and other communities may not enjoy this luxury, by strategically connecting a few “eight hundred pound gorillas” a community can build a Community Service Interface Specification that can quickly deliver value not only to the gorillas but also to other organizations who are willing to adopt the specification. If the CoI leadership chooses the core team correctly then the demand for the services provided by the gorillas will drive specification adoption. The community, through the extended team and the general participants, can evolve the specification to meet the “20%” of specific needs. Assembling a core team that is too large can stall progress and lead to a specification that is too “specific” to have general applicability. Conversely, choosing a core team that is too small will inhibit adoption of the specification. The general rule is to assemble the “market makers” or those organizations that offer the most value to the “net” by exposing their capabilities as Net-Centric services.

The design teams leads the technical work and captures the CoI efforts into systems and service design artifacts. It subsequently collects input and manages configuration control on the design artifacts. These artifacts include the Community Service Interface Specifications themselves as well as the critical design documents (use cases, sequence diagrams, etc.) upon which they are based. The technical team can also manage interoperability compliance and exception handling of developed services through conformance with the Community Service Interface Specification.      

         

August 01, 2006 in Communities of Interest | Permalink | Comments (0)

Promoting The Use of Open Industry Standards

The CoI leadership should be the champions of promoting the use of Web services open industry standards (XML, WSDL, UDDI, etc.) for community systems interoperability. The community CoI can make it clear that interface standards based interoperability is the best practice approach  over platform heterogeneity, point-to-point, or hub-an-spoke message broker based interoperability.

Although some of the newer more specialized standards are still maturing, the Web Services standards as a set have gained wide spread utilization throughout the world and the risk of their abandonment is minimal. SOA can be achieved through the use of other interoperability standards (e.g., CORBA IDL, JMF, XML RMI), but no alternative to Web services has the wide spread applicability or adoption for system to system interoperability.

It is important to understand the distinction between Web Services interoperability standards and community Community Interface Specifications. Web services standards are the general language constructs used to create community Community Interface Specifications. For example, the WSDL standard is used to describe the operations that a service can perform and the XML\XSD standard is used to describe the community data dictionary that services utilize. Creating a single common set of operations and data, instantiated in a single Community Interface Specification as the definitive vernacular for community interoperability, is ideal and can be achieved over time but it is very difficult to accomplish during the early stages of Net-Centricity. As history proves, getting a very large community of organizations to agree on a single data model is laborious and time consuming with a high risk of failure. This is where the use of Web Services standards delivers significant benefits.

Even if two organizations do not use the same Web Services based Interface Specification, because they are based upon the Web Services standards, interoperability can be achieved through Web Services translation using XML Schema Language for Translation (XSLT) or semantic mediation services. This translation can easily be automated and often does not require any coding development. Translation is unavoidable and is a healthy part of Net-Centric interoperability maturation. If all community Community participants agree to use Web services then this is a major step forward that will lead to faster interoperability results. A single common Community Interface Specification is the goal and the community must progress towards that end but agreeing on utilizing Web Services interoperability standards enables incremental progress as a function of “marketplace” evolution rather than working group decree.   

   

The CoI leadership can promote the use of Web services industry standards through policy, financial incentives, architecture guidance, implementation efforts, governance, and any other means by which they can exert influence. It is imperative that CoI leadership place the interface specification driven approach as the centerpiece of community interoperability.

Additionally, the community CoI and the component organizations should strategically and actively participate in industry standards bodies such as OASIS, OMG, and W3C. Active participation ensures that the community will influence the continuing evolution of the standards to meet their needs. Participation also will greatly assist the community in developing, propagating, and maintaining expertise in open industry standards that will translate into more effective systems interoperability implementation.

August 01, 2006 in Communities of Interest | Permalink | Comments (0)

Using CoIs to Promote Net-Centricity and SOA

Net-Centric effectiveness depends not only on technology but also on process, people, and organization. The US Department of Defense is embracing communities of interest (CoI) as virtual organizations to facilitate collaboration between organizations in the march towards Net-Centricity. An effective way to achieve a scalable, multi-agency interoperable systems capability is through a well managed CoI. There are four main efforts the CoI leadership can undertake to spur transformation and achieve Net-Centric interoperability by making it easier for the community component organizations to build interoperable systems, minimize impact on their central operations, and maximizing leverage between organizations:

  1. Promote the use of industry open standards for systems interoperability
  2. Facilitate community service interface specifications
  3. Enable Net-Centric interoperability prototyping
  4. Broker shared services to maximize systems reuse\leverage

August 01, 2006 in Communities of Interest | Permalink | Comments (0)