BPM Project meetings

OLE Project Meeting on BPM - Day 2 - Nov. 7, 2008

The group continued its meeting at Rutgers University. Notes from today’s activities follow.

Review of yesterday’s key topics

Important to meet with the people who really understand the workflows and interview and/or observe them. Our regional workshops and work back at our home institutions will help with this. Our trainer calls these meetings Discovery Workshops. We’re calling them Library workflow analysis workshops.

Roadblocks to success with developing models:

- how much detail to describe (option: focus on the most common scenarios, not every possible scenario)

- experts can be so committed to every detail that it is hard for them to step back and describe the process

- process model does not clearly define the beginning and end point

- process metrics are not defined; makes it hard to know how to optimize without that info

We discussed ways to take into account that our new OLE framework will have to inter-operate with legacy systems that are not SOA.

Engage owners of other business systems at the stage where we are developing the application service layer.

Process improvement planning: After modeling how things are done now, we move to thinking about ways to optimize processes. Eventually we need to model the new processes. Create 3-5 models of alternative ways of doing things and run through them to see which would actually be best.

We don’t just want to optimize old processes. We also want to consider new processes that could be beneficial.

SOAD – Service Oriented Analysis and Design has 4 stages:

Stage 1 – requirements gathering and process modeling

Stage 2 – service identification and interface design

Stage 3 – Service design and implementation (existing services, 3^rd party services or new ones we build)

Stage 4 – Process implementation

Our design project is focused primarily on stages 1 & 2

SOA governance:

Governance is mainly like putting bumpers in a bowling alley – reduces risks, doesn’t guarantee total success but increases likelihood

You need governance more in the beginning, but less over time as your processes become established.

Some of our concerns: change management, sustainability over time

Design time, change time, run time

Comment: Things like Google and Flickr do improvements incrementally; they don’t release new versions that require migration, upgrades, etc. SOA allows more possibility for flexibility and changing one segment without requiring upgrade of whole system

One of our working groups will be doing outreach to other open sources, SOA projects so we can learn from their experiences with governance issues

We will need closer relationships with our IT organizations, if we truly want to integrate better with the infrastructure. Need to convey that we want to drive toward becoming part of the enterprise rather than just deploying our own stand alone system.

OASIS Reference group has some standard terminology, etc. that could be helpful in establishing governance.

Start light with governance – some standards, etc. – and add as needed as you go. Start small and grown incrementally. But get governance growing from the start, rather than having it come in as a “heavy” later on.

Need both business stakeholders and IT involvement

Champions are crucial – energetic, persuasive change agents

Every service needs to be owned by someone for accountability

Every service needs policies that define how that service can be used, e.g., “financial data must be encrypted,” or “reject requests that have P.O. Addresses”

Managing individual services is fine, but better to manage the whole portfolio of services

Common vocabulary helps with governance

“A documented governance lifecycle is golden, but an automatically enforced governance lifecycle is divine.”

Better to govern by consent rather than by force.

We took a break for a frog-free lunch.

SOAD:

We discussed key concepts in SOAD

We reviewed the four stages of SOAD

Regional Workshops on BPM - Planning

Jean discussed how we will organize our regional design workshops and reviewed the tentative outline for those workshops.

We had a lively discussion about our goals for these workshops, how much can reasonably be accomplished in one or two days, and how we will follow up to these workshops.

We recognize that we will probably need to have additional workshops later on in the project to follow up on the work started at these events.

Working Group planning

We then discussed establishing a number of working groups which will focus on different areas of our project and will offer opportunities for other libraries to be involved in the project.

Share This