The question of how to combine BPM and SOA came up a lot here at TIBCO's TUCON user event - and, a little disappointingly, the standard response seems to typically revolve around reinventing the three-tier architecture of the 1990s, just with more scope and scale.

I pointed out in the previous part of this post a few ways in which that perspective is too short-sighted. It's OK to view BPM and SOA as both essentially technology approaches to building and integrating applications, but this is a perspective that misses a big part of the potential business value of the combination.

What we're starting to see, though, in a few advanced organisations, is how top-down, business-driven approaches to service orientation and business process thinking can combine with bottom-up, technology-driven approaches. The model that we see links an approach to business architecture that leans on the concepts of process and service to describe business fundamentals, with an approach to technology architecture that uses the same concept to describe the operation of automated systems. The same concepts are used at multiple levels of abstraction and composition/decomposition, so the link is seamless.

To make this link, the concepts of process and service are united through a third concept: outcome. The middle section of the diagram below, which outlines a process- and service-oriented view of business architecture, calls this out.

This is how it lays out:

• Outcomes are desired results. An outcome at the highest level is likely to be something concerned with the core value of the organisation, financial performance, etc. At this level, outcomes might link very straightforwardly to mission statements. At lower levels outcomes are going to be concerned with operational results - for example "product is delivered".


• Services are commitments to achieve outcomes.


• Processes are the methods through which outcomes are achieved.

Another way to explain this aspect of service orientation is like this: when you model a process, and define a KPI and a target for that KPI, you're actually modelling aspects of a service "wrapper" for the process, as well as the process. You're defining what the commitment to achieve the outcome looks like, as well as the method you'll use to achieve the outcome. It's only when you start to think in terms of outcomes (and then services and processes) that this becomes clear, though.

There are other ways in which SOA and BPM can be intelligently combined to add value to both that aren't just about simplistic views of integration (and I'll try and get to some of those in future posts, watch this space) - but I think this is one of the most important. It's important because it helps people get their heads around a way of linking business architecture work with technical architecture work - with one consistent set of concepts. To date, there haven't been many ways to do this, and our research suggests that few organisations manage to make the link effectively today.

To come back to the post title: when you start to think about outcomes as a core concept in business and technology architecture, it becomes clear that it's not accurate to say either that services come first, or processes come first: the truth is that *outcomes* come first, and services and processes are two sides of the same coin in achieving the right results.

Posted by neilwarddutton in Architecture | Permalink | Comments (1) | TrackBacks (0)

Over the years I've been helping to run MWD I've been to quite a few events, talked to many enterprise IT folks and talked to many tech vendors, too - and one of the topics that comes up most often is the relationship between BPM and SOA. There's been a bit of a run on the topic in the blogosphere lately. First, I was alerted to this post on CIO.com via the EDS fellows' blog in a post called SOA is a Business Process Architecture. At around the same time, I read The Problem with Process by Nick Malik (always good to read).

Too often, in presentations and papers, I see diagrams that replicate the old three-tier architecture of the '90s, but with a twist: instead of user interface, business logic and data access layers, now I keep seeing portal, BPM and SOA layers. Portals provide user interaction, and invoke processes; processes invoke services. Job done.

Looking at BPM and SOA purely in this way is short-sighted, disingenuous and dangerous. It looks at both initiatives through a very focused lens, and essentially says "BPM and SOA are about building and integrating applications". Not your father's applications I'll grant, but applications nonetheless - things with hard boundaries that have little awareness of other systems or resources that might exist, and little conceptual relationship to broader architectural or business considerations.

The first, and most obvious, point to make that blows this kind of picture apart is that it's mind-numbingly straightforward to wrap a process (or at least the initial invocation of a process) as a service. So *now* what's "on top" - process or service? This realisation has led to more enlightened commentators advocating that organisations consider processes and services more like a lasagne, with alternating layers of the two concepts. Services expose processes, processes call services, etc etc ad infinitum.

However even here we're only part way to the real answer, because this view also stems from seeing both BPM and SOA primarily from a "bottom up", software development- and integration-centric perspective. Of course, many people refute a view like this, and point out that "BPM is a business management approach, and SOA is a technology architecture approach - you can't lump them together so easily". In other (very simplistic) words BPM is a top-down, business-driven initiative, whereas SOA is a bottom-up, technology-driven initiative.

The two articles I've linked to above are great because they start to take a deeper look at the architectural and conceptual relationship between service and process. Both EDS Fellow Fred Cummins and Nick Malik start to pick away at the simplistic views that seem to hold sway in the minds of many at the moment.

Neither quite take the argument as far as they might, though. Through our industry research (for our book as well as our various free reports and consulting gigs), we've come to see that the value of both BPM and SOA comes from considering them neither purely as bottom-up initiatives focused on improving the development / integration of applications and resources, nor as top-down initiatives focused on exploring and elaborating business architecture. We already have a champion in the case of "top-down SOA" - the OASIS SOA Adoption Blueprints team. The real insights come, I think, when you see how top-down *and* bottom-up perspectives of service-orientation *and* process-orientation can all come together in a more holistic view of business and technology architecture.

I'll expand on what such a view entails in a Part 2 of this post.

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

... you're waiting for an identity management acquisition and then along come three at once. This time it's IBM which has acquired 40-person, privately-held Encentuate. If you think that Ecentuate's size is indicative of gap-filling motivations from IBM then you'd be right. The 7-year old company is a specialist in enterprise single sign-on (ESSO), which until now has been provided through IBM's OEM relationship with Passlogix. Clearly, owning rather than OEMing technology gives IBM greater control of its ESSO destiny - particularly as Encetuate is Java-based which should help with integration with the broader Tivoli identity management portfolio. In fact, during the announcement briefing the two companies explained how Tivoli Identity Manager is already able to manage Encentuate provisioning (although there are no production customer deployments). This is presumably the result of work that IBM Global Services did with Encentuate at the Singapore Government: the two companies weren't technology partners.

Having said this is largely about filling gaps in the IBM identity management portfolio, Encentuate does bring more than ESSO to the IBM table. The company has done a good job of integrating with a variety of strong authentication solutions and has a rather nifty ability to take physical access tokens (door swipes and so forth) so that they can be used as second authentication factors. Encentuate also has some neat audit and compliance capabilities which IBM will undoubtedly tie into the Tivoli Compliance Insight Manager (based on the acquisition of Consul in late 2006). In addition to the technology upside, Encentuate could also help IBM in the healthcare market, where smaller players such as Imprivata and Sentillion have done quite well: there's a good smattering of healthcare customers amongst Encentuate's 80.

Overall a smart acquisition by IBM. I am not so sure whether IBM's Tivoli Access Manager for Enterprise Single Sign-on customers will be quite so happy though. The company has committed to continued support but the next iteration of the product is going to shift from Passlogix to Encentuate. IBM will make it attractive for them to move but replacing identity and security solutions is, by definition, a risky business and I am sure they will have to carefully balance the risks of moving against those associated with sticking with a product which is not going to see further development.

Posted by nmacehiter in Identity Management | Permalink | Comments (0) | TrackBacks (0)

Hot on the heels of last week's acquisition of Credentica by Microsoft, Ping Identity (who I covered here in an On The Radar report) announced yesterday that it has acquired the Sxip Access business unit from Sxip Identity.

Sxip was early to spot the potential opportunity in providing organisations with a simple, easy-to-deploy single sign-on (SSO) solution for software-as-a-service (SaaS). Sxip Access was its response to that opportunity, combining provisioning capabilities with some Sxip hosted services and an appliance. The company had also cultivated relationships with the likes of Salesforce.com and Google (for Google Apps).

The acquisition of Sxip Access is a smart move by Ping Identity. Although it can be used to provide SSO for SaaS, PingFederate (the company's flagship multi-protocol federated identity offering) lacks some of the rapid implementation and deployment capabilities of Sxip Access. Part of the SaaS proposition is that organisations can get up-to-speed much more rapidly. Authentication and authorisation shouldn't hold you back: something that Sxip Access should help to prevent. Back in September Ping began to actively target the SaaS opportunity, allowing providers to sell PingFederate-based SSO to their customers and share the revenue with Ping. Yesterdays announcement should accelerate this.

(As an aside, I do wonder whether we might see Ping's SignOn.com user-centric identity offering heading in the other direction, given that Sxip is now fairly-and-squarely focused there).

Ping and Sxip, whilst they are comparatively small, punch above their weight when it comes to identity mindshare. I wonder whether this announcement might shake the much larger incumbent identity management vendors, none of whom have really articulated a credible SaaS proposition, into action. It should. SaaS buying decisions often bypass the IT organisation and the business buyers aren't (and in fact shouldn't be) interested in identity management: they want access. If a Salesforce.com recommends that the customer just needs to get their IT department to deploy this box and hook it up to the existing identity management solution so be it. Job done. With SaaS increasing in popularity, particularly in the SME segment where they have struggled to gain a foothold, the incumbents need a strong proposition or lose out to the likes of Ping.

Posted by nmacehiter in Identity Management | Permalink | Comments (0) | TrackBacks (0)

Microsoft today announced that it has acquired Canadian cryptography specialist Credentica. This news sees Microsoft reverting back to its more traditional approach of acquiring small (Credentica is a team of three) specialist technology vendors to plug very specific gaps. In this case, Credentica brings its U-Prove technology to Microsoft's Identity & Access Group to enhance the privacy assurance capabilities of Microsoft's CardSpace and Windows Communication Foundation (WCF).

Credentica was founded by acknowledged security expert Stefan Brands, whose team has applied some very advanced cryptography techniques to allow users to authenticate to third parties directly without the involvement of identity providers, whilst preventing the disclosure of personally-identifiable information - in a way that allows accounts to be linked across service providers. It also provides resistance to phishing attacks. Credentica's own marketing literature highlights the synergies with CardSpace:

The SDK is ideally suited for creating the electronic equivalent of the cards in one’s wallet and for protecting identity-related information in frameworks such as SAML, Liberty ID-WSF, and Windows CardSpace.

This is a smart move by Microsoft. Not only does it bring some very innovative and well-respected technology (with endorsements from the likes of the Information and Privacy Commissioner of Ontario, Canada) which extends the capabilities of Microsoft's identity and security offerings; it also brings some heavyweight cryptography and privacy expertise and credibility from the Credentica team. The latter can, and undoubtedly will, be exploited by Microsoft in the short term: the former will take more time to realise with Microsoft stating that integrated offerings are more at least 12-18 months away.

Businesses and public sector organisations offering B2C/G2C services should be following Microsoft's integration strategy closely as privacy becomes a more significant concern (and thus differentiator).

Posted by nmacehiter in Identity Management | Permalink | Comments (0)

I was chatting to a friend who's a top-notch Java developer over the weekend: we were shooting the breeze about Groovy, Rails, Spring, Hibernate and various other Things That Get People Excited (let's call them TTGPEs), and discussing how far they were likely to penetrate into your average IT shop. "Why do so many people insist on following the J2EE application model and associated patterns so slavishly," said my friend, "when they're so plainly not the right tool for the job in so many scenarios?"

"The thing that you never get from reading development books," I said - he'd just finished showing me a book on Groovy - "is how difficult it can be for your average IT shop to get on board with a new development technology, when you take commercial considerations into account. You can see from looking at code samples that language A is more compact or give you more productivity than language B. But what you can't see is the bigger picture of costs and risks."

I remembered a post of Steve Jones' I'd seen a couple of months back about development as a discipline for the masses - and also this one from Jeff Schneider about the value of SOA governance.

You see, the problem for your average IT shop in taking on TTGPEs is that even when they have been demonstrated to save time and/or money, there are two real barriers to adoption. Both barriers exist primarily because these shops have no option but to see development resources as a commodity.

First, within an average IT shop - think of one within a small utility provider or a local government - the business can't make a case for paying top whack to hire the very best developers. So, they have to shoot for the "mass market" of developers - hopefully capable and dependable, but not likely to be stellar performers. They also don't have a lot of time or money available for recruiting, so they tend to minimise the complexity of interviewing as far as possible - asking for "industry standard", well-recognised skills. Unless they can find TTGPE skills within that "mass market", they're not going to consider bringing those skills into the organisation. J2EE skills are now mass-market skills. Groovy skills aren't (yet).

Second, within such an IT shop, work tends to follow those same "industry standards", because the risk of doing TTGPEs is that if people leave or get sick, and new people have to be brought in, they have to be able to get new resources up-and-running quickly. If new staff have to spend weeks or months trying to re-engineer glamorous but unknown technology before they can continue a project, that's a huge, ugly cost.

Regardless of whether J2EE is increasingly being revealed to be more like a VW crossed with a tractor than a Ferrari, then, the truth is that most people have little choice, for now, but to stick with it and make the best of things.

Posted by nmacehiter in Software Lifecycle | Permalink | Comments (0) | TrackBacks (0)

HP yesterday announced long-awaited (at least as far as we are concerned) enhancements to its SOA software and services, which see the company beginning to realise the potential of its acquisition of Systinet (via Mercury) when it comes to SOA governance. Back in March, the other Neil highlighted that lifecycle management is one of the four key elements of an SOA functionality pyramid and is:

all about supporting development, integration and operations teams in linking their efforts to ensure that the consumer service experience is high-quality and consistent under potentially unpredictable circumstances. Typically the foundation of this capability is some kind of registry/repository, but ideally tools go further than this - firstly by helping to automate team workflows for implementing quality controls at design time; and secondly by helping to translate design intentions relating to operational SLAs into runtime policies which are tied into the infrastructure.

HP is attempting to go that bit further by more tightly integrating the registry/respository capabilities it acquired with Systinet to the policy-based management and monitoring capabilities of its SOA Manager product. Whilst HP also brings other valuable functionality to fill out the SOA pyramid, including business process monitoring (HP Process Insight), security and identity management (HP Select Access) and synthetic transaction monitoring and reporting (HP Business Availability Center) it does not - and nor would it claim to - have everything.

Enter the Governance Interoperability Framework (GIF) it inherited from Systinet. The GIF is designed to facilitate information exchange with the Systinet Registry and Repository allowing third parties to integrate relevant technologies, such as policy enforcement and service orchestration, with the SOA lifecycle management capabilities. As well as announcing 10 new GIF partners, HP is also publishing the GIF specifications.

Integration is not totally reliant on GIF though. Systinet's registry is also embedded in the SOA infrastructure offerings from the likes of BEA, Oracle and TIBCO, which makes HP an obvious potential source of broader SOA lifecycle management functionality for their customers. The company is not such an obvious choice for customers of IBM and Software AG who are building out their own capabilities.

SOA platforms do not begin and end with BEA, IBM, Oracle, Software AG and TIBCO though. There are other choices: Microsoft, Progress, Red Hat and SAP etc. Not forgetting of course that organisations will be acquiring service oriented solutions as part of business applications. What's the story there? There are two. The first is GIF. The second is the HP SOA Registry Foundation that also formed part of yesterday's announcement and which the company describes as

a new software product expressly designed for independent software vendors. HP SOA Registry Foundation is a powerful, standards-based way to publish, categorize and discover SOA services and artifacts. This new product can be easily embedded with packaged applications and distributed solutions.

In other words, it's an OEM-specific version of the registry designed to allow HP to replicate the BEA, Oracle and TIBCO agreements.

Coupled with the HP's services capabilities, these announcements should mean that HP is able to exploit its systems management heritage and installed base to position itself as a credible SOA lifecycle management provider to organisations moving beyond project-level SOA initiatives - and to the software vendors that are helping them on that journey.

Posted by nmacehiter in Architecture • IT Governance • Software Lifecycle | Permalink | Comments (0) | TrackBacks (0)