Thursday, May 28, 2009

Is it a repository or dumpster?

One of the SOA infrastructure components is the repository. It is a critical tool that enables discovery and reuse as well as playing a key role in SOA portfolio management. Unfortunately, a lot of clients don’t implement or utilize the repository properly. Often, this is due to a combination of poor planning and challenges in technology & process integration. Many customers end up using it effectively as a dumpster or shared drive. It is a fundamental issue with SOA adoption, as it retards adoption and value return or in some cases completely derails it.

During service analysis and design, service architects and interface developers use the repository to search for artifacts such as design documents, WSDLs, schemas, policies, SLAs, service contracts, etc or catalog new ones into it. An artifact may be used by different services (i.e. a logging or security policies). Or at a higher level, a common service (i.e.CreditInquiry, TaxCalculation) may be part of a composite service (i.e. PremiumCalculation). A minor change to a common artifact could adversely impact dependents and consumers.

SOA program managers extract a lot of information from the repository for service reporting (reuse, demand pipeline, impact analysis, etc). Reports provide visibility and control and enable SOA design time governance.

As demand for new artifacts are identified, the program manager or the service architect submits a registration request. The requests are often reviewed by a committee, before approved. Once the asset is implemented, reviewed and approved, publication requests are sent to the librarian for promotion.

In a typical repository, artifacts are filed under a project. Projects are filed under business units/departments. So, a repository brings an integrated view of all services and related artifacts as well as information that indicates ownership and usage.

The above is a typical highlevel SOA design approach. In this scenario, multiple roles are involved participating in different processes. There are touchpoints with design & construction tooling (i.e. development tools, testing tools, SCM, requirements management DB…) So, there is a set of requirements around how a solution is designed and delivered in the organization (process and policies). There is also a set of requirements around what integration requirements are needed (technology). The repository, but itself, doesn’t provide the solution out of the box. There needs to be requirements analysis, planning and design around implementing the repository in a way that aligns with the organization’s practices.

Here are some basic questions to consider:

  • Is there an SOA design & development process defined?
  • Is there an asset publication process? Has it been modeled right (i.e. quality gates and roles)? Is the process understood and followed by all parties? Do you measure and monitor the process?
  • Is there an asset specification template? What is the service naming convention and classification scheme?
  • What are the policies for asset registration & publication?
  • What are the policies for asset change management?
  • How is compliance checked/reported?
  • What are the requirments for supporting the organization (i.e. MNC, offshore, etc)? What would be the right topology and deployment model for the repository? Should you buy or build? What are the tradeoffs?

What is your experience with SOA repository?

No comments: