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?

Socializing service reuse

SOA repository is the technology enabler for asset reuse. During design time, project teams search the repository for scheduled and published services to determine whether any asset can be integrated and assembled into their solution without building it.

Several scenarios may happen:

1 - The service is found in the repository and can be readily reused
2 - The service is found in the repository, but the consumer has to wait until it is available
3 - The service is found in the repository, but requires change (minor -> major)
4 - The service is available, registered, but couldn't be found in the repository
5 - The service is available, but not registered so it couldn't be found
...

There are different solutions to the problems above. At the end, it is the job of the SOA CoE to socialize reuse and promote services. The rate and level of reuse is a function of organizational complexities (i.e. culture, CoE model, process) as well as development approach (prescriptive and formal unified process vs. highly interactive agile methods).

Also, as teams collaborate on service production and consumption, they engage in frequent social interactions. Repository vendors should look beyond basic collaboration support (i.e. notification, workflow) and integrate social computing capabilities in their solutions to generate excitement and overall vitality, enhance productivity & knowledge which should facilitate and contribute to more effective reuse.