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
