RE: [soa-rm-ra] Governance Paper

[Danny Thornton <danny_thornton2@yahoo.com>]

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