If you survey the information on the web concerning IT architectural principles you mostly find descriptions like this.  This is pretty consistent what others have published whether IBM, Gartner, Forrester et. al.

After some explanations, they go on to list a set of rules that should apply to the deployment of IT.  The perspective here is really policy based.  As a policy they are simply constraints on what is permissible and/or a listing of “best practices.”  I believe this approach can be subsumed by a broader category, one with a results focus.  IT’s sole purpose as is any tool is to act as a productivity multiplier, to make the organization more efficient.  The role of the architect is to make decisions which once made are not so easily reversed. This semi-permanent aspect of decision making is why architects should be experienced practitioners that are well versed in computer science fundamentals.

Drawing on the work of Darrell Mann and others, IT Architectural Principles with a results focus can be split into two categories, analysis and design, the first no one enjoys doing the second everyone does.   See diagram below.

In the category of analysis, the principles – as defined by the opengroup – become just another series of constraints which influence our design (sometimes to the detriment of the organization when a broader context is not considered).  With the exception of the last item, the listing is straight forward in meaning. What is meant by sticking points are those areas which are sometimes called engineering tradeoffs.

Regarding the design principles, these are derived from a millennia of trail and error with modularity allowing the architect to encapsulate complexity and increase his solution choices, flexibility allowing us to reverse decisions, adapt to change and resilience to withstand the shock of disastrous events.

I believe following these principles versus thinking only about organizational rules, policies and constraints permit us to produce more innovative designs, increasing efficiency in the organization and fulfilling the proper role of architecture.

That there are no new problems seems widely understood (save for the child and naïf) but it seems rarely do people bother to understand the historical solutions to these problems, that is to say, we focus almost exclusively on the facts of the problem without ever bothering to look at the principles or rules that may already be understood.  This kind of reflective thinking, along with analysis of principles derived from the experience of our predecessors whether extant or having suffered debitum naturae, extracts a large cognitive cost.  “Math is hard,” the philosopher Barbie once observed, as is all real analysis.

What we frequently do, because it extracts a low cognitive cost, is simply to allow things to move in the direction dictated by the promoter with the large megaphone, to prattle on mindlessly like a child, to ignore what has gone before, to ignore what theory there is and prefer the clustering of like minded people even if this is nothing more than a coterie of idiot enthusiasts.  It is easier to sit on the band wagon collecting money with all the other simpletons, than to go against the flow and think for yourself.

Nothing embodies this more than the widespread use of XML for things which it is poorly suited, especially data management.  In its early stages there were vigorous arguments against adopting it, but logic and reason are no match for fads backed by large corporations motivated by “innovation”, and quarterly results.

In proposing to use xml as the common “language” of security policy the authors of the specification write the following:

“XML is a natural choice as the basis for the common security-policy language, due to the ease with which its syntax and semantics can be extended to accommodate the unique requirements of this application, and the widespread support that it enjoys from all the main platform and tool vendors.”

This is specious reasoning if it can be called reasoning at all.  Can anyone show me a text based format that can’t be extended to accommodate the requirements of an application? In the second half of that sentence they note that xml has widespread “support.”    Socialism had widespread support among the intelligentsia,  but it doesn’t work well either.  To exchange data we only need to agree what to pass and what it means.  All real meaning exists in the hemispheres of the brain.  Since logic ignores context, the meaning is documented so we are not left to speculate.  If that view, that concept is missing we are stuck with speculation.  Anyone who has tried reading uncommented code or peered into a database without knowing the conceptual model, know this well.  Nearly all the early claims of xml’s benefits (especially about meaning and tags) have been abandoned and we are left with these two, everybody does it and I can make it do anything.

A while back there was a question posted on a Linked-In group titled “Is Role Based Access Control a dead end and Rule Based Access the future?” inevitably several said the answer to the problem is XAMCL. I don’t think so.  What drives the problems with role design versus using rules are really fundamental philosophical questions of categorization and classification (distinctly different concepts) and how we manage complexity.  To say the solution will be adapting yet another complex xml standard is laughable.  It really shows that one does not understand the fundamental nature of the problem. Maybe xml is the way to go but I doubt there was much reflective thinking before they started writing.  My best guess is that XAMCL will be as widely adapted as SPML and most likely will spawn efforts like this for the same reasons.

Challenge 2:  Fragmented Documentation
The documentation for accomplishing end to end workflows is scattered across many different documents.  There are few scenario based use case “how-to” documents.  Companies deploying NetWeaver IdM 7.1 will want to permit sufficient time for their deployment team to work with the product in order to gain a full understanding, before undertaking a deployment.  Alternatively, companies can bring in outside experts to assist, and train personnel.

Challenge 3:  Limitations in the Staging Environment
NetWeaver IdM 7.1 uses an xml export file to move from development to Test and Test to Production.    The file is exported using a built in utility.  The file is created within the identity center by selecting export.  Many settings between environments are not exported for example, repositories, event agents, provisioning/deprovisioning tasks on privileges must be done manually.  There are some bugs, for example, complex linking between tasks are sometimes broken during import.   These limitations can be mitigated with manual adjustments but the process is lengthy.
Challenge 4:   Job Customization Frequently Requires Custom JavaScript
Under NetWeaver IdM 7.1 the imported “SAP Provisioning Framework” has greatly simplified system deployment, however, there are simple functions, for example, E-Mail notifications which still must be done entirely in JavaScript.  This also applies to any non-simple data modification.   This slows down deployment.  The alternatives are to custom development Java templates or wait for the product to mature.

Challenge 5:  Few Useful Reports Available in Default Installation

Most of the default reports available lack the simplicity of being able to easily show standard audit information like “who did what to whom and when”.  Although extensive audit information is stored the database, it is not always easy to extract the data without extensive SQL queries.  The documentation itself does not clearly explain the complex relationship between the data in the tables.  There are no shortcuts available , careful analysis of the underlying tables and proper query writing must be done.

NB: Since I am on a project and can’t go to Tech Ed watch Matt Pollicove’s blog for updates on whether these challenges are being addressed.

I am now posting a stronger model that is complementary to the other one and can be used for other initiatives besides IAM.    It combines real options with Knowledge Value Added (KVA).  The methodology is derived from the work of Johnathan Mun so if you want to go back to the source start there.

As side note, some people think it is foolish to share methodologies that you have developed and all the big consulting firms protect theirs.  A methodology is just a process, and the only thing that matters is the execution of it.  It can be downloaded at the Risk Horizon website here.

And there is an additional “ONE TIME OFFER” from SAP: Every company that signs a certification agreement in the category “NW-IDM-CON” before December 31^st. 2010 will receive a 20 percent discount on the certification fee.

At least you are getting the certification discount;  I suppose you can then sell your connector to others after achieving certification.  I wonder how many “uncertified” connectors will start to circulate that people will write for their own use.   At times it seems that SAP is entirely driven by revenue generation.   I can’t help but wonder how better off they would be if they actually encouraged a vibrant developer community.

I haven’t had a chance to review the kit yet but having worked on custom jobs under 7.0, the documentation has to be better than just javadocs.

The most accurate answer could be had by having people wager on the best product as measured against a set of metrics.  When people are asked to risk their own money, it becomes more than a trivial exercise.

Exception from Modify operation:com.sap.idm.ic.