Tag Archives: EA

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!

How to recover the Gap between Business & IT?

Why does the Gap between Business and IT exist?

I’m sure you will find people who will try to convince you that there is no gaps between business and IT. But, I can give you my piece of advice, it’s been quite many years now that I am working in this context and I can tell you, there are gaps… I am even use call to call it a schism sometimes. But let’s look at why does this schism exist? If we want to treat it, don’t we have to identify the origin of the problem? Since we are Enterprise architect, it is always put forward that we are here to “align the business and IT”, so let’s look at the “what do we have to fill to align them”.

When it comes to improving enterprise performance via technology, IT and the business usually approach the same problem from two vastly different perspectives.  As a consequence, on one hand, business people often lack an appreciation for the IT technical ramifications of adopting a new process. On the other hand,  technology and IT teams usually find business requirements unrealistic. Of course, if both parties are unable to bridge that gap in a highly collaborative way, the consequences can be significant.

As an example, consider the scenario in which the business makes what it believes to be a simple functional request: “I just want to have this function in my application. I would make my life easier”… Then, only to hear back from IT that this request will take six months to be delivered. While it may be true that there are substantial technical implications associated with specific business requests, IT should not expect business users to understand the full impact of all the IT management details – and it isn’t necessary for them to.

How to recover the Gap between Business & IT?

Better approaches would be:

  • For business, express and explain their needs, the reason why, benefits they are expecting… in two words: the Business Case (honest one, not a fake).
  • For IT to focus on translating the IT management details into business language, so business can understand what IT is saying.

A trap where business is too often ended in is to ask to IT a solution that they have already decided on their own. E.g: ” “I want to have this function in my application.” Doing that is starting it all from the wrong foot and can lead the whole project to huge consequences. My own analysis of this situation is the following: this is happening mainly due to that business doesn’t can/want to spend time to explain what their are already convinced at and that the trust between business and IT is missing from the beginning. So it requires some effort from business to express their needs and not the solution they want. But they are not the only ones who need to make some efforts…

IT has to make effort on its side as well. To start with, IT has to make sure that the thought solutions are really addressing the business real need behind.  Nowadays in many companies, it is quite usal to have IT having the mission to strive for commonality in IT solutions to support different business processes to be supported by the same service or at a lower level: function. Of course, the main goal here is to reduce IT cost. So,back to my first purpose here: to analyse business’ requests and identifying already existing/future services/functions which address the same kind of need is the IT mission as well. Of course, it will take more time to do it, but it is for the sake of the entire company, isn’t it? So what few months spent in a project compare to years of savings? This has to be evaluated and time/money spent to do this evaluation must be accepted by both parties.

So, to me it is a jointly (usually called “collaborative”) work to be achieved. If both parties succeed, first to work on themselves, change their initial behavior, then to work together, I do think that they will be both on a better shape to go for a success. Once IT fully comprehends what the business is trying to accomplish, it may be able to offer an alternative approach that meets the fundamental business requirements and it would even might be done in a shorter time frame at the end.

Opening

Working together on essential business capabilities instead of implementation details, IT and business can often identify solutions that blend the two perspectives. In fact, such collaboration often enables the business to leverage what IT knows about current capabilities or best practices in other parts of the organization. It requires both points of view to ensure that the approach will enable the business to meet market demands.
Further, this type of collaboration positions IT to lead the charge in looking for solutions that are synchronized with business needs. If IT can facilitate a shift in the paradigm to a form a cooperative relationship, both sides will gain in terms of efficiency and results. Rather than responding to requests from business, IT can proactively offer solutions and alternatives. Isn’t it what we are aiming for? So called, win-win situation…

Agile and Complex projects

Catching up with my posts… Here is the trigger of this post: an interesting twitter discussion with my #entarch fellow: @RSessions
mcgoverntheorymcgoverntheory: Most #CIO dont know how to deal with issues in #Agile projects. Troubled projects lead to a backlash against #agile approaches. Endless loop 12:17pm, Nov 01 from Web
RSessionsRSessions: @mcgoverntheory Agile methodology methodology doesn’t scale to complex projects. 12:37pm, Nov 01
enectouxenectoux: @rsessions Don’t agree. It all depends of the scale of the project and awareness of project members.
RSessionsRSessions: @enectoux The scale of the project is what I mean by it doesn’t scale to complex projects.
enectouxenectoux: @rsessions lol, ok then I agree :o) But “complex” is not equal to “large”, isn’t it? To me, a complex project can be a small ones as well and the #Agile issue is more related to scale (large /small) than complex
RSessionsRSessions: @enectoux But I believe Agile can be applied to large projects once we get their complexity under control.
enectoux: @RSessions Well, this time I fully agree.

@RSessions is much more knowledgeable about managing complexity as I pretend to be. If you are interested, you will find lot of interesting thoughts and information at his website: http://www.objectwatch.com/

My intention here is to dig a bit more into this “complexity thing related to Agile”. Basically, if we look at Agile’s manifesto, here are some of the main principles underlie in it (short extract):

  • Customer satisfaction by rapid delivery of useful software
  • Welcome changing requirements, even late in development.
  • Simplicity
  • Regular adaptation to changing circumstances
So, if we look at these principles, some of them will be very difficult to argue with when it comes to manage complex projects through Agile. Take the principle “simplicity” for instance 😉 or on the other hand, other principles like “adaptation to changing circumstances” are more in favor of managing the complexity.
My point is that we cannot state that Agile doesn’t scale to complex projects. It is all about how you can deal with complexity. How much you (as the project leader or project member) can deal with a complex situation. Are you afraid of complexity or are you comfortable with it? If you are comfortable with it, then Agile methodology can help you to manage your complex project, parallelizing activities, having short development loops, enabling you to validate your “still fuzzy” concepts by testing them towards reality quickly than if you were in a “not Agile way of working”. Agile methodology is, to me, very powerful. But, like any powerful tool, it has to be handled with care. It is very easy to get trapped when using Agile and then, blame the method. I’ve seen and I see it many times. Among the principles I mentioned above, two are missing in this list (but not missing in the full list):
Close, daily cooperation between businesspeople and developers” and “Projects are built around motivated individuals, who should be trusted“. these two might look obvious, but they are to me the fundamental ones. Without trust between IT and business in a Agile project, there is no way to make it a success. As enterprise architect, one of our challenge is to achieve “Business and IT alignment“.
There is many ways to try to achieve this alignment, but I think that one of the best one, when the trust is lacking, is to re-establish this trust by succeeding a complex project using Agile methodology. Then you prove what you prone  as “alignment of Business and IT” has a value for both and for the enterprise.
I have many examples of such projects, at different sizes. Some have failed and some have succeeded. But let’s me ask you about you’re experience. Try to remember, any good personal experience of using Agile methodology in a complex project and making it a success?

Top Four Enterprise Architecture Methodologies

Starting point

Few weeks ago, I was on business trip, dining alone at my hotel restaurant in Gothenburg (sad story isn’t it ;)) I was using my favorite device: iphone 4 to read interesting Enterprise Architecture articles & papers, when, suddenly, my attention was caught by a direct reply on one of my tweets from my respected architect colleague: Roger Sessions Roger asked me:

RSessions Nov 16

@enectoux Thanks for the RT! BTW, have you seen our article that describes the 4 Factors of IT Coherence? http://bit.ly/9nQ36W

Which at that time, I hadn’t  read yet. So, I decided to read it carefully, as it deserved to be and give some of my feedback / thoughts to Roger and you through my blog, since a tweet would not be enough.

Quick summary

So, to start with, not to mention that you should spend the valuable time to read Roger’s paper, which I don’t want to re-write here. Let me introduce it to you quickly. The title this paper is: “Comparison of the Top Four Enterprise Architecture Methodologies”  To be honest, this title is sufficient by itself to summarize the purpose of the document.

Through this paper, Roger gives us four very good overview of the top four  framework/process/methodology/practice: Zachman, TOGAF, FEA & Gartner, but in addition to this he also gives us some clues of what does each is good at (and not that good at, as well).

My points

This said, here are my points:

When taking each of these frameworks/process… separately, I always felt uncomfortable. While reading, I remembered when I was seating in TOGAF 9 training, having the feeling that there were things missing. I couldn’t explained it at that time, then I was missing experience in Enterprise architecture field and couldn’t step back enough.

As an example:

To my point of view, Zachman framework is more a reference to which you should compare with. What for? To benchmark in which Zachman cells you are currently missing documented knowledge in your EA work. Of course, this is not enough, once you did this first step; you need to set your priority accordingly to your strategic business objectives.

So if you take Zachman only and try to use it, first thing you will get hit by is that you are missing a process to do it… This is of course, where TOGAF is coming into the picture, bringing the process… So TOGAF is completing Zachman, good… but not enough – that would have been too easy –

Then comes FEA which brings a methods, yes, ok… but… still not enough. So there it comes, the big one: Gartner! Hurrah! We finally get it all, right? Of course not! But why? will you ask me! We have a reference model, a process to get the architecture up and running, and methodologies and then top of the world EA specialists… Well, there are different reasons why, let me gives you the main ones I foresee, with the help of Roger’s paper.

Why does each of the Top Four methodologies are not enough (taken separately)?

Roger Sessions: “TOGAF merely describes how to generate an enterprise architecture, not necessarily how to generate a good enterprise architecture.”

This said, there is nothing much to add about TOGAF.

To continue, a general comment on FEA, Zachman. These 2 are IT oriented frameworks / methodology (there is also a debate about TOGAF, but let’s no opening it here now). So, OK, we know that, but the issue I see is not that they are IT oriented, but the issue is that none of them are fitting with 201x enterprises’ challenges.

Zachman and FEA were designed to answer 1980’s problems and challenges. When it comes to TOGAF, as we’ve shown it above, it doesn’t answer to any other challenge than: create the architecture. Not saying that creating the architecture is not useful, but it is architect matter that is addressed, not the CEO’s challenges, such as: “enterprise profitable growth”.

So… you will tell me: “We need another framework / process / methods…” Well, here is a debate that deserves to have its own post (coming soon) We already have plenty of these (remember that here that Roger took only the top four used ones) and I don’t want to re-invent the wheel again, but obviously, based on what I just described taken separately each of these 4 attempts is not enough.  So, we need something to help us to manage the complexity of the “thing” (enterprise in our case), to fullfill the current challenges our enterpises are facing today and to get the Enterprise Architecture moving forward.

“Get the Enterprise moving forward (with the help of the EA)”

How should Enterprise Architects help their CEOs to get their enterprise moving forward? To start with:

Then, once it is done, let’s us come back to frameworks, process, methods, best practices… when it comes the time to choose, you will have difficulties to pick one of these since they are always missing one aspect. Then… what to do? In a first step, what is important is to know these methodologies, understand what they are capable to offer you. Then, the second step is to find your own way.

“Find your own way”

I know that for a structured mind as an architect is usually provided with, this statement will not sound “satisfying”. So let me bring you few additional points here:

  • The “best practice” is always your practice (because it’s yours!) Who else than you should know better than you what you need? Of course, you might need help to express it, we all need such help from time to time, but at the end, you must be the one knowing what you want to do, right?
  • When it comes to choice and getting thing done. This is where we should stop (for a while) to structure things. Remember Gartner quote: “Just enough Enterprise Architecture, just in time”. To me, this also means that we need to keep space for “not structured thinking” (cf. my post about non-linear thinking) in order to keep freedom for creativity and get innovative.

Because yes, innovation is one of the KEY for your enterprise to get through and progress. Let’s us stop here for today. Next time I will tell you more about “my way”…

Why doing Enterprise Architecture?

You cannot effectively manage something if you cannot “see” and understand (know)!

Especially if it is big, complicated, or will grow and change at some point in time, or if  you need to communicate accurately with others about it.


The Cost of an error

There we are, in the heart of the topic! Money, save cost…

As you figure out with this simple chart, this is common sens, the earliest you are able to detect and error in your strategy, the most money you will save.

So, how will Enterprise Architecture will help you to save money?

Enterprise Architecture is the underlying design or structure of anything:

  • It exists whether or not  it is made explicit (know).
  • If it is not explicit, assumptions must be made.

If explicit, Architecture is…

  • “The set of descriptive representations about an object…” John Zachmann
  • A model or representation of an object created in order to…
    • “see” the object,
    • “communicate”with others about the object,
    • “do” something with or to the object: create, manage, evaluate or change it.

As a final thought for this post…

Enterprise Architecture is the underneath work that support any kind of Governance. Without such approach, Governance is blind or in the case relies on “convictions”… The issue with convictions is that, in some cases, they can blind us as well and keep ourself in a box. In this case, of course,  convictions  are quite dangerous especially if they are not challenged by facts that are partly brought by Enterprise Architecture.