poem Geo

GEO

Face to face behind
pointed pistols we shake and
resume discussions.

imho Arch of Governance pt 3 of n

All:

Found content:
http://www.dataflux.com/blog/archives/2006/04/10/defective-definitions-of-data-governance/
http://www.dataflux.com/blog/archives/2006/03/27/some-general-tips-on-data-governance/
http://www.dataflux.com/blog/archives/2006/04/07/roi-for-information-governance-think-strategically/

My take:
Here’s where I attempt to discuss governance as it relates to my core coverage domain: data management.

Data governance is a new buzzphrase with legs. I notice that three other industry analysts are posting to a blog sponsored by a data management vendor, and that they’re all tap-dancing around the topic of data governance…none of them has produced (in that blog) a clear definition of the term, though they’ve gone on at some length regarding the value of data governance, the “what’s it’s not” of data governance, the “what it sorta overlaps with” of data governance, and so forth.

I’ll back into my own definition of data governance. First, I’ll revisit my definition of federation, as one broad category of governance structures:

• “Federation is a governance structure in which autonomous domains choose to honor each other’s decisions and accept each other’s assertions in some realm of human endeavor—such as identity management, data management, or SOA management--subject to business contracts, trust relationships, interoperability agreements, and local policies.”

I implicitly describe “data management” as a “realm of human endeavor” to be governed (i.e., controlled). And I define governance in another post as:

• “Control structures on human and automated interactions, some of which emerge from the blur of decentralized, autonomous decision agents, and some of which are imposed by centralized authorities.”

Leveraging, converging, and extending these definitions, I define data governance as:

• A control structure on human and automated interactions within and among data management domains, addressing the full life cycle of functions necessary for comprehensive management of data as a business asset.

I have spun my own alliterative string of verbs to describe the various life cycle functions managed by a data governance environment:

• Mapping, modeling, and marking up data
• Moving and migrating data
• Massaging and manipulating data
• Massing and mastering data
• Monitoring and measuring data
• Mobilizing and extracting meaning from data

And so forth. Mmmmmmmmmmmmmmmmmmnemonics. Governing anything involves getting your head around a single conceptual model of the entire domain. I parse every data management vendor, architecture, approach, product, etc with this ontology in mind. ETL? (that’s primarily moving and migrating data). Data warehousing? (that’s primarily moving and migrating, massaging and manipulating, massing and mastering data). Business intelligence? (that’s primarily mobilizing and extracting meaning from data). DBMSs? (a bit of everything, actually). And so on and so forth.

Data governance is being used in the same breath as master data management (MDM) to describe this entire life cycle of data management functions. Now, repeat the mantra: mdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdmdm.

Jim

imho Arch of Governance pt 2 of n

All:

Found content: http://www.computerworld.com/managementtopics/management/story/0,10801,110436,00.html?source=NLT_APP&nid=110436

My take:
Hard to tell whether we’re twisting the concept of “governance” beyond its natural breaking point…but here I’m testing the tensile strength of the concept in yet another context.

Governance is control, implemented by hook or crook, proactively and/or reactively. The referenced article--“Why achieving SOA quality can be so difficult” by Shridhar Mittal--is an excellent discussion of software QA challenges in the “composite…distributed…heterogeneous….dynamic” SOA world. Here’s the graf that jumped out at me: “Application quality is fast becoming the primary governor for achieving companywide SOA success and deployment. With so many interconnected parts making up applications that can be delivered virtually anywhere, testing no longer becomes a mere matter of finding bugs within the developer's code or problems that occur on a given user interface. Software quality processes must evolve with the architecture to genuinely test a business process and maintain context across the entire workflow.”

Governor…governance….hmmmm. In the previous post, I implicitly defined governance as “different control structures on human interactions, some of which emerge from the confusion of decentralized self-interested interactions … and some of which are imposed by very visible iron hands.” Perhaps I should generalize this discussion to refer to “control structures on human and automated interactions, some of which emerge from the blur of decentralized, autonomous decision agents, and some of which are imposed by centralized authorities.” Yeah…that’s the ticket.

Governance is often event-driven: you see an exception condition (such as a software glitch or DDoS) in development or operations, and you implement a remediation and/or enforcement action to address it. In my discussions with the industry, everybody keeps bringing up the following lifecycle of SOA governance activities: design-time, deploy-time, run-time, change-time (or optimize-time, which is essentially a return to design-time, but incorporating SOA operational metrics from run-time into tweaking the production SOA).

Ideally, QA should be an activity that transcends all of these “times.” You should look for glitches and bugs continually—in development, when the software is being deployed, and in normal operations—and address it continually, sometimes fixing it on the fly, sometimes decommissioning a software component so that it can be fixed “out-of-band” while you implement a workaround. Your SOA governance toolset (i.e., Web services management in operations + visual design and policy administration tools in development shop) should provide you with the ability to test for, detect, and fix these issues at any “time.”

SOA governance involves continuous interaction testing that permeates the entire environment at all “times.” As the article states: “Comprehensive regression testing and runtime monitoring across this distributed environment is critical to maintain the integrity of the application….When teams truly collaborate and continuously automate tests against every layer of the SOA, companies can more reliably wrest value from today's complex, service-oriented business software.”

QA-driven SOA governance, then, is both an automated background activity and a very human collaboration operation that never sleeps.

Jim

imho Arch of Governance pt 1 of n

All:

The current meditation started when I accepted the position of principal analyst with Current Analysis.

Surveying the vast domain of my focus area (data management) and just following a long DRM sequence, it occurred to me that DRM is what you might call a use case of “data governance”: “flexible deployment of content-control policy-enforcement logic throughout networks” (hence sort of under my current coverage scope; in fact, you may notice this in the previous post: “governance of … distributed data…in the form of a corporate-standard master data management (MDM) environment”).

But governance sprawls across many coverage areas, including information security (“heavyweight content security, policy, trust, and key management infrastructure that will inevitably be embedded everywhere”), which is the province of my colleagues Andrew Braunberg and Charlotte Dunlap. It also fits squarely into the SOA governance province of my colleague Shawn Willett.

Regardless…no need to feather my overcrowded nest any further…this concept of governance keeps creeping into my thinking on many topics. Federated identity, for example. In a November 22, 2005 post, I list one of the elements of federated IdM patterns as “federation governance,” with the alternatives of “bilateral trust agreements” and “multilateral agreements.” (Yes, I am using my blog as a memory aid).

And on January 27, 2005, I posited the following “laws” (normative) of “identity governance”:

• Law of identity federation: Domains must be able to establish trust relationships under which they can choose to accept each other’s identity assertions and honor each other’s identity decisions--or reject them--subject to local policies.
• Law of identity assurance: Entities must be able to unambiguously ascertain, resolve, and verify each other’s identities, and reserve the right to refrain from or repudiate interactions in which such assurance is lacking.
• Law of identity self-empowerment: Humans must be able to self-assert their identities, and reveal or conceal as much or little of their identity as they wish, at any time, for any reason, from any other party, for any duration, and also to unlaterally defederate from any domain that deliberately or inadvertently compromises or violates these rights.

All of which brings us to the core issue (of this post at least). What exactly is “governance”? And what exactly distinguishes it from “management,” “administration,” “access control,” “federation,” and other related terms of art in this industry? Is “governance” simply another empty fuzzword coined to give the false impression of new substance?

It occurs to me that, in IT contexts, “governance” is usually used in the same breath as “federation.” And both terms are used in contexts in which responsibility for some functions (e.g., authentication, authorization, etc.) is decentralized across two or more autonomous peer sibling domains. In other words, governance as barely controlled anarchy. As an alternative to centralized, command-and-control environments, in which there is a parent/child relationship between domains (in other words, hierarchy, aka big G Government).

But of course, some use “governance” to characterize all options on the spectrum from anarchy to hierarchy. All of it describing the different control structures on human interactions, some of which emerge from the confusion of decentralized self-interested interactions (e.g., Adam Smith’s “invisible hand”) and some of which are imposed by very visible iron hands.

If we take the most global definition of “federation,” we can describe it as one type of governance structure, to wit:

• “Federation is a governance structure in which autonomous domains choose to honor each other’s decisions and accept each other’s assertions in some realm of human endeavor—such as identity management, data management, or SOA management--subject to business contracts, trust relationships, interoperability agreements, and local policies.”

Or you can characterize federation as governance built up from contracts, and the alternative (hierarchy) as governance handed down from constitutions and covenants. Contracts vs. constitutions: horizontal vs. vertical policy envelopes: negotiated vs. decreed governance environments.

All a part of the art of governance. Or the arch of covenants.

Jim

poem Character

CHARACTER

Character is caricature.
It exaggerates, and becomes.
Becoming your blunt summation
in the act of unbecoming.

fyi German Bank Fights Phishing With Electronic Signatures

All:

Found content: http://www.computerworld.com/securitytopics/security/story/0,10801,110054,00.html?source=NLT_SEC&nid=110054

My take:
Fight phishing with common sense, not electronic signatures on e-mails and websites….OK, use the latter as well, if you wish…but if you’re like me, you’ll:

• Use online banking as little as possible….direct deposits for regular paychecks and direct debits for regular bill payments are totally automated…which eliminates most of the need to visit a physical or online bank
• Believe no e-mail that purports to come from a financial institution, including those in which you have accounts…and doubt whether there might ever be legitimate circumstances under which a financial institution would ever send you an e-mail to notify you of some account-related event or anomaly….and tell all of your financial institutions in no uncertain terms that monthly statements and all other official communications must come from them via postal mail, printed at their expense, on their letterhead, and on a regular schedule, to your permanent street address.
• Tell your legitimate financial institutions that, if there’s a serious event-driven issue concerning your account (e.g., overdraft), they will have to contact you via phone…so at least you have some evidence that somebody somewhere spent sufficient resources (to print and mail paper and/or to have a human being call and talk) to discuss something of critical importance to both them and you….even though scams also make use of the phone system on occasion.

Make the scammers really work if they want to separate you from your assets, through online or other approaches.

Asking you to periodically “verify” existing account information online is a crock….you verify it implicitly every day by going about your life as usual and not noticing anything out of the ordinary with your checking or brokerage accounts….accept that you’re responsible for checking your statements every month, and that no legitimate institution will prompt you to exercise that responsibility….banks don’t call you to ask if you received and have reviewed your printed-out monthly statements…or balanced your checkbook register….do they?

Asking you for your password so that they, the “institution” that supposedly manages that account, can manage it is also a crock…if their “employee” or “representative” doesn’t already have full access to your account information, that’s their problem, not yours…they’ll have to prove that they have sufficient information on you already before you even begin to speak to them…if it seems like they know nothing about you, clam up…if they can’t even tell you what your current mailing address is for the purpose of verifying it over the phone, then they have never mailed you a paper statement…which means they have never actually established a real relationship with you…which means they’re a fraud…they don’t have the nucleus of an “identity system of records” on you, or can’t match up the data in their iSoR with the equivalent data that only you have possession of…they’re obviously fishing/phishing for that data…don’t give it to them…close your browser and/or hang up…

Asking you to verify an electronic signature on a financial institution’s e-mail or website strikes me as a bad idea. They're putting the burden on you, the customer, to verify the authenticity of the institution that purports to have sent you a message or operates a website that you’re visiting. You have to do all the work, per the referenced article: “Under the Postbank certification system, users can verify an e-mail by clicking a certification symbol, which, when opened, provides details about the signature. A warning symbol appears if any inconsistencies arise during the signature authentication process.”

When the customer has to do any work at all to verify an electronic signature, you can best believe that most customers will do nothing. Which means that there will still be plenty of scams that use electronic signatures to convey the illusion of legitimacy, and that verify few customers will actively “verify” these signatures. And that few users who do attempt to verify the signatures will know what to do with the information that the signature system presents to them.

The more I stare at the following two statements from the article, the more they bother me:

• “users can verify an e-mail by clicking a certification symbol, which, when opened, provides details about the signature.”
• “a warning symbol appears if any inconsistencies arise during the signature authentication process”

What “details” are presented about the signature? Will it tell me that a certain “E_Trade” (scammer) that signed a message or webpage is not the same as the “E*TRADE Securities LLC” that actually manages my accounts? Would I pay attention even if it told me? Who actually keeps track of these typographic differences between alternate possible versions of these concocted corporate names anymore (Yahoo vs. Yahoo!...yeesh)?

What “inconsistencies” might arise during the signature authentication process that would make the recipient have second thoughts about trusting a message? Pharming thrives because people blithely ignore the inconsistencies or discrepancies between an authentic financial institution’s URL and the one that pops up in their browser (to which they’ve been redirected, possibly, by a virus planted on their PC). Might malware also hijack your PC’s electronic signature software and produce bogus “everything’s cool” messages that hide any “inconsistencies” in the signature verification process?

So, in summary: Paper is safer. Letterhead is a better bet. When an institution commits ink to pulp and regularly sends it out, it shows that it holds your master account data. That it’s working hard to hold your confidence and continued patronage. That it isn’t waiting for technologists and lawyers to get the kinks out of electronic signatures.

Jim