Fully agree, but I think the problem we are having now is on explicitly finding methodology to connect/merge concepts from BPM and SOA initiatives. We were faced with the same problem and came up with a development model linking FR, NFR, and architecture and reviews with concrete review points stating explicitly what was necessary to be reviewed in each phase. The key was on reviewing the "right" elements rather than just conducting a review.
IMO, we are all beginning to see the problems and into providing the solution to them. :-) H.Ozawa --- In [email protected], Gervas Douglas <gervas.doug...@...> wrote: > > <<The combination of Business Process Management (BPM) and > Service-Oriented Architecture (SOA) has been the subject of a great many > magazine column inches and conversations in the past couple of years. > Most commonly, the relationship is seen primarily as one of technical > complements -- where BPM is seen as a way to make it easier to create > composite applications from services, and SOA is seen as a way to make > it easier to integrate automated processes with existing applications, > systems and data sources. However this is only one small part of the > picture, and it forces both BPM and SOA into playing purely technical, > application development related roles. > > */How did we get here?/* > It's important to see how we got to where we are today -- where most > people think of BPM and SOA primarily as complementary technology-driven > concepts. There are three factors that have conspired to push the BPM + > SOA equation into industry consciousness, and all of them have been > driven by IT suppliers: > > 1. *The adoption of BPEL within mainstream software products.* Through > 2004-05, the suppliers selling new middleware products aimed at > customers pursuing SOA initiatives started to offer orchestration > engines that could be used to wire together Web services to create > multi-step logic flows spanning multiple external services. These > engines implemented a standard called BPEL, or Business Process > Execution Language to provide that orchestration. This overloaded use of > "Business Process" terminology caused many commentators to blend and > confuse the topics of SOA and BPM. > > 2. *Software suppliers with products that appealed to technology buyers, > looking for ways to sell to business leaders.* Many of these same > suppliers were motivated to perpetuate any confusion in the market, > because they were keen to find ways to sell their products not only to > their traditional technology buyer audiences (Architects, Project > Managers, etc) but also to business buyers. Branding their new > technology capabilities as "BPM" was seen as a great way to get a foot > in the door, because BPM had already gained a foothold as a line of > business investment for many large organisations. > > 3. *BPM technology products making use of Web services.* At the same > time, a group of startup software suppliers was selling a new type of > software platform built specially for BPM initiatives, which came to be > known as the Business Process Management System (BPMS) -- designed to > not only help organisations model processes, but also translate these > models into working systems that could then be easily monitored and > optimised in a "closed-loop" fashion. These suppliers entered the market > just as interest in SOA was spreading rapidly, and as the initial Web > services technical standards work in the SOA area was starting to become > widely recognised. It made sense for these vendors to piggy-back on the > new Web services protocols as a way to make their products "open" for > customers to integrate new automated processes with existing back-end > applications, systems and data sources. > > */BPM and SOA: ships that pass in the night/* > In fact, though, what's interesting is that when we interview managers > from both business and IT departments in an organisation we commonly see > a very different picture which can be summed up as follows: > > * *SOA is IT-driven.* From the perspective of SOA, BPM is seen > primarily as a separate modelling and analysis exercise carried > out by business analysts that has little direct impact on the way > that things get done in practice. > * *BPM is business-driven.* From the perspective of BPM, if SOA is > understood at all it is seen as a small part of the technical > implementation landscape for processes that IT staff will "figure > out". > > */Missed opportunities/* > At first glance it might look like there's nothing wrong with having BPM > and SOA initiatives that are disconnected in this way. However there are > negative implications for both BPM and SOA initiatives in situations > like this, particularly for organisations that aspire to implement BPM > and/or SOA more broadly than across just one or two projects. Here are > three examples: > > * *Failure to leverage "integration services" effectively in BPM > implementations.* One of the supposed benefits of using Web > services comes from the opportunity for service reuse. But if > integration services in BPM initiatives are being specified and > created purely within the context of individual process > implementations, without any architectural (i.e. cross-project) > oversight, there's no guarantee that the resulting services will > be reusable in any real-world sense. SOA, done right, will improve > consistency and reusability of integration services across BPM > projects. > * *Failure to consider opportunities for process reuse.* It's > straightforward to take a process implementation and expose it to > the "outside world" as a reusable, standards-based software > service -- many BPM tools provide automated functionality to do > this for you. But (as is the case when considering integration > requirements) if you drive the creation of "process services" > solely from the BPM implementation environment without considering > the broader business/IT landscape, who's to say that the resulting > services will deliver optimal value? Any working SOA initiative > should be able to provide valuable input here. > * *Failure to capitalise on information architecture value.* Within > SOA implementations, the definition of "common information models" > is crucial to minimising the amount of translation of information > flows that has to be performed when services are being combined > and re-combined in different environments. If process > implementations are to be reused (as described above), the same > requirement holds within BPM initiatives, too. But apart from > that, it makes sense to enable individual BPM project teams to be > able to reuse or import standard information definitions. Defining > process information within the context of individual projects is > fine when you're only pursuing one or two isolated projects, but > when BPM starts to be "part of the way we do things around here" > you need to be able to guarantee that processes are going to work > with commonly-defined definitions of business information entities > like customers, orders, invoices, deliveries, products and so on. > > /*Creating a "service context" for processes*/ > > There's another, but less obvious, way in which the combination of BPM > and SOA can deliver increased value: SOA, when considered holistically > in the context of business architecture as well as technology > architecture, can provide a consistent framework in which to explore and > define process KPIs. > > In a business architecture driven approach to SOA, a portfolio of > services isn't created by solely focusing on how existing software > applications and resources can be more effectively exposed to be reused. > An equally important starting-point is an understanding of the > high-level business service commitments that an organisation makes to > external parties (related to the ordering and delivery of products, > resolution of problems, or filing of financial statements, for example). > Service models acting at different levels of granularity and abstraction > decompose these top-level business service commitments, and inform > requirements for service commitments at different levels within an > organisation and its systems. > > Today, these service-level commitments for processes are most often > explored and analysed within individual BPM projects, rather than within > broader initiatives that span multiple processes and projects. If you > drive the specification of KPIs and SLAs for processes solely from > within the scope of individual BPM projects, without considering the > broader landscape of the organisation's business model and service > commitments, who's to say that the KPIs and SLAs are really aimed at > measuring what's important: the business service commitments to external > parties? > > A holistic approach to SOA which considers top-down service level > commitments as well as bottom-up system development and integration > requirements can, and should, inform business process modelling > initiatives to ensure a consistent set of business-meaningful service > level commitments. > > In summary: when you look at how to combine BPM and SOA initiatives, > don't just focus on the obvious integration-enablement aspects. If you > broaden your view to see how BPM and SOA fit into the broader > perspective of Business Architecture, more profound relationships and > opportunities will become apparent.>> > > You can find this at: > http://www.soainstitute.org/articles/article/article/bringing-bpm-and-soa-together-for-maximum-business-value.html > > Gervas >
