Augment – a NetWeaver IDM 7.0 staging tool – bonus features

In addition to Augment’s basic features, we’ve added a few bonus features:

  • Compare Task links between two environments, and be able to filter for differences
  • Import or export constants and variables, either global or repository, from either environment
  • Export all scripts, either Javascript or VBScript, and selectively import

These added features definitely help identify and correct any errors within your IDM configurations quite easily. There’s also the added benefit of being able to manage your scripts easily as actual files rather than embedded scripts.

Hopefully this gives you a good overview of how SECUDE’s Augment can help improve your IDM 7.0 staging process. Feel free to leave a comment if interested in an early beta.

Augment – a NetWeaver IDM 7.0 staging tool – basic features

SECUDE ‘s Augment helps save valuable time during the staging process. Here are the main features that help with some of the basic steps of your staging process:

  • Work with a maximum of two environments at a time
  • View all jobs and tasks that are either disabled or enabled
  • Quickly enable or disable jobs and tasks, selectively or globally
  • Compare Jobs, Tasks, Variables and Constants between two environments, and be able to filter for differences

In the next post I’ll highlight the bonus features we’ve added that will definitely help make your staging process a more robust one.

Augment – a NetWeaver IDM 7.0 staging tool

Currently, when working with Netweaver IdM 7.0, migrating a configuration from one environment to another (e.g. DEV to TEST or QA to PRODUCTION, etc.) can end up being a very long and manual process. One has to go through the following steps:

Export the configuration

  • Export job groups
  • Export identity stores

Bootstrapping the staging environment

  • Create dispatchers with the same names as on the test environment.
  • Create event agents.
  • Define the default import settings: dispatcher, enable jobs and check-in jobs.
  • Create roles, privileges and dynamic groups (if used for task access control).
  • Import job group(s).
  • Import identity store(s).
  • Manually link any event agent references.
  • Manually update global constants and repositories.
  • Manually update provisioning/deprovisioning task references on privileges.

In the above list , all items in bold are manual steps.  So, with about 75% of your staging process being manual you can end up spending close to about 4-6 hours completing a migration for a pretty complex system. And with 75% of the build process being manual, the chances for human error are much greater.

We at SECUDE have developed a tool called Augment, that we hope can greatly reduce the time taken for migrating configurations between environments. I’ll higlight some of it’s basic features in the next post.

VDS Logging

The astute observer will notice that the most recent releases of SAP’s NetWeaver Virtual Directory Server are missing the logging control buttons. There is a  very good reason for this seemingly missing functionality.  Much like NetWeaver Identity Management, VDS is also merging into the NetWeaver, specifically NetWeaver’s logging framework.  This means that there is not a need to have VDS offer internal logging.

However, VDS also offers the ability to run in a “Standalone mode” which allows for VDS to run independently of NetWeaver.  If you plan on running in this mode you’ll need to take advantage of the following configuration tweak in order to access the logs:

Update the file standalonelog.prop that can be found in the Configurations folder.  If you do not have this file, information can be found in the SAP NetWeaver Idenity Management Operations Guide. This document can be found on SDN. The file is a basic text file that includes setting the log level and desired location of the log file.

Once this file is configured it needs to be placed in the Work Area folder (typically underneath the Configurations folder.  Note that creating this file will not bring the buttons back, it will only create the logs in the paths specified in standalonelog.prop.

From what I understand the internal log viewer will be back in the next Service Pack for VDS.  It will be good to have it back.

Perception of Risk is Influenced by Ease of Pronunciation

I missed this study earlier  (HT: Bruce Schneier).  The result is exactly what one  would expect.   There has always been a general distrust of the alien, fear of the unknown.  The impact on IT is that when they bring new items up for review they can expect higher scrutiny for anything containing hard to pronounce names.  Experience teaches us that most innovations fail so when we encounter something unfamiliar we consider it more risky.   Difficulty in pronouncing its name  amplifies this effect.   In fact this is why we have proof of concepts, pilots and test markets for innovations.   When faced with three choices to make under time pressure we will tend to choose the one that is most familiar because cognitively we map what is familiar to safe.  Difficulty in pronouncing a name, can also slow the time it takes process the choice.   Look how long it took Linux to gain acceptance in the executive suite despite the cost differential and ease of pronunciation.  The experience of using it in the data center is now sufficiently broad that except in the most conservative companies, it is no longer considered risky.  Imagine how much longer it would have taken if the name was something like Lydrarjickavar.

Structured for Failure

The painful losses in the sub-prime mortgage market among Banks and Wall Street firms, a near global melt down of credit markets show once again that despite an army of PhD’s in finance, sophisticated risk models, the same kinds of errors continue to be repeated.  As James Kenneth Galbraith observed in his book, A Short History of Financial Euphoria (Financial Genius is Before the Fall) control of large sums of wealth is mistakenly assumed to be a sign of great intelligence and leadership when it may in fact, only indicate, accident of birth, political acumen or indifference to  legal restraint.  There are lessons here, which many will ignore, but one in particular bears repeating and impacts enterprise risk management.

Success is a positive feedback loop with each success re-enforcing the previous action and increasing like kinds of behavior.  Positive feedback loops are an essential element of any system, but there is a tendency for them to cycle out of control.  An example would be children starting to build a fort from scrap wood and ending up putting titanium gun ports on their material list.  A more ominous example is drug abuse where the addict must ingest ever larger dosages to achieve the same high. In like manner, euphoria regularly overtakes markets and businesses.  The restraint on this behavior is a negative feedback loop.  Externally these are provided by short sellers at market highs and buyers at lows.  Internally, on Wall Street, this is the role of risk managers.

Following the debacle in the subprime market and other collateralized debt obligations (CDO) many risk managers lost their jobs.  This seems reasonable given what occurred except for one thing; in at least one case they reported to the heads of the individual businesses .  Does this sound familiar?  When you have been assigned the responsibility but do not have the power, you are nothing more than a sacrificial lamb for someone else’s failure.  The negative feedback loop function of risk management is eliminated and the most you can do is sound a warning like an old testament prophet and then wait quietly for the stoning.   Whether we look ex-ante or ex-post, it would seem obvious that organizations that structure reporting hierarchies with conflicts of interest are increasing their risk of failure and simultaneously increasing the magnitude of any loss.  This problem is not unique to the financial community.

For a corporation to succeed long term, to demonstrate true stewardship of the shareholder’s assets, it must address internal and external threats and meet regulatory requirements. It must fully understand the true costs of mistakes and where this is unknown prepare. It must be able to withstand shocks. The risk control groups within the typical enterprise, (insurance, audit and information security), need to provide their advice to those whose best interest is in heeding it, not those who have a “perverse incentive” to ignore it. Where does internal audit report in your organization? Where does information security report?

When dealing with both endogenous and exogenous risks, if we wish to learn from past errors, we need to have the reporting structures free of any conflict of interest. A typical conflict in large corporations is where the information security manager is reporting to the CIO or worse a director. We have seen many large projects where critical risk mitigation strategies are ignored because they increase costs on the front end. Enterprises that persist in this direction are leaving themselves open to essentially unlimited risk. It would be far better for organizations to take a total risk management approach placing information security, insurance, business continuity planning, internal audit, privacy and like functions under a single manager who reports to the CEO. Absent this structure then reporting structures will depend largely on the type of business, industry, product, or relevant regulation. Let’s examine the foregoing using Professor John Boardman’s Systemigrams which are particularly well suited to providing insight into both solution and problem domains.


In this simplified example (actual risk can be more subtle), we have a typically hierarchical organizational structure wherein the risk management function (information security in this case) reports back into information technology (IT) and information technology is reporting into finance (CFO).  The problems do not develop until late in deployment .  The weakness in the system (which may or may not meet regulatory compliance) eventually impacts profitability.  This receives the attention of finance which subsequently applies pressure to IT.

Frequently there is no impact on profitability and the problem remains until it is detected by internal audit.  Depending on whether the company is subject to US regulations, it may not ever be addressed.  As a practical matter system vulnerabilities can go undetected and unexploited ad infinitum.  We have seen companies who are surprisingly blithe about the level of risk they are assuming and they can point to years of experience in which nothing damaging has occurred.  This is a fundamental weakness in human psychology.  Lack of previous exploitation tells us nothing about the future probability of it occurring.  In fact, small regular loses will draw immediate attention but disasters will only produce heroic figures and scapegoats.  Someone once wrote “crisis is the best opportunity”.  Preventing the crisis goes unrecognized as we have pointed out in another post.

Let’s take the foregoing example and alter the reporting structure.  In this diagram we are focused only on the risk elements and ignore many of the more subtle dimensions for the sake of illustration.  The reporting of IT risks is detached from IT, audit is detached from finance and they are equal partners in a dialog concerning risks. Given that the modern corporation is not purely hierarchical containing also elements of networks and properties of networks, risk subject matter experts (SME’s) are detached and work within the business elements they support.  Their insight provides valuable perspective on emergent properties of networks they are affiliated with.  This will reduce checklist, purist or ivory tower type decision making on risks.  The importance of this cannot be understated.  Businesses must take risks to excel and those risks must be measured, intelligently taken, and balanced.  With the correct strategies and structures in place, the business can move forward confidently and while not immune from losses and failures, neither is should it be the architect of its own collapse.

conflict-of-interest-removedWe have attempted to show certain structures can be detrimental to the long term health of the enterprise by permitting it to take on excessive levels of risk.  We have also attempted to show one general approach that permits the organization to consider risks and mitigate them before it reaches the level of a disaster, irrespective of the risk domain.  Proper structure allows the enterprise to plan for foreseeable risks and remain flexible and adapt to those that are unseen.  Obviously this is a single dimension of risk management and prudent organizations will have a plan covering all areas.

Keep it on One Sheet

When IT personnel seek approval  for a project or to purchase software, they spend a lot time preparing a document which is often restricted to a single page summary.  Many managers today insist that everything be crowded onto  1- 1.5 pages before they will make a decision.    I have  sat in meetings in which they didn’t even look at the paper because they had the responsibility for deciding an issue but not the knowledge or experience.   At first glimpse it may be seen as  intellectual laziness (and in some cases it is), but far more often it is a resource constraint.  “I don’t have the bandwidth” you hear people complain so ‘no’ is the safe decision.  Late adoption of new, beneficial technologies normally occurs in companies with technical managers of below average technical understanding or where the CIO still reports to the CFO.  This is not meant as a slur, but simply what I have observed.  One could argue with access to capital you don’t have to be an aggressive user of new technology.  The choice is reasonable if frustrating to innovators in the company.

Returning to our single sheet requirement, it becomes apparent one cannot present all the information.  The relevant data will be  selected  so that it communicates the facts from sender to receiver but only the facts the sender wants to show.  If the level of trust is high it won’t be questioned.    This process practically guarantees a tendentious analysis.  This simply does not serve the best interests of the company.  I intentionally chose an innocuous example.  Far worse are the complexity of internal politics, turf wars  or outright corruption.  These are real risks and when things are going well they are glossed over or accepted.

To work around these problems and risks, it is necessary to properly set the context.  Starting with our time horizon, drilling into corporate strategic goals, looking at our internal systems,  and finally at the product or project we are analyzing.  The frame we create profoundly impacts our decisions.  If the goal is to make the best choices possible, this is where we start.