5.1 - 5.5
1=Never
5=Consistently or well-established
|
5.1 Architectural reviews? |
5.2 SOA included in reviews? |
5.3 Processes for publishing contracts? |
5.4 Change management process for contracts? |
5.5 A central repository for service contracts? |
|---|---|---|---|---|---|
UBC |
2 |
2 |
1 |
1 |
N |
Michigan |
2 |
2 |
1 |
1 |
N |
Cornell |
2 |
1 |
2 |
1 |
N |
Georgetown |
2 |
1 |
1 |
1 |
N |
Ohio State |
2 |
|
2 |
2 |
N |
UMUC |
2 |
2 |
1 |
2 |
N |
UofT |
2 |
2 |
2 |
2 |
Y |
UW |
3 |
4 |
4 |
3 |
Y |
UW-Madison |
2 |
3 |
1 |
2 |
N |
UC-Irvine |
3 |
2 |
2 |
2 |
N |
Colorado |
2 |
2 |
1 |
2 |
N |
Indiana |
2 |
2 |
1 |
2 |
Y |
5.6
Additional information on the management of service contracts
Michigan: We are currently working on a Directory of API project that will create a repository of web services and their meta data, which will include service level expectations.
Cornell: There is a Confluence wiki listing some of the service contracts. As we start up Oracle SOA Suite, Oracle Enterprise Repository and Oracle Service Registry, we will attempt to leverage the more-or-less automated features of these tools to improve the situation.
Ohio State
Currently maintaining spreadsheet/DB table. Also researching/evaluating Service Registry/Repository software
UofT
We are creating an initial "message-flow" (Student Contact Information) to test the SOA governance process. The next step is to convert the message-flow to a web service. The next service will test the collaboration with one or two of the divisions in designing and building a new service (probably enrolment details for a student in the current session).
Colorado
Just beginning to clearly define service contracts - clearly a goal, but pretty early in the process
Indiana
Question 5.5 is kind of a "maybe". Our repository of service contracts is defined in WSDL form and is included in the Kuali Service Bus registry.
Cardiff
Characteristics of the interface to the Service. There may be more than one of these for any given Service.
- Version
- The version number of the interface, used to ensure the stability of the interface.
- Endpoint(s)
- Where the Service is exposed, e.g. the URL of the Service endpoint.
- The protocol used by the endpoint, e.g. SOAP or REST.
- The data-interchange format used by the endpoint, e.g. XML or JSON.
- Any Service Level Agreements for this endpoint, for example:
- Availability - any uptime guarantee or outage window
- Timeliness - how "fresh" the data available via this endpoint is
- Stability - this is a general control on whether the interface should be considered reliable or not; developers should undertake a Contract with the Service provider before consuming an interface that is not Committed. Categories likely to be:
- Committed - the interface will not change across system developments or upgrades
- Uncommitted/External - the interface is under internal development or is controlled by third parties (for example, an out-of-the-box Blackboard Service)
- Not an Interface - this interface should not be used.
- Data Classification - a general control on what level of protection the data available via this Service is subject to. The target way to do this may be to have this enforced by an ESB, but this may not be achievable in the short term. Categories may be:
- Public
- Mixed
- Private
Washington
Non WSDL (eg machine discover-able)
UW-Madison
Beachheads and the snipers are fierce
5.7
Has SOA changed your IT governance? If so, how?
UBC
No.
Michigan
n/a
Cornell
Not yet.
Georgetown
Broadly speaking, an increase in the number of services that need to be integrated and tracked has forced reactive improvements in change management, business continuity planning, and portfolio management.
Ohio
Just starting to impact or influence. We just started governance activity this year (2012)
UMUC
n/a
UofT
Yes. While establishing a process for SOA governance, we realized that some of our IT governance processes needed to be modified, in particular with services that impacted multiple departments with the central IT division, and IT departments within the divisions.
A new committee is being established to manage the lifecycle of the services. This committee is made up of the business users - people that are owners of the services. Some services are ""enterprise"" in that they are not really owned by any particular registrar or business owner, and therefore have to be ""owned"" by a central entity (e.g. VP of Operations - delegated to one of the registrars). We'll have to see how this committee functions...it hasn't met yet.
Washington
Yes: has made us more aware of the need to communicate between silos
UW-Madison
It has informed it. It has pointed out possible directions
Colorado
Not yet
Indiana
Not very much, we don't have governance bodies who are responsible for vetting changes to our service contracts. Most of that is handled adhoc by the technical teams.
Overview
Content Tools