Re: [soa-rm-ra] Governance Paper

[Ken Laskey <klaskey@mitre.org>]

If we go back to the August 17 email summarizing the RA ftf, it focuses on the general philosophy of what governance means in a SOA context and how it will likely evolve rather than just being mandated.  The current article then gets to some specifics that would hopefully be consistent with the philosophy.

A couple things to note:

- The functional view depends on a visible, high-level champion.  While this is useful, it is also brittle.  Unless the community sees value beyond the exhortations of the champion, the object of the cheering will fade as soon as the champion moves on.

- I usually feel that the idea of build time vs. runtime is over-emphasized in most cases (e.g. for discovery) but I agree with Anil's dividing the technical aspect this way.  Now the question is to what extent governance helps to define the framework vs. trying to lock in low-level specifics.  This will be very important, but I am not yet sure what we have useful to say about that.

- Much of the Five Views is what we moved to management instead of governance.  Recall from the summary email, "governance reflects what some authority wants to happen, e.g. policies, and management provides the details and mechanisms by which policy becomes reality".  A governance board may mandate policy but it is someone on the ground that makes it happen.

- A third aspect in the article goes untitled but is testing.  The "specification team" probably doesn't want to test every use but do we want to take a position on the spec team/service provider providing a test suite against which someone using the service can test their mechanisms for use?  Someone using a service will also have to devise and perform their own local tests.  Finally, there needs to be ongoing monitoring, possibly at the infrastructure level.  Does someone have responsibility for the testing section?

Ken

On Oct 7, 2006, at 5:24 PM, Danny Thornton wrote:

A minor nit about the wording in the article.  The

article implies if you use a hierarchical structure

for governance views then that is likely to result in

silo-based architecture.  The views in the article are

both hierarchical and horizontal in nature (Strategy

over Business, Function, Infrastructure, and

Application. Function to Application), a key point to

capture, as Anil pointed out, is the feed back loops

between the views.

The industry currently seems to be heavily focused on

governance and life cycle.  The RA committee is also

discussing governance in terms of conflict resolution

between services.  We currently have management

activities separate from governance and the way

management is captured in the RA it makes sense to me

to do it that way.  If I were to try and add conflict

resolution between services to the governance model

presented in the paper, it would not have a distinct

spot.  I think Anil alluded to this with the

Operational/Run-Time Governance break out from the

Technical Governance view.

Danny

--- "John, Anil" <Anil.John@jhuapl.edu> wrote:

Michael,

This was interesting reading. Thank You.

They divide governance into two large buckets:

Functional governance which seems to tie in with

providing motivators

and de-motivators at the organizational level to

moving to a SOA

approach. This is where active support from

management etc.. play.

What is missing seems to be the information on the

feedback loop on how

these were implemented. i.e. Once those "..rules and

guidelines...."

Have been defined, how did you handle non-compliance

etc.?  Also, how

did they bridge Functional and Technical Governance?

Did the folks from

on high, authorize a central team to be the

"governance police?" (which

is what seems to be implied)

Technical governance which is related to the

development of a "..set of

architectural rules and guidelines together with

technical

prescriptions" on how the technology implementation

is done.

I personally would actually break down the Technical

Governance aspects

of it further into Operational/Run-Time Governance

and Design-Time

Governance aspects as the manner in which you would

handle and implement

them would be a bit different.. There is the

opportunity to automate (at

least the monitoring aspects) of the former, while

the latter is more of

a process based approach.

In the paper, they also espouse a way of looking at

the information

system according to 5 views:

Strategy view. This view describes the strategic

objectives of the

enterprise in term of business and in term of its

information system.

All the decisions made in the other views must be

related to one of the

objectives in the strategy view.

Business view describes the business processes and

business activities,

independently from the internal structure of

information system. This is

the view in which live the end users.

Functional view aims at structuring the information

system into

processes and business services. This view, which is

not meant to be

seen by end users, is essential for the efficiency

and the

maintainability of the information system. This view

should be as

independent as possible from the technology and

technical aspects of the

IT system. This is the view in which live the

functional architects

Application view aims at implementing the functional

specification into

an IT system. This view deals with application

modules and technology

choices. This is the view in which live the

technical architects and the

application developers

Infrastructure view contains the description of the

IT physical

infrastructure of the company (computers, networks,

...). This is the

view in which live the IT operations

.. which may tie into the views and viewpoint

discussion here.

Some interesting comments:

"moving from a vertical silo-based architecture to a

layered service

oriented architecture proved to be a complete mental

shift for most

participants of the program. If not taken care of,

it quickly leads to

confusion and potentially blockage of the program

(when you ear

end-users arguing about the format of the WSDL, then

you know that

you'll soon be in trouble)"

"We found out that it is important to avoid

hierarchical relationships

between the objects in the views, because such

relationships tend either

to recreate the silo-based architecture or to lead

to a confusion of the

roles between the actors (e.g. end-users arguing

about SOAP

encoding rules)"

Regards,

- Anil

________________________________

From: Michael Stiefel

[mailto:development@reliablesoftware.com] 

Sent: Wednesday, October 04, 2006 9:01 PM

To: soa-rm-ra@lists.oasis-open.org

Subject: [soa-rm-ra] Governance Paper

In my reading I came across the following short

paper on governance

models. 

It stated that it was based on the work done in

France on the Copernic

system. I do not know if anybody  is familiar with

it, but the paper

states that  it was "a complete refactoring of the

entire fiscal IT

system: 9 years duration, more than 1000 people with

70 projects and a

budget of 900 million Euros". It claimed that it was

"probably to date

the largest IT system fully implemented according to

the SOA paradigm. 

Any project that big should have some interesting

ideas on governance.

Michael

__________________________________________________

Do You Yahoo!?

Tired of spam?  Yahoo! Mail has the best spam protection around 

http://mail.yahoo.com 

------------------------------------------------------------------------------------------

Ken Laskey

MITRE Corporation, M/S H305     phone:  703-983-7934

7515 Colshire Drive                        fax:        703-983-1379

McLean VA 22102-7508

smime.p7s