Tag Archives: architecture

MDM in LED

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?

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.

Europe by Midnight
First sight of Europe 2014.

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 post 19 more words

Advertisements

Next generation of Enterprise Architecture

Early this morning, while glancing through the latest tweets on my iphone, I was attracted by last post from Richard Veryard on slideshare:

Preamble

Good slideshow though, but since I felt that it is going a bit in many different directions, I felt that I had to react on this one, directly on my blog to reflect my own thoughts regarding: How should we deal with enterprise architecture in big companies? Richard starts his slideshow by exposing 2 historical views of Enterprise Architecture: the “Simplify and Unify” view and the “Differentiate and Integrate” view. Structuring the begining of his presentation through this split, Richard starts quickly to mention ancient approaches such as “Information Engineering” structure versus the well-known “Zachman framework“. then, he also mentions the different trends / challenges the EA is facing to… But, finally, what is the main stand-point that comes out of this presentation? To be honest, I miss a bit Richard’s stand point at the end of the presentation. So here is mine (stand-point):

My point is…

I would say that, in general, I try to learn from history and experimented people such as John Zachman and Roger Session, but at the same time, I don’t want to follow them blind. I think times change and EA has to change as well (even quicker).
To me, such approach as Zachman’s framework, which is a 198x’s vestige (see my article: Top Four Enterprise Architecture Methodologies) or trying to simplify the IS way too much, when if fact we, as Enterprise Architect must admit/deal with this complexity (up to a certain point). We (EntArch) have to make this complexity manageable and introduce enough flexibility in it to better support the business objectives.  Not saying, as I mentionned earlier that we should forget the previous frameworks or structures, but more to know them, understand their points, why they raised when they did and look at today trends/issues to make our own opinions.

Then, let’s re-invent the wheel again will you tell me… No, sorry I am not this kind. I looked for a real EA methodology for a while before finding one that suit the best to my personnal beliefs. To me, the Praxeme methodology is the EA methodology that suits the best to my personal perception of what the EA should be/do.

There I think that Praxeme is fully supporting the EA challenges Richard is pinpointing. (see fig. 1)

My Conclusion

I would quote Richard when Richard writes:
“Not suppressing complexity but managing complexity”

This is exactly what I am trying to do when practising EA. EA should not be done for the “beauty of the move”, but for the whole-of-the-enterprise sake and benefit. To add to Richard’s presentation, I would say that in order to “manage the company IS complexity and support business objectives“, we need both the theory and the practice. There,  it’s time to mention Emmanuel Kant that is underneath the Praxeme’s approach:

Theory without practice is useless; Practice without theory is blind.

Let’s come back to the title: “Next generation of Enterprise Architecture”. To me the next generation of Enterprise Architecture and as a consequence: Enterprise Architects :D, where I expect from myself to be a key player ( 😉 french humor) is based on a true Business approach. We, as Enterprise Architects, have to get our key business decision makers to understand the value of spending money on EA to gain money on the maintenance (IT costs), reduce the project failure rate… stop re-doing project to achieve the same goals without succeeding each time.

Once your top management is convinced, then it is time to go to work. Start from the semantic level to keep the flexibility in the whole enterprise system. Break the silos, avoid hard-coded business rules that have lead us to where historic companies are entangled in today. Complex and frozen Information System that is not anymore able to support the always moving targets of our companies, neither the economical volatilities that we are currently facing or the increasing competition (to mention a few…). Our companies have no choice to evoluate or die. This is pure evolution theory.

  • If you are lucky and work for companies like Google or Apple, then you have not much to achieve in the first hand (convinced your management), mainly because the top management is already convinced and they have trusted the vision I described above. In addition, they didn’t have to manage the complexity coming from all the heritage of ages (usually called “Legacy”).
  • In case you’re not working for Google or Apple, then you are even more lucky! Look at all the interesting job you have in front of you! I use to quote Booker T. Washington when saying:

“You measure the size of the accomplishment by the obstacles you had to overcome to reach your goals.”

So, let’s go to work!