In terms of activities:

Artifact Analysis - although understanding dependencies is important, a more indepth form of analysis would be impact analysis, so for certain types of artifact we may want to understand the changes that have occurred between versions (possible in different lifecycle stages), to see whether they will potentially have an impact on service clients.

Repository Management - an important area from a governance perspective would be understanding responsibility. When artifacts are pushed to the repository, they will initially not have any concept of ownership, so it would be good if (a) an organisational structure could easily be managed in the repo/UI and (b) artifacts could be associated with different organisations (if external) or teams (if internal) to understand who owns the artifact, and contact details etc for support or SLA issues.

Another requirement in this area maybe dependency maintenance - the initial upload of a service artifact may result in dependencies being established automatically, however this may not always be the case, and definitely not when we get into SOA Modelling where service candidates and their dependencies will need to be manually created.

Repository Browsing

I think the most obvious requirement is the ability to browse the S-RAMP repository.  This includes simple navigation through the artifacts in the repository, along with more advanced searching/filtering.  I can imagine an initial implementation that works like http://search.maven.org/.

Features

• Hierarchical browsing of S-RAMP tree (e.g. http://search.maven.org/#browse)
• Searching of the S-RAMP repository (e.g. http://search.maven.org/#search)
• Download binary artifact content

 

I don't believe that hiearchical browsing of S-RAMP will effective. First of all, there isn't much hierarchy in an S-RAMP repository, and what hierarchy exists is largely a categorization by type: all the XSDs are under "xsd", all the WSDLs are under "wsdl". Instead, S-RAMP allows each artifact to be tagged (using an OWL-Lite ontology to define the tags).

IMO, the best approach to enable users to find things within the repository is to use a filtering mechanism. Sure, there should be some filters that are predefined. Perhaps parts of the UI can even be designed to make the user think they're using a hiearchy and navigating (though I'd prefer to never give the users this artificial mental model). But perhaps the best reason is that these filters can be defined/added by extensions so that the UI can be extended for data governance, resource governance, document governance, etc., and no just for SOA Governance.

I have a great example of an application that never uses navigation: iTunes. Everything you do is by filtering or searching. This kind of UI paradigm is fantstic when something doesn't belong in only one place but instead belongs in multiple places. And this is exactly what we have with S-RAMP: artifacts don't belong to a single hierarchy, but instead can belong to multiple things based upon tags.

Repository Management

If the Repository Browsing activity above is focused primarily on finding artifacts, there should also be a part of the UI that is responsible for adding and updating artifacts.

• Add (upload) new artifacts to the repository
• Update repository artifacts
• Delete repository artifacts

Isn't this more about managing artifacts rather than repositories? Perhaps "Artifact Management" might be a more appropriate term.

Of course, that begs the question:  who are the users?

 

Are there multiple groups/types of users?  Does the UI for browsing the repository need to be different depending on the group/type the user is in?  If so, can the user be in multiple groups/types?  Can they switch their current "role" to get a different browsing style?

 

Perhaps that's going too far - there can be a single browser based on filtering/searching that is flexible and natural enough to accomodate the needs of all groups.  But it would still be helpful if we enumerated the different types of users so we can make sure the browser is useful for them all.

I'd think that at a minimum the results will take into account the roles/privileges (so that users only see the information they're allowed to see). But I can definitely see that the UI would reflect the capability given the user's capabilities (based upon roles/groups). For example, if you don't have privilge to upload new artifacts, the UI would never present that option. Or, if a user can only govern SOA artifacts (and not data, rules, or resource artifacts) then perhaps the UI would not include such pre-defined filters (e.g., predefined 'smart search').

Consider this example: let's imagine a governance repository capable of governing SOA and data-oriented artifacts. A user logs in and only has the ability to govern SOA artifacts and cannot even read the data artifacts. In this case, I'd think the UI would present a way for the user to click on "WSDLs" and "XSDs" (or perhaps just "Web Services"), but would not present any of the data-oriented filters (like "DDLs" or "Databases"). (Note, I'm expressly using in this example the term "SOA" to apply to web-services and not data services.)

Does that help at all?

Yes I think that matches up with what I was getting at - the structure of the UI is common regardless of the logged-in user's role.  However, the specific data they see and even the specific buttons they can click on are determined by their role.

 

That seems better than trying to figure out a way to change the actual structure of the UI based on the user's role (in other words the *layout* of the UI vs. just hiding/showing data and functionality).

I agree.