Enterprise Architecture training-course | Tom Graves / @tetradian | @scoopit http://sco.lt/98hpqr #entarch #Training
Good article initiated by Henrik Liliendahl completed by the very good comment of John Owens. I decided to re-blog it in order to continue and complete it. As John Owens mentioned, “QUACKs (Quack Alternative Codes & Keys, also called Structured Codes) are a very useful way in business of referring to a frequently used entities, such as products, locations, etc. The problems start when data analysts confuse them with Unique Identifiers and then system designers further compound this error by implementing these QUACKs as Primary Keys in tables. This embeds a flawed data structure into every single record that is created in which these flawed primary keys are used foreign keys, for example, in tables linking a flights to St Petersburg airport. Now, had the designers used an unstructured Primary Key and shown “LED” simply as a QUACK referencing the Leningrad/St Petersburg airport, the code “LED” could at any time have been very simply changed without in any negative impact on referential integrity in the data sets involved. All past and future flights would automatically reflect the change in the airport code. The reason the code LED is hard coded in this way is not an innate part of MDM, it is the result of bad data analysis and worse systems design. A major part of current MDM is to move the knowledge, practices and skills into enterprises to enable them to avoid to making these totally avoidable and hugely costly errors.” All of us have faced this kind of problems, consciously or not. This can be a very big issue especially when having very tightly connected legacies. Such original mistakes can lead to decades of re-engineering, trying to decouple legacies in order to be able, later on to bring more flexibility. As you may notice, this is a 2 steps approach that does not bring any business value first – while decoupling – and might bring a Return Of Investment 3 or 5 years after the initiative has been started… This is the main reason why, most of these initiatives are never started!! Actually, the only cases I’ve seen such projects initiated – to try to correct the initial error – was due to an unique phenomenon called: “hit the roof”. “Hit the roof” is a side effect of mainframe developers usage, who most of the time were the same ones who did the initial error: “using the QUACKS as primary key”. “Hit the roof” is quite simple as well, after several decades of usage, some QUACKS table value reach the end of the range. We could take the previous example – the airport code based on 3 letters, with one assumption: only letters, no numbers. It gives you a total of: 13,824 possible airports, which might sounds reasonable if we think about the main airport, but which will be quickly reached as soon as you include the small aerodromes into the same table… I guess you saw me coming!! :) I am not an airport specialist, but I am quite sure that some politicians will have this brilliant idea, one day or another – if it is not already done – to have a common repository (Table) for all airport and aerodrome of the world… Then, we will hit the roof! Ok, very good that we “hit the roof” you should tell me, finally, it gives us the opportunity to correct the initial mistake… Well… I won’t be so optimistic if I were you, even though if I agree with the reasoning: having a golden opportunity to put things back into order… Most of the time, the “solution” that wins is the following: let’s introduce numbers in the 3 digits code that we got! Wouhou! Jackpot! We increase from 13,824 values to 39,304… And that will cost only 8 to 10 millions $ to the company!!! You think I’m joking, unfortunately I am not. So, what to do then? To start with, the less silly solution is to create “Alias” to smoothly (can take years of continuous efforts, depending on how much your systems are “connected” to each others) move from the “QUACKS ID” that was initially set to a real (dummy) object ID (primary key). It is not the silver bullet that some might look for.. but it’s the only reasonable way forward I know about. Any experience to share on this topic?
Originally posted on Liliendahl on Data Quality:
All airports have a tree letter code usually being a mnemonic of the city name or airport name. The airport at Saint Petersburg in Russia thus has the code LED because the code was assigned when the city was called LEningraD. That’s how it is with master data: Names may change but the code of an entity must be kept as it was. And that’s why you usually shouldn’t put meaning into codes.
The Russian MDM (Master Data Management) market has been well described by Dmitry Kovalchuk in a post on the Hub Design Magazine.
This year I had the pleasure of celebrating New Year in Saint Petersburg, a city with great palaces from the time of the czars and czarinas and a growing awareness of Master Data Management including some very interesting start-ups around MDM, where I had the chance to visit TaskData
View original 19 more words
Strategy, Leadership and the Soul - Jennifer Sertl and Koby Huberman
Have a quick glance to the following appetizer:
Strategy, Leadership and the Soul presents a new paradigm for organizations. Jennifer and Koby present a stunning analysis of the dynamics of organizational evolution since 1850 to the present day, reflecting on how the context of the changing nature of society over time has informed the necessary adjustments in structure and leadership, and in what way these have been vital to the sustainability of those organizations. The current quixotic context for both small and large organizations – the rapidly changing business landscapes, global inter-connectedness, technological innovation and the diversity of the needs of customers and employees alike – requires organizations to ‘be in a state of permanent transformation if they are to survive’, to become transorganizations.
Most of the all, in order for these transorganizations to survive, a new style of leader is required - a transleader – now my twitter followers know where does my #Transleadership comes from ;) !
The qualities needed for this transleadership style are:
- the ability to communicate with passion and clarity
- to develop a shared language that can transform the thinking of everyone working in or with the organization
- to inspire self-confidence and knowledge to strengthen teams
- to share power, and give greater control to the workforce to behave like mentors rather than bosses
- to welcome diversity
- to have an exceptional level of self-awareness
- to be able to transcend culture, age, and title as a means to arrive at what is relevant
Aligning the values and beliefs of the transorganisation and the transleader is a key feature of this new paradigm. Transorganizational strategy must be similarly aligned, with an agility and flexibility to allow for an unlimited number of possibilities. Without this, organizations become dysfunctional and will be subject to a very real chance of failure.
The soul of an organization is the intrinsic corporate identity that underlies all that it does, that informs its business practices, its aims and goals, its internal and external relationships and its intangible sense of direction-shared in an aligned way between its employees, its managers, its shareholders and its business partners. It is the extremely present and powerful set of beliefs that make the organization what it is. This is not the same as superficial PR or the ‘image’ on advertisements, nor is it just brand identity or corporate culture, but the identity that defines and aligns the relationship it has within the various sectors of the organization and in its interface with the global community.
Strategy, Leadership and the Soul provides a new paradigm and a practical guide to the personal and the organizational adaptation needed to meet the challenges of the future.
Do yourselves a favor… Read that book!
While I am preparing to publish my next article on Information Management and taking the opportunity of a email discussion with Jean Evelette – the author of the very interesting website MARS – Metadata And Repository System - I realized that a clarification regarding information ownership was needed. Here is the famous question:
Who is owning the information?
I will not go into the philosophical debate whether or not the information should be owned…. Let’s say that for a practical matter, information needs, at least, to have a responsible at each point in its lifecycle (note that the responsibility may change overtime).
Such question deserves me to answer in 2 steps:
First, refering to my previous post: #INFOARCH – POST 2. THE STARTING POINT, the enterprise CIO is the owner of the Information Framework. The enterprise CIO is the Responsible (see RASCI model) to make the “implementation of the Information Governance accordingly to the defined Framework.” happen. e.g.: the CIO is the one responsible to have core information owners appointed (so called Master Data in our context – see the following post: MASTER DATA – SHORT DEFINITION ).
Then, this “owner” term is really sensitive especially since with the ownership comes the responsibilities… Most of the time, should I say always? ;), when we mention ownership, the discussion between who is owning what is coming right away…
The answer is quite simple to me:
Of course, the content (that we could also call “value” from a coder perspective ;) ) is to be owned by the “Business people” (such as R&D engineers, buyers…)
But, in the other hand, the structure of the information (cf. its metadata and the way each information objects are connected to each others – so called information models) is to be owned by the CIO’s organization.
So, yes, at the end of the day, it is a shared responsibility that we are talking about. Shared, but not blurred responsibility, each party has a very clear and defined responsibility mission (see above). As always, one of the key is that each party stick to is own responsibility, without trying to fool his/her partner by either trying to overtake his/her counterpart responsibility or on the opposite way: trying to push his/her partner his own part of the work (without formal agreement/delegation first).
Having this in mind, you’ll be ready for my next post… coming soon :)
General Note: I use Information instead of “Data”, this semantic difference is important since I am distinguishing between several levels of Information, the classical: Conceptual, logical and physical levels, where the Data is at the Physical level only.
Way too often neglited… The weekly review is a fundamental practice to keep “in the train”. Personally, I save 2 hours every Fridays’ afternoon for this, doing my best to protect them against late meeting requests and other disturbances.
Originally posted on GTD for CIOs:
At this time of the year many people want to get back on the GTD bandwagon because they are in a reflective mode of self improvement. They know it works and know the stress reduction it can provide. They know when practiced diligently it can provide what David Allen calls “Mind Like Water.” When you are in this state you can feel great about where you are, what you are doing and what you are not doing. For anyone who has experienced this feeling it is amazing and they want to get back there.
So many people ask me how they can “really do GTD right this time?” Like a diet or a new year’s resolution, they really want to be successful, but deep down fear they will fail over the long term. The want a magic bullet or trick that will help them to succeed with GTD over the…
View original 707 more words
Originally posted on loppysmile:
Most strategies fail.
Rewind. Most marketing and comms strategies fail.
I’m not saying they don’t have an impact. What I mean is, most fail to achieve their stated outcomes. Downer.
A lot of the time, we’re never forced to recognise that our pretty little diagrams amounted to jack. We pump out a few vanity metrics to bamboozled managers or clients (talk about reach, interaction and so on) and everything is rosy.
But if we really analyse – with cold, hard eyes – the impact of our work, we usually find we didn’t quite achieve what we said we would.
Why? All sorts of reasons. But here are three common factors.
- bad strategy
- crappy execution
- lack of resource
Today, I’ll take a quick look at strategy (I’ll look at execution and resource in a couple of follow-up posts next month).
A blog isn’t the right place to debate strategy in depth. But…
View original 381 more words