REDMOND, Wash. — For the most effective service-oriented architecture implementations, enterprises should unify enterprise architecture with SOA and business process management, so said Gartner Research analyst Nick Gall in a broad how-to discussion on SOA at the 2009 Microsoft SOA and Business Process Conference here.
Gall, who is a vice president at Gartner, spoke on “The Role of Enterprise Architecture in Shaping Business Process Management and SOA.” He started off saying the reason for getting into SOA is change. He said the frequency and amplitude of business change is increasing, “And you’re all going to be doing SOA in 18 months whether you plan to or not.”
Meanwhile, Gall said SOA and BPM are typically not well-coordinated in the enterprise. He then got into definitions of the basic concepts. For instance, EA is the process of translating business vision and strategy into effective enterprise change by creating, communication and improving key principles and models that describe the enterprise’s future state and enable its evolution.
As for SOA? SOA is an architectural approach to building systems, Gall said. It delivers two major categories of value. One is sharing or reuse, and the other is agility or the ability to change more rapidly. And this is done via two fundamental principles: interface abstraction and modularization, he said. Further, Gall said there are five principles of SOA design. A SOA is modular, distributable, clearly defined, swappable and shareable, he said.
And what is BPM, you ask? According to Gall, BPM refers to a set of management disciplines that accelerate effective business process improvement by blending incremental and transformative methods. BPM is a cultural change, he said. So if an organization is not willing to change the way it works then it should not set its expectations very high, he said. However, BPM’s disciplines are largely technology-enabled, Gall said.
Gall maintains that SOA is better with BPM. “While you can establish an SOA, to build an SOA application you need business and process analysts to design and build the most effective ‘close-to-the-business’ applications,” he said.
And conversely BPM is better with SOA, Gall said. “BPM alone is limited,” he said. “Older, siloed applications are difficult to integrate with BPM.” Yet, services represent the actions that processes coordinate and services ensure consistence across processes.”
However, “where the magic happens” is in what Gall refers to as the Service Interface Center of Gravity or IFaPs, which is a reference to Identifiers, Formats and Protocols. (IFaPs). Identifiers are single versions of master data. Formats are metadata for transparency and discovery. And protocols are common information services to harmonize of manage results, Gall said.
Five Building Blocks of SOA
Meanwhile, Gall listed five building blocks to enable SOA and business processing: Enterprise architecture; modeling and abstraction; skill, sourcing and organizational structure; governance; and technology.
Having already defined EA, Gall delved into modeling and abstraction. “It’s more important now to start thinking about integrating your models,” he said. “And that’s why I’m excited about things like Oslo, which is about integrating models.” Oslo is the codename for Microsoft’s broad modeling strategy, which consists of a new modeling language, a new visual tool and a repository for managing the models.
In terms of skills to effectively deliver SOA and BPM, most organizations will need to do “some outsourcing and some ‘in-sourcing; but this is not the kind of thing where you send folks out to a training course and they come back and it magically works,” Gall said.
In addition, Gall said, “You can’t tell the success of an SOA initiative until at least two to three years later.” A successful SOA implementation should be enabling more rapid change even two to three years later, he said.
Moreover, Gall listed a bunch of technologies that enable BPM. These include human workflow management tools, document and imaging management solutions, modeling tools, integration brokers and application servers, portal servers and rules engines, he said. And on the SOA side, Gall listed some of the leading companies delivering SOA capability in the famous Gartner Magic Quadrant. These companies included Oracle, IBM, TIBCO and Microsoft, among others.
To bring home his point about the benefits of unifying EA, SOA and BPM, Gall mentioned Well Fargo as a case study of how it can all come together. He said the Wells Fargo experience showed that EA acts as a facilitator, but without BPM systems tended toward stove-piping. Yet, BPM alone did not have the reach. So by unifying the approaches, Wells Fargo was able to streamline a major process that had 15 sub-processes into a solution that reduced cycle time from 12 days to a single day and led to savings of $30 million a year, he said. Also under the new architecture, Wells Fargo executives gained more visibility into their systems and decided that one-third of proposed projects were not needed.
So when implementing SOA — along with EA and BPM — Gall recommends that enterprises use a middle-out architecture; focus on the pain points; move business volatility into data and move technical stability into code; describe architectural interfaces as IFaPs; and focus on process issues that are difficult to manage or change.