Actional released version 6.0 of its SOA Management platform this week.
Following on our acquisition of Actional corp, the Actional team has kept a steady eye on delivery of its next major release of its SOA Management platform (a.k.a. Web Services Management – WSM).
This product release touts 3 major new capabilities – 1) Something called “Business Process Visibility” (BPV), 2) Automated Runtime Governance, and 3) “Trust Zones” Security.
BPV goes beyond a service-by-service approach to visibility, governance and process optimization, allowing organizations to create “business flow maps”. A business flow map is based on Actional’s auto-discovery techniques that are used to build a map of SOA interactions across services, protocols, platforms, and appliances.
BPV provides the correlation of between the IT and business views of the same end-to-end business process. The business view provides key business indicators (KBI) to answer questions about the health of your business in a broad way such as “Are there customers having issues?”, “Am I keeping up with demand?”, and “Am I meeting my commitments?” KBIs at an individual business process level can provide “what is the average dollar amount per order for the order process?” Additionally, metrics and measurement can be applied at a process level to answer questions such as “How long does it take from order to delivery?” and “Why has the process stalled?” All this information is made available in a Business Activity Monitoring (BAM) dashboard environment with visual charts and graphs that can be readily understood by business people.
When a problem does occur in a business process, an alert can be raised to both the business people and the IT people who are monitoring the process from different perspectives. The IT people then have the proper tools to drill down into the details of the requests that travel across the business flow map and perform root cause analysis of which service went faulty or caused the overall process to exceed its Service Level Agreement (SLA) timing boundaries. Historical snapshots of the process metrics may also be examined in order to determine changes in behavior over a period of time.
You may be wondering at this point what is different or unique about this capability from other technology approaches such as what you can do with a BPM tool or what you can accomplish with a traditional system management console. The typical IT approach is to use a manage console to individually look at systems and trying to understand whether they are down, and what caused the failure. This serves a useful purpose but by default it doesn’t allow one to understand how the broader business process, such as an “order process”, is affected. Using a BPM tool or an ESB you have insight into the process as far as that tool can define and track it, but you don’t have insight into process flows that extend outside of the reach of that tool. To address both of these shortcomings the usual approach is to interview a number of IT developers and system architects and use something like Visio to manually build a set of process maps that capture about 80% of the overall problem, and manually correlate that to alerts that occur within an enterprise management console.
In contrast, the Actional SOA management approach relies on dynamically building end-to-end business flow maps that are segmented into individual business processes. This automatically provides a view of your business processes based on the “system of reality”.
Because the business and IT people both have their views into the SOA environment at the process level, then they also have a common context for discussion when a problem does arise.
The other two major capabilities – automated runtime governance and trust zones — take full advantage of this unique process centric approach.
I have spent a great deal of time meeting with many senior level architects over the past few years about their SOA projects, and they consistently tell me the same thing - regardless of how diligent an organization is about creating policies and procedures for deploying services, there always seems to be new services or new versions of services being deployed that bypass or go outside of those procedures. The introduction of these “rogue services” in an enterprise can open up severe holes in an organization’s security and governance plans that they have in place, and can violate important regulatory compliance such as Sarbanes-Oxley.
The Actional 6.0 automated runtime governance capabilities recognize that new rogue services are just a fact of life, and can proactively work with a registry to corral those rogue services into compliance. Using the UDDI v3 APIs that are part of the Systinet 2 Business Registry (a.k.a v6.5 :) ), information about the newly discovered services can be automatically populated into the registry. Using the Systinet registry’s administrative promotion and approval capabilities, the newly discovered services will be presented to an administrator for deployment approval or rejected and dealt with. Using the autodiscovery capabilities of Actional 6.0, information such as service consumer and provider dependencies can also be reported to the registry (whether the services are rogue or not).
Policies may be applied across a process to provide automated runtime governance.
Common policies, such as security policies for authentication and authorization, can automatically and immediately be applied a newly discovered rogue service without having to wait for an administrator to go into the registry tool and view it. Now that’s cool! This can help to immediately seal holes in your security as soon as they happen.
Trust zones take advantage of the process centric view of the SOA runtime by enforcing policy-based authentication and authorization checking across and end-to-end business process flow. Messages that have not passed through a security enforcement point can be stopped in their tracks.