EA Voices

Just recently, I was asked to provide some advice to a customer on how to adopt SOA Governance, specifically the Oracle Enterprise Repository (OER), in a step-wise and rational way.  It seemed like sage enough advice to publish here

Here is what they were trying to do which is similar to what other customers are doing:

• Establish a single source of truth in a SOA Repository
• Single repository supporting on-shore / off-shore distributed teams
• Manage service artifacts (i.e. projects, service design documents, policy definition…)
• Enables SOA program managers manage service portfolio and service demands
• Enables SOA program managers with related reports (i.e. demand, reuse, compliance & exceptions, dependency/impact analysis, …)

So it can be successful – but you don’t want to boil the Governance Ocean – at least not all at once.  In a word, I’d advise getting a firm understanding on which services you want to govern (probably not all of them) and the types of things you want Governance to do for you. Once you have that, you can move forwards in a stepwise approach that reduces the effort AND complication.  Realize that installing OER is only a small part of the puzzle.  You need to have the right Org structure (official or unofficial) in place and the right incentives and rewards to help motivate people to “do the right thing” such as to reuse services instead of writing their own.  Then you need the right processes to for people to follow.  It’s the notion that:  

Let’s say there are 50 key services to manage –  for discussion purposes.  Here is what I’d do at a super high level:

• Add Projects, Policies, Classifications Asset Types as needed (JUDISIOUSLY – keep it simple at first)
• Add users in different roles
• Get your top 50 key existing web services in OER using the Harvester if possible.  Otherwise just take some time to add them manually.  Make sure these are the relatively static PROXY services from OSB.
• Be sure to assign one or more people to OSR as administrators/architects to help keep things in order
• Add the correct lifecycle stage to them
• Add the right classifications/taxonomy to them
• Add documentation such that developers know how to use the service (i.e. can download a doc or visio or whatever that explains it)
• Add any and all XSD, WSDL and other files that people would need to download to actually use service
• Add a section to the OER home page that explains to users about the WL Gore SOA program, schedules and contacts – make it a place people go for some critical PROGRAM-level information – SELL what you are doing here…
• Get developers used to using the tool through an in-house training
• Use the reports to get a management view into the SOA program and help fund/support what you are doing
• Then – start entering future state services to track as they go from inception to deployment in the life-cycle

Things that add complexity that you can add later IF they add value to what you are trying to do:

• Install OSR / set up
• Enable publishing to OSR
• Set up harvesting of SOA/BPEL projects
• Set up/enable automated approval workflows
• Synch up performance metrics from OSB or OEM back into OER
• Assign CAS (custom access settings) settings to individual assets

And so on.  But add these later after the basics are down.

So – I hope this helps anyone else who wants to begin a SOA Governance effort using OER (with OSR, OSB and OEM as secondary stages after initial success).