Salesforce.com just added a powerful new tool to its Force.com development platform, a Visual Process Manager:
“The Visual Process Manager brings the power of Cloud Computing to Business Process Apps. Now you can visually draw any business process and instantly deploy it in the cloud with no code, no software and no infrastructure. The Visual Process Manager helps companies easily automate specific business process like call center scripting, sales quotes, and new employee on boarding.”
According to a post on TechCrunch:
“The technology powering the Visual Process Manager is based on technology acquired from Informavores, call scripting startup Salesforce bought last year.
The Manager has several different components. The Process Designer essentially helps businesses sketch out applications with established set forms, questions, and choices, and logic components, like task assignments, decision trees, and approval processes. These components can be dragged and dropped into a visual process design diagram/ The Process Wizard Builder enables companies to design a “wizard” to help walk end-users, step-by-step, through their business process. The Process Simulator lets customers test out and review processes before they are deployed. And lastly, the real-time process engine will run all of a company’s sophisticated processes and provides realtime scalability.”
The Visual Process Manager introduction gets a bit deeper on functionality. [emphasis is mine]:
“Using our cloud-based workflow software solution, you can specify the retrieval, creation, update, or deletion of any object in a salesforce.com application or any Force.com object (including custom objects). You can also call any Force.com API. In practice, this functionality means that sales and service agents can work with simple, easy-to-follow scripts—while underneath, embedded business rules and salesforce.com data drive what the agent sees and automatically update CRM records. These are textbook examples of successful workflow software applications.
After you’ve optimized a specific process using the Visual Process Manager workflow software tool and the process is running inside your salesforce.com application, operations become much more efficient. The newly automated workflow carries out all the administration work behind the scenes. It may control the interaction of an agent in a call center or a customer on a Web site, as it silently interacts with other systems, processes, and Web services to deliver the required actions.
Because our workflow software tool is designed with integration in mind, you can link to databases, dialers, and IVRs; initiate workflows; control exceptional events or surge conditions; and handle the “stop and save” process required to manage escalations and call transfers. All in all, our workflow software frees sales reps and support agents from administrative grunt work, quickly giving them the situation-specific information they need for effective selling and top-notch customer service.”
As I read about Visual Process Manager, I was reminded of my Vanilla Layer Cake Theory paper from 2005.
“There are classic rules of thumb used in buy/build decisions. Buy in situations of parity. Build for competitive advantage/differentiation. In a buy scenario, you willingly cede control of the end product (functionality, architecture, technology) for the promise of a lower price tag, ease of implementation, and quicker time to market. For success, you must actually cede that control—in other words, no modifications. But, that’s not always realistic. So, how can you reap the advantages of a buy, while providing a solution that actually fits your business (modifications and extensions), without getting trapped? Think Vanilla Layer Cake.”
An excerpt published on elemental links, November 2005:
“The vanilla layer cake theory is simple. Do vanilla (out-of-the-box) installations of all new application packages. Then, customize and extend the application functionality using abstraction layers, rather than in the application package itself.
[Click on picture to enlarge]
In essence, the application package installation performs the role of a provider in a service-oriented architecture. In some ways, the application package is more valuable for its building blocks, than how the vendor assembled it.
The abstraction layers implement your business architecture, in the form of an enterprise information model, business services, business scenario composition (process, events, service orchestration), and user interaction (portal, user interface, unified in-box).”
Of course in the SaaS world of Salesforce and Force.com, you can skip the “Do vanilla (out-of-the-box) installations of all new application packages” step, and proceed right to “customize and extend the application functionality using abstraction layers”. Now, that’s intriguing…
For those with a sense of nostalgia, you can read the entire Vanilla Layer Cake Theory on ebizQ. Otherwise, dig in at Salesforce.com.
[Cross-posted from Elemental Cloud Computing].
As I officially wrap-up my SOA Consortium responsibilities, I wanted to share the following (lengthy) post on a great discussion in the community of practice. The following is cross-posted from SOA Consortium Insights. As was announced in October, the SOA & BPM Consortiums have merged. To participate in great discussions like the one captured below, visit the SOA Consortium website or send them an email. The original post follows.
Note: For practitioners, one of the most valuable aspects of consortium participation is the opportunity to exchange ideas in a trusted peer community. While the diverse group doesn’t always reach a single conclusion, each participant gains new perspective to consider in their unique situations.
One such SOA Consortium conversation thread started with service value, covered service marketplaces, cathedrals and bazaars, and concluded with service portfolio management. What follows are notes from that conversation, published not as an answer, but for consideration as you expand the breadth and depth of your service-oriented architecture. As always, we welcome comments.
CALL #1 – Service Sprawl and Service Marketplaces
In a series of calls, the SOA Consortium’s community of practice engaged in a very interesting discussion on service portfolio management. The conversation began innocently enough, when one member queried the group on visual methods to demonstrate the value of a services approach to business personnel.
This member was looking for insights on creating a business intelligence dashboard for business stakeholders to see the value of service adoption, including key metrics on service use and re-use, and time-to-market improvements. His motivation wasn’t marketing, but an underlying concern that full SOA value wasn’t attained because of service sprawl.
In this case, the service sprawl had two sources. First, and the more common cause, SOA was simultaneously adopted in different business lines. In the early stages, each business line created its own services, unaware of reuse or collaboration opportunities. Second, the organization acquired another organization with similar business lines, which was also pursuing SOA.
Through conversation, members noted other service sprawl causes, such as lack of trust, immature service governance practices, and no mandates for service rationalization.
From here, the group began discussing ways to reduce and prevent service sprawl. A popular idea was the creation of a services marketplace. In a short brainstorming session, the group discussed incorporating prediction markets to gauge service popularity, and social technologies to build trust, as well as to strengthen the service offering with better definition, feature/function, and performance. Detailed brainstorming notes follow.
Services Market Place Requirements
Services Marketplace Functionality/Technology Ideas
Services Marketplace Questions
About this point, the group made the leap to the Cathedral & Bazaar metaphor. Service repository as we know it today is Cathedral, Services marketplace is Bazaar.
Service Bazaar Startup Needs
At the close of the call, the member originally posing the service sprawl problem decided to explore prediction market technology for service portfolio rationalization. As well, the group decided to continue the bazaar discussion on the next call.
CALL #2 – Service Cathedrals and Bazaars
Continuing the services marketplace conversation theme, but with many new call participants, there was a strong sense that service sprawl needs to be managed both proactively, via portfolio definition/management practices and reactively, via both top-down rationalization efforts and bottoms-up service marketplace advertising and consumption patterns.
Call participants from enterprises expressed concerned that a pure services marketplace – introducing competing code – is not behavior a development organization can afford to participate in.
There was strong support for the advertising aspect of the services marketplace, letting people know a service existed, its purpose, current usage scenarios, community ratings etc.
For a services marketplace to be successful, it needs to be close to where developers work. Oracle’s Enterprise repository (BEA Flashline) was cited as an example of tool with community engagement vision.
It was noted that in organizations where sprawl exists, or M&A activity is underway, the services marketplace can provide a mechanism to contain further sprawl and promote (Darwinian) rationalization, even before formal rationalization assignments/efforts are underway.
Another note was that duplication does not always equate to waste. An organization’s operating model (see Ross & Weil) may call for some separation of services to support a fast growing/changing business unit/activity.
There was a call for distinction in the marketplace’s unit of exchange (used in funding decisions) from service portfolio metrics. Service portfolio metrics should not be number of services; instead use percentage of (unplanned) redundancy & coverage gaps.
The group believes portfolio management – value of IT investment over time – is an important concept. The current project focus in most organizations – on-time and on-budget measurement – is very short sighted. Businesses do look at total IT spend over time, and percent of development versus maintenance, but most often don’t drill into the specific business domains or business capability. This lack of transparency can lead to a behavior of delivering sub-par solutions that require frequent replacement.
In respect to proactive service rationalization, the group spoke of defining enterprise and/or domain service maps. They also spoke of the need to get business analysts involved in service definition, and that business analysts might be better accepted by business units if they (business analysts) reported to Finance or Quality, rather than IT.
Additionally, the group discussed incentives for sharing services. The biggest point/concern here is that the incentives need to map to portfolio metrics and goals. Avoid the trap of putting incentives in place that encourage “gaming the system” to receive the incentive while damaging the overall service portfolio. Some members believe the incentive is keeping your job.
A late discussion point was that sustainable SOA has organizational implications beyond initial centers of excellence. Sustainable SOA requires pervasive practice, cascading changes (service thinking and management) to funding practices, project management, solution delivery, operations, and change management. In other words, SOA cannot be a side practice forever.
CALL #3 – Service Portfolio Management
Reviewing the key discussion points over the past two calls, the group concludes that both models – Services Cathedral and Services Bazaar – are valid.
The adoption of a cathedral and/or bazaar approach may vary based on project lifecycle phase, business criticality of the problem being solved, experience of the project/development team in respect to SOA, and/or time to market considerations.
A discussion on project lifecycle practices leads to a discussion on portfolio management practices:
A service-oriented approach fundamentally changes the basic management unit from an application, to services, or a bundle of services that represent a business function (component, segment, flow or capability), which are consumed by many applications, business processes and/or domains.
The multi-purpose aspect of services, and bill-of-materials structure of service compositions and solution assemblies, point more towards product management practices than traditional application management practices. The shift to product, rather than project or application thinking, forces changes to funding, project management, asset management and operations practices.
Most notably, organizations will need to be deliberate in the realm of service portfolio management, understanding what business capabilities are offered in the portfolio (marketplace), how those capabilities are instantiated via software and information assets (model to asset mapping), and how/where those capabilities are packaged into end-products (applications, processes) that solve a business need.
The diagram below, previously published, illustrates services and the various process and portfolio interaction points across the service lifecycle.
[Click on diagram to enlarge]
[Disclosure: The SOA Consortium is a client of my firm, Elemental Links. I will continue to work with the SOA-C’s parent organization, the OMG, in 2010.]
