A small step for SCA, a giant leap for BSM

In a very short post, Khanderao Kand describes how configuration properties for BPEL processes in Oracle SOA Suite 11G are attached to SCA components. Here is the example he provides:

<component name="myBPELServiecComponent">
  ...
  <property name="bpel.config.inMemoryOptimization">true</property>
</component>

It doesn’t look like much. But it’s an major step for application-driven IT management (and eventually BSM).

Take a SCA component. Follow the SCA-defined component-to-composite and service-to-reference relationships upwards and eventually you’ll get to top level application services that have a decent chance of mapping well to business-relevant activities (e.g. order processing). Which means that the metrics of these services (e.g. availability, response time) are likely to be meaningful and important to the line of business. Follow the same SCA relationships downward and you’ll end up (in a SCA-based infrastructure like Oracle SOA Suite 11G), with target components that are meaningful to the IT administrator. Which means that their metrics and configuration settings (like “inMemoryOptimization”) are tracked and controlled by IT. You now have a direct string of connections between this configuration setting and a business relevant metric. You can navigate the connection in both directions: downward/reactive (“my service just went down, what changed in the infrastructure”) versus upward/proactive (“my service is always slow, what can I do to optimize the execution”).

Of course these examples are over-simplistic (and the title of this post is a bit too lyrical, on account of this). Following these SCA relationships in brute-force fashion will yield tens of thousands of low-level configuration settings for any top-level service, with widely differing importance and impact (not to mention that they interact). You need rules to make sense of this. Plus, configuration-based models are a complement to runtime transaction discovery, not a replacement (unless your model of the application includes every single line of code). But it’s not that often that you can see a missing link snap into place that clearly.

What this shows is the emergence of a common set of entities between the developer’s model and the IT admin model. And if the application was developed correctly, some of the entities in the developer’s model correspond to entities in the mental model of the application user and the line of business manager. SCA is the skeleton for this. Attaching configuration to SCA components puts muscle on the bone.

The road to BSM is paved with small improvements in the semantic alignment between IT infrastructure and application services. A couple of years ago, I tried to explain why SCA is very relevant for IT management. Now we can see it.

4 Comments

Filed under Application Mgmt, BPEL, BSM, Business, Business Process, Everything, IT Systems Mgmt, Mgmt integration, Middleware, Modeling, Oracle, SCA, Standards

4 Responses to A small step for SCA, a giant leap for BSM

  1. I am curious why you seem fixated on the actual static configuration rather than the actual dynamic behavior patterns and runtime state.

    What has [config] changed? Should that not be what new behavioral & state patterns have we detected in our system. A configuration change does not necessarily imply a change in actual software or system execution behavior though I will admit that it is a good starting point when you have nothing else to go on.

    Maybe it a difference in perspective. I seek to understand (largely observation based) and acquire knowledge whereas most are just looking to take corrective action (incident mode) which typically means roll back but without the search for the underlying “why X” and no knowledge acquisition.

    Coming from a programming background I see both the dynamic system and software execution models as the ultimate configuration management databases. But then again I love the hard challenges.

    William

  2. Hi William L.,

    “fixated” seems a bit strong a word when I explicitly wrote that “configuration-based models are a complement to runtime transaction discovery, not a replacement”.

    Regards,

    William V.

  3. Missed that statement. I take “fixated” back the rest you can keep, ;-).

  4. Pingback: Bookmarks for July 22nd through July 27th