TUCON: Merck’s SAP Integration Strategy

Daniel Freed of Merck discussed their SAP implementation, and how their integration strategy uses TIBCO to integrate with non-SAP systems. As with Connie Moore’s presentation this morning, the room was packed (I’m sitting on the floor and others standing around the perimeter of the room), and I have to believe that TIBCO completely underestimated attendees’ interest in BPM since we’re in a room that is half the size (or less) that for some of the other streams. Of course, this presentation is really about application integration rather than BPM…

They have four main integration scenarios:

  • Master data replication (since each system expects to maintain its own data, but SAP is typically the true master data source), both event-driven publish-subscribe and batch point-to-point.
  • Cross-system business process, using event-driven publish-subscribe and event-driven point-to-point.
  • Analytical extraction/consolidation with batch point-to-point from operational systems to the data warehouse.
  • Business to business, with event-driven point-to-point as well as event-driven publish-subscribe and batch point-to-point.

They have some basic principles for integration:

  • Architect for loosely coupled connectivity, in order to increase flexibility and improve BPM; the key implication is that they needed to move from point-to point integrations to hub-and-spoke architecture, publish from the source to all targets rather than chaining from one system to another, and use canonical data models.
  • Leverage industry standards and best practices
  • Build and use shared services
  • Architect for "real-time business" first
  • Proactively engage the business in considering new opportunities enabled by new integration capabilities
  • Architect to insulate Merck from external complexity
  • Design for end-to-end monitoring
  • Leverage integration technology to minimize application remediation (i.e., changes to SAP) required to support integration requirements

SAP, of course, isn’t just one monolithic system: Merck is using multiple SAP components (ECC, GTS, SCM, etc.) that have out-of-the-box integration provided by SAP through Process Integrator (PI), and Merck doesn’t plan to switch out PI for TIBCO. Instead, PI bridges to TIBCO’s bus, then all other applications (CRM, payroll, etc.) connect to TIBCO.

Gowri Chelliah of HCL (the TIBCO partner involved in the project) then discussed some of the common services that they developed for the Merck project, including auditing, error handling, cross-referencing, monitoring, and B2B services. He covered the error handling, monitoring, cross-reference and B2B services in more detail, showing the specific components, adapters and technologies used for each.

Freed came back up to discuss their key success factors:

  • Organizational
    • Creation of shared services
    • Leverage global sourcing model
  • Strategy
    • Integration strategy updated for SAP
    • Buy-in from business on integration strategy
  • Program management
    • High visibility into the development process
  • Process
    • Comprehensive on-boarding process for quick ramp-up
    • Factory approach to integration — de-skill certain tasks and roles to leverage less experienced and/or offshore resources
    • Thorough and well-documented unit testing
    • Blogs and wiki for knowledge dissemination and sharing within the team, since it was spread over 5 cities
  • Governance
    • Architecture team responsible for consistency and reuse
  • Architecture
    • Defined integration patterns and criteria for applicability
    • Enhanced common services and frameworks
    • Architecture defined to support multiple versions of services and canonical data mocdels
  • Implementation
    • Development templates for integration patterns
    • Canonical data models designed early

In short, they’ve done a pretty massive integration project with SAP at the heart of their systems, and use TIBCO (and its bridge to SAP’s PI) to move towards a primarily event-driven publish-subscribe integration with all other systems.

TUCON: Architect’s Guide to SOA and BPM

I enjoyed Paul Brown’s seminar in Toronto a few weeks back, so I attended his session today on planning and architecture for SOA and BPM: how to define the services that we need and rationalize our data architecture in the face of managing end-to-end processes that span functional silos? Although many organizations have systems within those functional silos, the lines of communication — both person-to-person and system-to-system — always cross those silos in any real business process.

A lot of new skills are required in order to adopt SOA and BPM across the enterprise, from high-level executive support to a worker-level understanding of how this changes their day-to-day work. To make all of this work, there needs to be a total architecture perspective, including business processes, people, information and systems all coalescing around a common purpose. Business needs to re-engage with IT — in many organizations, they’ve been scared away for a long time — in order to get that business-IT collaboration happening.

Brown covered some of the same ground about separating out services, processes and presentation on as he did in the seminar, which I won’t repeat here but recommend that you check out the link above for more details.

He went on to discuss the TIBCO BPM.SOA execution model. First, develop the execution strategy for the entire program:

  • Develop vision and program roadmap
  • Define and implement organization and governance
  • Define and implement technical infrastructure and standards

Then, move on to solutions and operations for each project:

  • Analyze process and develop project roadmap
  • Design, build and deploy business process
  • Operate the business

This last point highlights the importance of setting and measuring goals for the project; you don’t know whether your project was successful until it’s been in operation a while and some measurements have been taken.

He had some pointers for how to get started with BPM and SOA:

  • Focus on business processes first: they’re the source of business value, and the glue that binds the people and systems together.
  • Separate service access mediation (access control, security, routing, distribution) from services.
  • Acknowledge different types of processes, both unmanaged and managed/orchestrated.
  • Separate processes and presentation.
  • Embrace total architecture with a cross-functional architecture team

He finished up with some case studies of organizations that have taken an architectural approach to rolling out SOA and BPM, and how this has made IT departments much more responsive to new business requirements. Findings by one organization included that they wanted to have more IT involvement in business processes in order to better align the business processes with the underlying services. For services that will be used across multiple systems, it’s critical to have an enterprise architecture group review these for reusability.

His final summary: keep the business process focus as the source of business process; BPM and SOA provide opportunities for improving business process; and the major challenges are organizational, not technical.

Architecture & Process: Robert Pillar

The first breakout session of the day was on connecting BPM, SOA and EA for enterprise transformation, with Robert Pillar of Microsoft. He’s talking about how compliance is the key driver to the coalition of BPM, SOA and EA, but that the coalition starts with holistic collaboration. There are barriers to this:

  • Organizational barriers: IT organizations and silos between EA, SOA and BPM groups
  • Cultural barriers: lack of understanding the business value, lack of understanding the concepts, and old-style mentality
  • Political barriers: resistance to change
  • Collaboration barriers: resistance to meetings and collaboration

Risks and benefits must be measured.

At this point, someone in the audience spoke up and said “we understand all this, can you just skip ahead to any solutions to these issues that you have to present?” Incredibly rude, and really put the speaker on the spot, but he had a point.

He had a summary slide on why to choose SOA:

  • It offers a focus on business processes and goals: supports customer centric view of the business, allows design of solutions that keep requirement changes (agility) in mind
  • It offers an iterative and incremental approach following EA and BPM initiatives: make change happen over time, allow employees learn about the concept of services
  • It offers a means to reap the benefits of existing investments on technology: reuse IT resources, focus on business problems without being entangled in the technology

He sees EA and BPM as leading us to SOA, which is a valid point: if you do EA and BPM, you’ll definitely start to do SOA. However, I see many organizations starting with SOA in the absence of either EA or BPM.

Architecture & Process: Woody Woods

There’s one huge problem with this conference: too many interesting sessions going on simultaneously, so I’m sure that I’m missing something good no matter which I pick.

I finished the morning breakout sessions with Woody Woods of SI International discussing transitioning enterprise architectures to service-oriented architectures. He started out defining SOA, using the RUP definition: a conceptual description of the structure of a system in terms of its components and the services that they provide without regard for the underlying implementation of the components, services and connections between components). There are a number of reasons for implementing SOA, starting with the trend towards object oriented analysis and design, and including the loosely coupled nature that allows for easy interfaces between systems and between enterprises. Services are defined by two main standards (in the US, anyway): NCOW-RM, the DoD standard, and the OASIS reference model for SOA.

There are a number of steps in defining operational activities

  • Establish vision and mission
  • Determine enterprise boundaries
  • Identify enterprise use cases
  • Detail enterprise use cases to create an activity diagram and sequence diagram
  • Develop logical data model

The process for developing a service model, then, the following steps are taken (using RUP terminology):

  1. Identify the roles in a process.
  2. Identify the objects in a process, starting with triggers and results, and refining to include all objects, the initial actions and a complete action analysis, potentially creating a sequence diagram. Other types of process models could be used here instead, such as BPMN, although he didn’t mention that; they’re using Rational Rose so his talk is focused on RUP models.
  3. Identify boundary crossings, since every time an object crosses a boundary, it’s a potential service. By “boundary”, he means the boundaries between roles, that is, the lanes on a swimlane diagram; note that some boundary crossings can be ignored as artifacts of a two-dimensional modeling process, e.g., where an activity in lane 1 links to an activity in lane 3, the fact that lane 2 is in between them is irrelevant, and the boundary crossing is actually between lane 1 and 3.
  4. Identify potential services at each boundary crossing, which implies encapsulation of the functionality of that service within a role; the flip side of that is that it also implies a lack of visibility between the roles, although that’s inherent in object orientation. Each boundary crossing doesn’t necessarily form its own unique services, however; multiple boundary crossings may be combined into services (e.g., two different roles requesting information from a third role would use the same service, not two different services). In this sense, a service is not necessarily an automated or system service; it could be a business service based on a manual process.
  5. Identify interfaces. Once the potential services have been defined, those interfaces that occur between systems represent system interfaces, which can in turn be put into code. At this point, data interfaces can be defined between the two systems that specify the properties of the service.

In this context, he’s considering the RUP models to be the “enterprise architecture” that is being transitioned to a SOA, but this does provide a good methodology for working from a business process to the set of services that need to be developed in order to effectively implement the processes. I’ll be speaking on a similar topic — driving service definitions from business processes — next week at TUCON, and it was interesting to see how Woods is doing this using the RUP models.

TIBCO seminar slides

If you were interested in the TIBCO seminar that I attended last week, you can download Paul Brown’s slides (PDF, no registration required). I particularly like his graphics showing the current model for today’s business processes with EAI and ETL tying things together (slides 6-7), then the slides showing how SOA and BPM refine that structure (slides 8, 12,13, 14 and 15).

BPM/SOA events calendar reminder

As you can guess from my previous post, we’re in the middle of prime conference season, as everyone tries to get these in before the summer. That results in a lot of potential scheduling conflicts: today, I had a request to speak at a conference during a time that I’m already committed to another conference, which unfortunately I had to decline.

Although not a perfect solution, I created a public Google calendar last year in response to a very similar set of circumstances, and several other people are authors on the calendar including Todd Biske, who adds most of the SOA events. It’s already being used by some event organizers to check for potential conflicts, as well as serving as a resource for attendees to locate event information. I have it embedded on this page, but you can also access it directly, add it to your Google Calendars, or subscribe to the RSS feed.

This is not, of course, my personal calendar: if I attended every event on here, I would be both superhuman and divorced.

If you’re organizing an event, you might want to check the calendar for conflicts before selecting the date, then get your event posted on here by contacting me with the details or a request to become an author on the calendar.

If you’re looking for an event, subscribe to the calendar in Google Calendar, then use the "Search My Calendars" function there to locate a specific event.

BPEL for Java Developers Webinar

Active Endpoints is hosting a webinar this Thursday on BPEL Basics for Java Developers, featuring Ron Romano, their principal consulting architect. From their information:

A high-level overview of BPEL and its importance in a web-services environment is presented, along with a brief discussion of the basic BPEL activities and how they relate to Java concepts. The following topics will be covered:

  • Parsing the Language of SOA with Java as a guide
  • Breaking out of the VM: evolving from RPC to Web Services
  • BPEL Activities – Receive, Reply, Invoke
  • BPEL Facilities – Fault Handling and Compensation (“Undo”)

The VP of Marketing assures me that he was allowed only two slides at the end of the presentation, and that otherwise this is focused on the technical goodies.

You need to register in advance at the link above.

TIBCO seminar: Achieving Success with BPM and SOA

TIBCO is holding a series of seminars in various cities, and today they’re in Toronto, where I happen to be at home for a few weeks. Amazingly, there’s free wifi in the Park Hyatt meeting rooms, something that I never expected

We had a welcome from the regional VP, Craig Byar, and an overview by Rourke McNamara of SOA product marketing, but the key speaker was Paul Brown from the Global Architecture group. Actually, McNamara made a great point in his short presentation: organizations with an identified BPM center of excellence (CoE) reported five times greater ROI over those with no CoE or dedicated process team.

Today’s business processes involve many systems, and we’ve used EAI and ETL in the past in order to tie these systems together, but we’ve created a fragile mess of our systems and lost the focus on the business process. It’s hard to . SOA and BPM refine the traditional 3-tier layer of presentation, business logic and data by splitting the business logic layer into processes and services: effectively, BPM and SOA. The service layer can further be split into service operations (the actual functionality of the service) and service access mediation (finding the right service and authenticating access). He also splits the process layer can be split into hard-wired processes (the processes in legacy systems that can’t be changed, or unchangeable high-volume processes such as credit card processing), orchestrated processes (integration-centric processes facilitated by BPEL) and managed processes (BPM), although I’m not sure that I agree on the distinction between the latter two.

We need to separate processes from presentation; too often in the past we’ve embedded processes right in the presentation layer, and since we deliver functionality now through multiple presentation channels (web, desktop application, mobile, web service), the process needs to be in the layer below presentation so that a consistent business process is executed regardless of the presentation channel.

We have a disconnect between business and IT when it comes to developing new systems, and we need to first focus on business processes — the source of business value — to see how they bind together people and systems. There’s an expectation that systems will be developed faster, and this type of splitting of presentation, processes and services helps to facilitate that. However, there needs to be overall architectural guidance and governance for any development project so that things fit together: an architectural review of bot the business process and the systems somewhere between initial requirements and development. The challenge that I see in this model, however, is not to fall back into old-style waterfall development: instituting a requirements-architectural review-development cycle can tend to make the development process less iterative and agile.

There are three key leadership roles in any BPM project, immediately below the business executive sponsor: the project manager, the business process analyst/architect, and the systems architect. I have to say this is true of any business-facing development project, although the business process analyst/architect will be replaced with the particular application-specific analyst/architect role. Brown equates the CoE for a specific technology or application such as BPM, and an overall enterprise architecture team in terms of the mentoring and governance role that they provide. He had a number of case studies of BPM and SOA projects that showed significant ROI, with a BPM/SOA CoE being a key part of each of them.

We all ended up with a copy of Brown’s first book, Succeeding with SOA, and apparently I’ll be getting a copy of his hot-off-the-press second book, Implementing SOA, at TUCON later this month.

We had a quick demo of TIBCO’s process modeling environment, showing the different usages by a business analyst versus IT.

Mapping BPM Events

Coincidentally on the same day that Todd Biske and I start collaborating on the BPM, SOA and EA calendar that you can find on both our sites, I saw this amazing post (linked from the Google Operating System blog) showing how to map a Google calendar’s events on a Google map, with a bit of help from a simple Yahoo Pipe. The results, showing our events calendar, can be found immediately beneath the calendar.

The theory is that this should refresh from the pipe (and hence the calendar itself) every time that you visit the page — or, if you prefer, a link to a larger version of the map directly in Google Maps — although I haven’t tested that out.

If you’re an author on the BPM Google calendar, be sure to fill out the location field so that your event is displayed on the map.

Definitely the most fun that I had all day.

BPM Events calendar gains a new audience

Todd Biske, whose blog I read regularly, announced last week that he was going to publish a Google calendar of BPM, SOA and EA events, I invited him to join the one that I’ve been running for a few months. During the time that I’ve had the calendar active, I’ve added about 10 other authors to the calendar who can add events; these are typically people very active in the industry and have events to contribute. If you want to add an event, you can email to either Todd or me; if you think that you can make an ongoing contribution, then let us know and we’ll add you as an author.

You can view the calendar on my site here, or on Todd’s site here. If you have a blog on a related subject, feel free to embed it on your site as well. Good place to check first if you’re organizing an event and want to make sure that it won’t conflict with competing events.