enry Ford's development of assembly lines was of major significance to the manufacturing process. Ford brought all of the raw materials and skilled workers into a single facility and focused on the efficiency of building the entire product.
The assembly line model was in place for many years before a more global model predicated on a cheap, efficient
transportation infrastructure supplanted it. In modern manufacturing, companies turn conventional wisdom on its head
by decomposing the production process into optimized manufacturing with mind-boggling workflows. Sub-assemblies are
produced by specialist facilities in parts of the world where it can be done cheaply and efficiently. These partial
results are then sent elsewhere for further development and integration. It has reached the point that, for example in
the world of dolls, there is a
specific company that produces just eyes and
It seems inconceivable that this new form of manufacturing would work as well as it does because of the complexities involved. Henry Ford's model seems like it would be the right way to do it, but this new supply chain approach recognizes some fundamental principles that change the game. It realizes that there are efficiencies to specialization not exploited in the assembly line model. Not every step takes the same amount of time. Not every skill can be utilized maximally by waiting for the preceding steps to occur. By allowing each sub step to occur in one location at maximum efficiency, the overall process can be made dramatically more efficient. A finished product becomes an orchestrated workflow of materials flowing through a combination of optimized sub-steps. Not only does this have an effect on the overall cost and efficiency of the process, it also engenders an agility to respond to new demands quickly. Resilience is gained by having a distributed process that's not as subject to the sensitivities of local politics, weather, or unexpected disasters. Retooling and rerouting to accommodate new requirements requires only localized effects. Not every facility along the chain needs to be affected and new steps can be woven in quickly without upstream dependencies.
Supply Chain Service Oriented Architecture
The supply chain vision applies to the world of service oriented architectures (SOA) and Enterprise development. Historically, this software development approach yielded vertical silos where everything was done in one place or application. Database layers feed raw content to various processing steps, which display the end results through a client-facing technology. This approach has dominated the industry's thinking for quite some time, but this is starting to change. The single-application strategy has the same costly duplication and inefficiencies as Henry Ford's assembly-line approach. You cannot reuse functionality locked behind the application boundary. Not every step takes the same amount of time. Costly contention for resources (e.g., database connections, processing threads, synchronized access to shared state, etc.) can affect the computational and economic costs of the entire effort. Scaling horizontally by adding more processing nodes helps, but that is too expensive and ultimately not the best strategy.
Supply chain SOA suggests a model in which you can tie together individual data sources and services on demand to produce a desired result. New requirements put minimal burden on reorchestrating a different configuration with new processes. Each piece of raw material (i.e., data) can be identified at its source and referenced as needed. It is not necessary to pass actual data everywhere, which results in costly duplication and unmanageable regulatory access control compliance. These ideas have always formed the basis behind the SOA space, but it has not been accomplished fully or cheaply using the WS-* stack.
You can implement this vision today by applying the concepts of the web in the Enterprise, combining URL-addressable RESTful web services and data sources into sophisticated, efficient processes. It is not necessary to pull all the pieces into a heavy deployment structure like conventional J2EE and .NET applications. New functionality becomes a recombination of existing information and functionality. Each step can be separately credentialed and tied into arbitrary single sign-on or other authentication and authorization systems. While many organizations commit to an Enterprise Service Bus (ESB) to coordinate all of this, the web demonstrates that this is not required. It is easy to imagine building on top of the following ideas with an ESB or without one.
What is necessary is a cheap, efficient infrastructure to identify data sources and services to allow these potentially complex orchestrations to combine with low inertia. It is necessary to find, select, and bind to these subcomponents. Users and developers cannot be expected to remember URLs, particularly as they are likely to change. Instead, a classification scheme is needed to describe all of this content and functionality via metadata. Nearly all service-oriented environments have attempted this with arguably tragic and unsuccessful results. The JINI community attempted to define a taxonomy of services for devices and software but the approach taken was not flexible enough to satisfy everyone. UDDI attempted to provide a hierarchical metadata infrastructure but ultimately failed to deliver sufficient value for the cost of implementation.
The issue with the existing approaches is that they require too much human agreement and are not universally
applicable across services and data. The social costs of these efforts always far outweigh the technical costs. It is
necessary to support different classification schemes because it is simply not possible to achieve consensus among
all stakeholders. Additionally, it is necessary to have a consistent metadata strategy for not just the services, but
the data, concepts, policies, documents, and everything else that might participate in these orchestrated spaces.
This is where the Resource Description Framework (RDF) in
general and the Simple Knowledge Organization System (SKOS) language come in.
By binding sub assemblies to logical URLs, it is possible to address and describe the content and services through the
same technologies. SKOS builds on RDF allowing both the notion of categorization as well as the ability to mix in
arbitrary metadata and perhaps competing classification schemes. When grounded in a software infrastructure that
allows the registration and discovery of this metadata, all of the pieces are finally in place to achieve this supply
chain vision for SOA.
Describing Services with SKOS
Figure 1. Printing ServicesHierarchy: A sample service taxonomy for printing services.|
The goal of using these technologies is to describe and categorize services as quickly and easily as possible.
Languages such as the Web Ontology Language (OWL) provide the ability to model domains quite accurately, but the
skills and effort to do so remain outside the reach of most Enterprise developers for the near future. As discussed in
"Applying SKOS Concept Schemes",
SKOS is an attempt to allow simpler concept schemas (e.g., taxonomies, controlled vocabularies, etc.) to be used in
place of heavier weight ontologies. Modeling taxonomies is within the skill set of modern information architects,
software developers, and service-oriented architects. Figure 1
shows the represented hierarchy.
A PrintingService is a root service of a particular type that deals with services for
printing documents. Below that are the concepts of LaserPrintingService and
PlotterPrintingService; one for
conventional documents, another for large CAD/CAM, and perhaps architectural diagrams. There are two types of
LaserPrintingService concepts: ColorLaserPrintingService and
BWLaserPrintingService. This does not represent a likely decomposition of services in an organization, but is merely meant to be demonstrative of the kinds of taxonomic relationships between associated services.
Listing 1 shows a sample encoding of this hierarchy in SKOS.
There is a hierarchical relationship between these concepts. You can imagine wanting to query for all
PrintingServices or all LaserPrintingServices. This requires a selection of a concept and a traversal down the concept schema. Alternatively, you can imagine starting at a terminal node and wanting to find the path to the root service concept to find similar types of services. In the on-demand SOA orchestration world, you respond to what is available by presenting options to users. RDF alone is insufficient for walking these SKOS relationships. It allows straight graph pattern-matching queries; a different set of technologies is required to "figure things out" about the concepts in a taxonomy in SKOS.
OWL and RDFS Reasoners can perform inference and type entailment over knowledge bases expressed using constructs from those languages. By adopting a richer language than just RDF, it is possible to encode more information in fewer statements. Most RDF stores and platforms require some special handling to deal with SKOS data; but all the different languages that are based on RDF should be interoperable. This allows various categorization schemes and arbitrary metadata to describe the services in a SOA. You can query more realistic systems like this for all services of a certain type, or a certain version published in the last six months. You can also query the metadata for service definitions, input/output schema, etc. All of this infrastructure enables a rich, flexible supply chain SOA capable of growing more quickly than you would expect.