Interview with the Book Authors: Brown, Laird, Gee, Mitra: SOA Governance

Posted by Boris Lublinsky on Mar 20, 2009

Sections

Enterprise Architecture

Topics

SOA ,

Governance

Tags

Business/IT Alignment

The book "SOA Governance: Achieving and Sustaining Business and IT Agility" by Clive Gee, William A. Brown, Robert G. Laird, Tilak Mitra provides a combination of thorough descriptions of SOA governance topics, work packages, which can be directly used for establishing and implementing a proposed governance model and a case study, showing how these approaches and work packages can be applied in real life.

InfoQ had the chance to interview the book authors.

InfoQ: It is a widespread belief that one of the main SOA advantages is reusability. Do you agree with this?

Book authors: We would agree that reuse is one of the advantages of SOA, but not necessarily the main one. Those who are IT centric may focus on reuse as a main advantage and build their business case for SOA on reuse only. Services that help for reuse tend to be IT common services such as editing services, logging services, security services and so forth. No doubt, this is useful, and we don’t mean to denigrate reuse.

In fact, the concept of reuse has been well understood and leveraged right from the day of object orientation (OO). In OO, the granularity of reuse was at the level of classes. In SOA one of its first class constructs is a service. A service is defined at a level of abstraction that is at a much higher (towards business alignment) level than that of objects and components. The ability to define services (business & IT) at a level that fosters business and IT agility is a fundamental and imperative training that every SOA architect must have mastered.

The ability to define a business service that can be realized through a composition of one or more IT services raises the level of abstraction of reuse - one of the main advantages of SOA. This advantage enables the business to define their enterprise operations in terms of business services; IT to define a set of IT services that may be used to realize the business services. This traceability between business services and IT services brings in the much needed business to IT alignment in an enterprise by fostering reuse at multiple levels in a software stack.

An even more important advantage of SOA, however, is business agility. This requires an organization to have a true partnership between the business and IT and have performed analysis on business goals, business processes, the decomposition to business services and the architectural building blocks that support business agility. This is hard work, and there are not yet many skilled practitioners.

InfoQ: Which tooling would you recommend to support governance processes outlined in your book?

Book authors: One major theme of the book is the establishment and management of a Service Factory to plan, define, design, build, test, and operate all services and automated business processes. Like any other manufacturing process, our service factory can benefit significantly from the use of appropriate automation and tooling. The sets of tools required for SOA governance implementation differ depending on the state of the service lifecycle:

• The most important capability for implementing governance is effective two-way communications. Any tool that can be used for that purpose, be it an intranet, 'brown bag’ meeting, collaborative messaging tool, email or one-on-one meeting can actively help implement governance.
• Having a standard, enterprise-wide business entity and messaging model is critical to developing enterprise-ready services. A common tool to version-manage and publish such models is a real asset. Where there are multiple physical representations of a single logical business entity, a data dictionary that describes in detail how to map between these separate representations is also essential.
• One inhibitor to reuse that we often see is the practice of recording business requirements solely within the documentation of individual IT projects, where it is often difficult or impossible for new projects to locate them. A common database or repository to version-manage and publish business requirements, business rules, terminology and compliance criteria, indexed by business entity and/or business process can provide a major boost to reusability, reducing both unnecessary duplication of effort and reducing the complexity of operational systems.
• There is a need to manage, publish and promote all technical requirements, such as Architectural Principles, Architectural Decisions, policies and standards, best practices, recommended design patterns, checklists and checklist guidance. This could be achieved either using a custom tool or simply as part of a well-managed enterprise intranet.
• Some SOA implementations we have seen use a model-driven design approach, where most of the analysis, design, and even testing is performed using graphical modeling tools, and where the actual source code is largely generated automatically, rather than being hand crafted. Since models are much easier to understand than source code, this helps reviewers to ensure that the design accurately meets business and technical requirements and that the code accurately reflects the design. There are some excellent commercial Service Development Toolkits (SDKs) currently available from IBM and other vendors that provide such modeling and code generation capabilities.
• In large organizations, some tooling support for managing the results of compliance reviews can help to minimize the overhead involved. Such tools could be as simple as the use of some generic personal productivity/reporting tools, although some products are starting to appear on market that specifically address policy compliance automation.
• As organizations create many services (say 50 or more) or start to make services available to third parties, a Service Catalog or Service Registry becomes increasingly essential. Ideally the service registry should be partitioned into two distinct sections, based on target audience:
  • For potential service consumers (e.g. internal departments, business partners or customers), details of which services are publicly available (including version details), how to become authorized to use them, and how, technically, to access them (e.g. the Web Services Description Language or WSDL that describes their interfaces), together with details of the terms and conditions of the Service Level Agreements (SLAs) that govern their use. This section of the catalog or registry should also contain details on proposed new services or service versions to obtain feedback on their content and value). This section should not contain any information on how services are physically implemented; one of the key features of SOA is that the implementation of any service can be changed any time provided that the 'contract’ of the service (i.e. the WSDL) remains honored. Naturally, access to each service description needs to be restricted to only those who might become potential consumers; some services will certainly be restricted to internal users only
  • For Service Developers, a much wider amount of content should be available, including service internals such as non-functional requirements, and detailed design. This section of the registry should also include some lower-level components that are not directly exposed as services, such as the individual fragments from which compound services are assembled
• A repository or set of repositories to contain physical assets such as source code and configuration data. The ability to recreate a specific physical configuration is critical when migrating a new service or system from testing to production, or when performing software maintenance. There is at least one publicly documented instance where a major U.S. corporation was taken over by a competitor, following the catastrophic collapse of their stock price after a failure to restore an earlier working configuration of a critical IT system for a week or so following an unsuccessful software upgrade
• To implement any practical level of service operational governance, it is essential to have tooling or infrastructure that monitors all aspects of service and automated process execution, including frequency of service use, version by version, service response time, identity of users, as well as error conditions and system capacity monitoring
• As the enterprise’s level of SOA maturity increases, there will be an ever-growing amount of data on the efficiency of service development and operations, the vitality of the SOA development and SOA governance efforts, and the business impact and value that SOA is having on the overall enterprise. There will be many reports to prepare, on monthly, quarterly, annually or on an on-demand basis. Good tooling can significantly improve the productivity of creating such reports; solutions we have seen range from simple business data analysis/report generation tools, to sophisticated 'dashboards’ that monitor service and process execution on a real-time basis.

InfoQ: One of the topics that is not emphasized in the book is the selection of appropriate services for a SOA solution implementation. How would you recommend approaching this issue and what are the prerequisites for this?

Book authors: Our experience has been that appropriate services can be selected via a top down planning process or may be created organically as the obvious need arises or due to legacy capabilities that can be turned into services. Both are useful. The top down case implies some sort of Enterprise Architecture capability (so I suppose having an EA group is a prerequisite) with the ability to partner with the business, analyze business processes and decompose processes to business services. These services tend to aid business agility. Growing service organically is much easier, as the service ideas will come from many sources. Governance needs to make sure that the proposed service follows all of the architectural standards, policies, and guidelines as governed in the service development control points.

InfoQ: Your book suggests to include a business sponsor as an integral part of the SOA factory. How would you suggest involving him?

Book authors: At the Telco I used to work at, I would schedule 1 hour brainstorming sessions once a month with each of the business vice-presidents. I never discussed SOA. I never used techie terms. The word 'architecture’ never passed my lips. Instead, we had a business discussion on their white board. We would talk about how various business services would be useful to them, helping them cut costs or drive product to market faster. These men and woman became quite passionate about 'their’ services and sponsored projects that helped their business. In effect, they became business sponsors for SOA without even knowing it! Talk business problems and business solutions and pretty soon you have business sponsors.

InfoQ: You seem to suggest that the only way to successfully implement SOA is through standardization of the service infrastructure support through ESB. Do you consider ESB to be a prerequisite for SOA implementation? Do you consider that an enterprise should have a single (federated) ESB for SOA implementation?

Book authors: While not an absolute pre-requisite for a successful SOA implementation, an Enterprise Service Bus (ESB) can certainly provide useful common technical infrastructure for service destination routing and data mediation, especially where there are a large number of services or the services to be implemented are very complex. For organizations where this is the case, we would certainly recommend using a commercial ESB rather than developing the same functionality in-house.

From a strictly governance perspective, an ESB simply provides a single point of contact for monitoring some service internal metrics, such as the number and scope of data mediations, and the relative frequency of any alternative routes or branches during service execution. While these are not exactly critical success factors for overall success with SOA, all such information is useful for obtaining maximum efficiency. As to the question of having a single federated ESB for SOA implementation, we would say that that depends on the individual organization. For example, one of our clients had multiple IT development organizations situated on three separate continents. It’s hard to see how they could practically implement and operate such a federated ESB, especially since most of their service executions were specific to a single geography.

• Older >