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" <> 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:]
Sent: Wednesday, October 04, 2006 9:01 PM
To:
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
