Saturday, November 9, 2013

SOA Governance Evaluation Guidelines

A pragmatic approach to assess and compare alternative solutions

Today I will try to outline the general principles which might be useful when selecting or architecting a comprehensive SOA Governance Solution. They have helped my team in the past and hopefully could be of some use to others as well.

Depth and Scope

By definition Service Oriented Architecture represents an array of business and technical strategies that the IT organization of an enterprise pursues to promote the exposure of business functionality within and between enterprises in a consistent, published, secure and contractual way. Yet most “SOA enabler” products including Governance Solutions are centered around Web Services, WSDL and UDDI – none of which are an intrinsic part of SOA. The reason for this is that due to its recent popularity, SOA has become a must have on all product spec sheets and architecture proposals, and the vendors are trying to limit the scope of SOA to match their offerings. The following table summarizes the common misconceptions about the substance, scope and depth of SOA and some of its aspects:
SOA ≠ Web Services or Any Other Technology
SOA ≠ Integration or OOP or MOM
Service Registry ≠ UDDI
Service Description ≠ WSDL
Service Monitoring and Control ≠ JMX
Service Management ≠ Component Deployment
Service Versioning ≠ Repository Source Control
Service Security ≠ SSL or XML Firewall or Security Appliance
Service Accountability ≠ System Logs
Service QOS ≠ HA Solutions
Service Metering, Chargeback ≠ Usage Logs
Service Routing ≠ BPEL or MOM or Java Code
Service Interoperability ≠ HTTP and SOAP
Service Composability, Orchestration ≠ Published WSDL
Service Discoverability, Dynamic Binding ≠ UDDI
Service Fault Handling & Analysis ≠ Java Exception Stack or WSDL Fault or System Logs
Service Throttling ≠ Firewall or JMS or Application Server Configuration
When considering investment in a SOA Governance Solution, it is important to make sure that prospective vendor or architecture team have not artificially narrowed the scope and thus future usability by repeating any of these mistakes.

Solution Drivers

The following drivers should be decisive in evaluating the architecture and functionality of a governance solution:
  1. Does it define a comprehensive Governance Information Model (GIM) which contains information required by all stakeholders and actors in the SOA landscape? Such service model should be radically different form the metadata-based approaches to SOA Governance adopted by the majority of existing solutions: it should define a strongly typed, easily validated view of the governance domain with enforced referential integrity, while the latter simply adorns the service WSDL. The SOA service model should be extendible with metadata to allow users capture additional service attributes, such as geography or pricing, which are pertinent to their business model, but the model itself should be defined as the first-rate data.
  2. Does it separate the views of a service from the Technical, Business and Governance domains and allowing them to be expressed and maintained independently?
  3. Does it provide support for all core SOA characteristics as well as any additional ones required by the enterprise without forcing the users to implement the characteristics that have no current business value in their domain?
  4. Does it maintain complete separation between service implementations and service aspects implementing the SOA characteristics, allowing incremental adoption and rollout of governance solutions?
  5. Does it facilitate the support of all existing and future SOA-related standards without forcing users to lock into any particular standards or profiles? Does it allow users to switch between competing standards or between proprietary and standard aspect implementations? In other words: can it be used as hedging against uncertainty in the SOA standards space?
  6. Does it support packaging policies into reusable Governance Contracts to prevent uncontrollable policy application and proliferation? Does it help to prevent unnecessary service proliferation by exposing the same service implementation to different constituencies with different contracts?
  7. Does it facilitate true service reusability through direct support for service virtualization and refinement? Service Refinement refers to the ability to slightly change the interface, vocabulary, granularity, semantics or behavior of enterprise services without changing the service implementation or affecting existing service consumers.
  8. Does it provide complete support for the Web Services technology stack (HTTP, SOAP, WSDL, UDDI), while allowing service producers and consumers to use the technologies of their choice when implementing and consuming enterprise services? Does it minimally support JMS, EJB and Java service bindings, and allow users to define and implement new binding types.
  9. Is it Aspect-based? Does it provide SOA adopters with the means to support all aspects of service governance without forcing them to accept any arbitrary decisions on which governance aspects they should implement or how these aspects should be implemented. Does it come out of the box with a reasonable governance model and a set of aspect implementations providing a useable starting point for recent adopters of SOA? At the same time is it equally applicable for advanced service-oriented enterprises with established governance model, standards and toolsets?
  10. Does it support aspect delegation: many of the service governance aspects including: security, versioning, monitoring and management, etc.; have existing packaged solutions broadly adopted in the prospective SOA marketplace? The examples of such solutions are Sun’s Access and Identity Managers and CA’s eTrust for security, IBM’s Tivoli and CA’s Unicenter for monitoring and management, CVS and ClearCase for version control. Does it allow users who have already adopted a packaged solution in one or more aspect spaces to delegate the implementation of these aspects to those solutions, provided that the solutions themselves support such delegation? At the same time it should not rely on any external packaged solutions, providing independent implementations for all core aspects.
  11. Are the services exposed through the solution consumable without any custom client code? Is it compatible with industry-standard tools like SoapScope? There is a contention between the need for interoperability and decoupling versus convenience and the need to hide complexities. Can the solution resolve this contention by offering service consumers a spectrum of options for invoking governed services? These options should include:
    • Access points, which allow service invocation without any client-side components, but require client implementation to manage the complexities of dealing with find-bind-execute cycle and compliance with the governance policies.
    • Client interfaces, which provide service-generic but client platform-specific solution components that insulate consumers from most of the complexities when invoking any exposed service.
    • Convenience APIs, which provide both service- and client platform-specific layer for zero-effort invocation of designated services.
  12. Does it manage the cost of compliance? To be able to satisfy all of the above drivers would require a solution of significant level of complexity - does it compromise overall viability of the SOA implementations it is designed to support? Specifically:
    • Does it introduce performance bottlenecks to underlying service implementations?
    • Does it introduce scalability bottlenecks to underlying service implementations?
    • Does it introduce a single point of failure or negatively affect the availability of underlying service implementations?
    • Does it introduce any additional vulnerabilities or negatively affect the security of underlying service implementations?
    • Does it negatively affect the testability of underlying service implementations?

No comments:

Post a Comment