OASIS Open

FAQ

1. What is the rationale behind this standardization effort? What is the motivation of the sponsors/authors?
   
   As more organizations move to adopt Service Oriented Architectures, there is an increasing demand for functional descriptions and working examples of SOA. These functional descriptions and working examples (Blueprints and Implementations) can form the basis for a community of best practice-so implementers can gain insight into the best (and worst) practices associated with specific solutions to well-defined SOA problems.
   
   To gain a better understanding of the historical motivations, please refer to the next question.

2. What is the history of this effort?
   
   The original SOA Blueprint was developed by The Middleware Company along with a large panel of experts from the business user, software vendor, and industry analyst communities. This group developed and provided feedback for this specification. The original intent was to create a standard "sample application" for SOA in order to foster understanding and adoption in the industry.
   
   The original blueprint scenario focused on a company called "Generico", which is a fictitious company. The "Generico Blueprint" consisted of a set of Enterprise applications integrated in a portal framework. These applications included Human Resources applications and employee self service applications all with integrated security and identity management.
   
   This "Generico Blueprint" will be contributed to OASIS to form the first blueprint for consideration and standardization by the Technical Committee.
   
   More about this original "Generico" Blueprint can be found here: http://www.soacenter.com

3. What is the scope of this effort? What is explicitly out of the scope and why?
   
   This effort is designed to maintain, develop and publish "blueprints". In addition, the committee will encourage and support implementations of the blueprints. In order to understand the scope, it is essential to understand the nature of a blueprint as defined by the committee.
   
   An adoption blueprint will provide a (a) business problem statement, (b) a set of business requirements, and (c) a normative set of functions to be fulfilled, all on a vendor-neutral basis. These blueprints will have several additional key properties. Firstly, a blueprint must be implementable. Secondly, a blueprint must be useful. Since "useful" is a highly subjective term, the intent is to drive the creation of additional blueprints based on the demand by end-user organizations.
   
   The intention of the OASIS SOA Adoption Blueprints Technical Committee is to develop blueprints which are functional specifications. It is explicitly out of scope for the Technical Committee itself to develop software implementations of the blueprints. It is intended for external organizations to develop implementations which meet the blueprints requirements, as a way of demonstrating capability to meet those business needs.
   
   The Technical Committee will however, review and accept donations of implementations to blueprints should that be deemed helpful to the goals of fostering understanding and adoption of Service Oriented Architecture. However, this would only be done in a vendor-neutral way. A more typical approach would be for the Technical Committee to hyperlink or reference vendor implementations externally.
   
   The Committee will not develop any new Web services standards, , although it may provide input to other standards Committees as well as recommend certain standards as suitable for specific functional requirements.

4. Are there existing comparable or overlapping standards, or comparable standardization efforts currently under way (inside or outside OASIS)? How does the work of this Technical Committee relate to these? What distinguishes this TC from similar work? How do the differences add value?
   
   This work relates most significantly to that of the OASIS SOA Reference Model Technical Committee; however, the OASIS Adoption Blueprints Technical Committee is focused on developing implementable working examples, which is distinct from the development of reference models and reference architectures.
   
   In general, blueprints will be more concrete and less generalizable than reference models and reference architectures.
   
   The OASIS SOA Adoption Blueprints Technical Committee intends to refer to the SOA Reference Model whenever appropriate-though much of the blueprints work will be functional in nature and may not maintain the conceptual integrity needed at the level of a reference model. From the blueprints perspective: "if it barks like a dog, it's a dog."

5. Is the product of this Technical Committee intended to be used in conjunction with other standards or complementary technologies? What are these? How does this work relate to these? (Is the usage of these complements mandatory? optional? restricted or profiled?)
   
   One of the most frequently used technologies for SOA is Web services. The SOA Adoption Blueprints will explicitly name sets of standards in business cases that require them, including requirements such as vendor neutrality and interoperability. These standards may or may not include sets of Web services or other standards. These choices will be driven by the business and functional requirements of the blueprint scenario.

6. Can you give some example of concrete benefits from standardizing the specifications from this TC?

   Benefits from standard blueprints fit the following categories:

   1. Gain and share expertise via communities of best practice: organizations implementing SOA will have a vendor neutral context to interact with like-minded experts. These communities will be able to share design patterns and anti-patterns and decrease the risk inherent in implementing new technologies. These include functional best practices (what to do) as well as implementation best practices (how to do it).
      
      
   2. Decrease adoption risk via improved supplier selection: a blueprint implementation provides the clearest and best proof that a vendor meets the business requirements. In that sense, a blueprint specification is like a Request For Proposals (RFP) document, while a blueprint implementation is like a Proof Of Concept (POC) project. Not only will this ensure that supplier capabilities meet business requirements, but will enable healthy comparisons between different implementations.
      
      

   Standardization increases the benefits listed above by elminating fragmentation and maximizing the size of the relevant communities. It also creates the strongest incentive for vendors to produce implementations because of the ability to address multiple customers with a single proof-of-concept application.

7. Is it anticipated that TC deliverables will be broadly used, deployed, and/or implemented? Or are the deliverables intended for a narrow audience, possibly including only the TC membership?
   
   The blueprints are intended to be broadly used to gain valuable SOA adoption expertise as well as to select technologies and vendors for implementation. Thus end-user organizations are expected to consume the blueprints and implementations.
   
   The blueprints are intended to be implemented by technology suppliers, which are a smaller community than the end users...

8. Do you see factors that should help a broad acceptance and deployment of the specifications from this TC? Any factors that may potentially hinder a broad acceptance and deployment?
   
   The key factor which should help acceptance is the demand for supplier-neutral information about SOA. In addition, unlike many products of standards bodies, the blueprints should have a very functional focus. This means that the documents will be easily understood by business users and well-informed laypersons. This will expand the acceptance and deployment of these standards.
   
   Suppliers and vendors are busy people and may be disinclined to develop software just to show competence in a functional area. This could hinder the adoption of the blueprints. However, the presence of significant numbers of end-user customers of these vendors should mitigate this adoption risk. For example, the "Generico" blueprint gained the support of dozens of vendors and has been implemented by the top companies in the software industry.

9. Regarding the adoption of this specification(s) by a vendor for its products: is this a decision that vendor companies can make individually, or are the interoperability aspects important enough to require industry-wide, coordinated adoption?
   
   Unlike many "typical" standards, these blueprints can be taken on a case-by-case basis. Some blueprints may have cross-industry implications while others may be more verticalized or specialized.