Gastautor(en)
Tuesday May 27th, 2008

Objects, Entities and “Impedance Mismatch”

Summary: “Entity” and “Object” are the keywords of this article. The differences between these concepts are well known, the catchword for that is “impedance mismatch“. This text, however, highlights their basic affinity and shows how this point of view may contribute to conceptual clarity and a reduction of modelling costs in IT-projects.

“An entity is an object that doesn’t know how to behave”. This is just one way to answer when asked to describe the connection between objects and entities. You may get other answers, a smirk for instance. Between object and entity there seems to be some sort of divide: “Entity” smells stale whereas “object” indicates modernity. Most current ideas and discussions in the domain of information technology use an object oriented approach and a vocabulary which differs in many aspects from the mindset associated with the notion of “entity”:

Table concerning „Impedance Mismatch“

Entity Object

unit of work

set

single object

perspective

database

application

style

declarative

procedural

identification

subject matter

technical

data structure

flat

nested

The table names some of the differences while Charles Bachmann’s one-liner at the beginning stresses what both concepts have in common. The latter is what this text tries to explore. (Bachmann is known for one of the first modelling tools.)

A thought experiment: You are to build an application within a domain of your choice. Sketch a class diagram for that application, and then an entity-relationship-diagram. Or the other way round – start with your favourite approach. Then compare your classes with your entities.

My result: There is considerable agreement in an essential part of the diagrams. There are “boxes and lines”, there are “numbers” along the lines. Some of the object-oriented boxes carry the same headlines as their entity colleagues. In those places the two networks of lines fit very well together. So does much of the content of the boxes: the data elements. The classes, however, contain more entries than the entities: The latter lack the “methods” or operations and so are unable to express behaviour – that is what Charles Bachmann’s one-liner says.

Now let us have a look at those parts of the diagrams where there is no agreement.

Object but no entity. Consider the objects without corresponding entities. These are meant for processing data or interaction with the user. In the object oriented approach the window on the computer screen is an object, too. Entities, however, usually end up in the database and that is why such objects do not show up in the entity diagram. So we can say that the class diagram covers more ground than the entity-relationship diagram does.

Entity but no object: Conversely, you will find entities, but no corresponding object – at least at first glance. Looking closer you will find the missing data as parts of other objects. The object oriented approach allows nested data, whereas data in entities are flat. Nesting of data, however, comes at a price. We will return to this topic.

Objects are generalized entities: That is what we can conclude from what has been said so far. Small wonder: Entities were invented years earlier than objects. But the concept of “key” has been lost on the way: An object is an entity looking for its key …

Keys help clarify things: A key uses subject matter information to define what constitutes a duplicate and what does not. Whoever has engaged in defining keys with the future users of an application will be glad to have a coherent way of writing down the results. He will surely want to look them up afterwards. And he will be grateful for the effort to have taken place before much code has been written – especially if he is responsible for the budget.

Objects are numbered serially, so the above discussions will probably pop up later, perhaps too late.

Later in this text we will come back to this topic from a different angle. For the time being, we will look at practical reasons to wish for continuity between object and entity.

An extreme Example of “object equals entity”: Some time ago I had the opportunity to attend a presentation of a tool that generates code. You specify a graphical model of your application, plug it into the generator, which presents you with a working Java application and a restricted set of operations (create, retrieve, update, delete). The participants of the presentation were asked to vote for new features. The result: A database reverser. Its task is to extract the data structure from a live database and to convert it to part of the input for the generator. Not much more is needed for the generator to produce its Java-application. You can use the generated code as a basis to fill in the missing operations manually.

Whoever asks for such a database reverser must concede that for practical purposes it is quite irrelevant whether the box in the diagram is called entity or object.

Data modelling with object oriented tools: I work with programs that transfer models between modelling tools. Most of the class models on my desk are in fact data models conceived in an object oriented modelling tool. Why is that?

Object oriented tools are routinely used during conceptual work because – apart from organizing your data – you want to think through your processes. That done, the database gets its due, a task where the object oriented tools lack qualities. That is why after a while projects want to transfer their classes into a database design tool. The result of the transfer is useful as a basis for database design.

At this point the mental divide between object and entity gets in the way.

UML has no concept for “key”, (among others). The standard for object oriented modelling is called UML – Unified Modelling Language. It was preceded by a host of object oriented methods and wants to be their generalization. That accounts for the letter “U” in its name. Entities and related concepts have been treated somewhat harshly by UML, they simply don’t exist.

Additional expense because of constructs missing from UML. If a UML-tool is used for data modelling, existing UML-constructs have to be used in ways for which they were not intended. There is no “official” way to do this and so each class model that needs to be transferred into a database design tool looks different. This is obvious at the level of subject matter – but it is worse than that: The syntax is different. That is why more than just pushing the button is needed to transfer the model. The peculiarities of the model must be identified and a script must be written to neutralize them. Only then can the button be pushed.

Extending UML. There is some consolation: UML wisely refrains from completeness, see above, but it opts for extensibility as the superior concept. If constructs for a special purpose are missing, e.g. a key, then UML can be extended. Essentially the interested persons, projects or organizations themselves create the missing descriptive elements, and bundle them to form a so called “UML-profile”. After loading it into a modern UML-tool they can use the formerly missing constructs – e.g. the key of an entity. In organizations the profile is distributed together with the tool, which means that the user need not be aware of working with a profile instead of native UML.

Problem solved? Not quite. Each special purpose, each organization may create its own profile and does so. A project has to deal with various purposes and various organizations are engaged. Each occasion builds its own Babylonian Tower.

Database invisible? I can hear your objection. Who needs a database design tool to design his database? No need to bother with that. We have the data structures within the classes and we have tools to build the database on that basis.

It is in fact quite feasible to build a database application without ever laying hands on the database. This is an efficient way to build a single application. But in big organizations, you will very rarely find isolated applications.

If you have more than one application running on the same database things get a bit complicated. Nesting of data in objects is done to speed up operations, so different applications will need different ways of nesting. Having only one database, you will want a design that neutralizes the different data structures. That is what traditional database design does.

To sum up: Although continuity between entity and object is something natural and to be wished for, in practical situations there are problems. The reason? No idea. I consider it just an error that has not been corrected in time – just like the positions of letters on your standard keyboard.

Practical suggestions:

  • When modelling persistent objects, try to find a key and check whether your users agree with your decision.
  • If more than one OO-application is to run on the same database make sure that it is properly normalized.
  • If you are modelling with an UML-tool and wish to design your own database, for instance in a multi-project-situation, try to find a UML-profile for data modelling that is already established in your organization and use it.
  • Nudge projects working on “your” database in the direction of using the same modelling method as you do and be prepared to make compromises.

JJG

Roland Dürre
Thursday May 22nd, 2008

corruption, monoculture, multiplicity, shareholder value

Siemens AG is currently often in the media, mostly negatively, in particular as regards the Siemens corruption scandal. This saddens me, since Siemens was my first employer and moulded my views.

5 years ago, with Marc Borner – a philosophy student from Darmstadt – I produced a lecture about corruption with the title “Das Käufliche des Unkäuflichen” for a seminar at the Wolfgang-Goethe-University and repeated it at various Universities and meetings. I still get reactions to it, so I will be happy to repeat it where there is interest.

Briefly, the (reasoned and substantiated) message was:

  • Corruption has existed as long as mankind.
  • So corruption can be regarded as normal.
  • Under exceptional circumstances corruption can even be ethical or even necessary.
  • But since corruption generally damages society it should be combated and limited as far as possible.
  • Corruption in many countries, including Germany, significantly exceeds what is acceptable.
  • It may be that we have gradually got used to it.
  • “Training” in corruption starts in childhood and continues in social systems and at work (see my posting “target-setting” – Zielvereinbarungen, if you understand German).

Enough for now about corruption:

When I started at Siemens in 1976, all new employees were greeted in the fine canteen in Hofmannstrasse in Munich by a real live director. His talk covered the social balance of Siemens AG and then described the Siemens corporate strategy in detail.

I summarise his talk:

“Siemens has 25 different divisions. Most make a profit, as one would hope. Two or three have crises. That is inevitable. These divisions will be sanitised as quickly as possible so that they are profitable within a couple of years. It is an illusion to think that all can always make profit. Siemens very rarely gives up a business area.”

“Modern” managers would probably dismiss this as an antiquated principle. But I believe it is a modern and wise company strategy, which has proved right in recent decades too, giving intelligent diversification coupled with synergy.

In 1976 synergy was not a dirty word. It really happened in Siemens. It was not always easy and friendly, but generally worked well. Personally, I know of Siemens products that were particularly good due to influences coming from different divisions.

Siemens was jokingly referred to as “a bank with associated electric business”. Financial health, customer utility, business respectability, solid, sensible cost planning, stability and long-term thinking were epithets associated with Siemens.

Nobody at Siemens then talked about Shareholder Value. Good results were expected. Good return on investment was the natural result of good engineering and a solid centrally integrated sales force. The company profited from a healthy value system. Siemens had a few weaknesses, but prospered while other electro-firms (AEG, Grundig, and Telefunken) failed.

What went wrong?

My explanation is quite simple. Siemens like many other European companies fell into the “Shareholder Value” trap. After more than a century, Siemens’ own successful strategy was sacrificed to the international analysts. Widespread dubious ideas were thoughtlessly adopted and became the new management principles. The following two were particularly damaging:

  • A multinational concern does well only when it is number 1 or 2 in the world
  • Corporate “styling” by merger or takeover or by selling parts is a good way to solve problems

“Number 1 or 2”

The belief that a major concern must be Number 1 or 2 gives me toothache. Perhaps there are special cases where this makes sense (e.g. Intel processor chips, or Microsoft operating systems), but I have doubts there too in the long term.

In business history one sees that the number 1 often goes downhill or even disappears completely. And there are many examples of companies ranked 3 to 10 in the world that constantly earn very well. Particularly in Germany there are firms whose good work (and luck as the founders willingly admit) made them number 1 in specialised areas. But when they go onto the stock market, the problems start. BMW is now finding out how hard life is as number 1. (Comment from the translator: I thought GM and Toyota were top).

I fear that the new Siemens strategy of concentrating exclusively on three mega trends is very damaging. The utopian aim to be number 1 or 2 in the world will fail. A multi-culture of 25 divisions with separate business areas seems to me a better form for a long term functioning company, than 3 mono-cultures that must always be number 1 or 2 worldwide.

“Merging and divesting”

I need not write much about mergers. The literature shows that most mergers fail. The desired positive effects very rarely happen. Siemens-Nixdorf, BMW and Daimler are recent German examples. Compaq, HP and DEC also bear this out. The hope is that 1 + 1 will give more than 2, but often 0·5 or less, results. Regarding sell-off, in Germany one thinks of BenQ, Fujitsu-Siemens, Infineon, Quimonda (all dubious Siemens spin-offs), and (soon to come) NSC.

Uncritical foolish adoption of the above two beliefs has damaged Siemens AG more than the currently well publicised corruption. Corruption is one of the moral problems of our time, but should not be overrated. Siemens was perhaps recently a bit more corrupt than other firms, but I do not really believe it. Probably Siemens just hid things less cleverly, (which could be taken as a sign of positive culture).

What could have been done better?

It is easy to criticise. Effective advice is much harder, as I know from my own experiences as a businessman. I believe that lasting success in business only comes when three main requirements are satisfied:

  • Costs must be controlled!
  • Know-how – the best thing that a company has – must be protected!
  • The firm must continuously renew itself, and stay young!

Here some clarification of these three requirements:

“Costs must be controlled”

Clear control of all costs and economical operating are the first prerequisites for lasting success. This is particularly important while building new business. This used to be a strength of Siemens. Recently it went missing. I cannot really judge whether it was clever to shower Ronaldo and Real Madrid with money, in order to sell mobile telephones in South America. But I am allowed to register my scepticism.

“Protect Know-How”

In my time at Siemens, I was always impressed by its universal know-how. The joke “If only Siemens knew what Siemens knows” was absolutely justified. Regarding IT, I have recounted something about it in my posting “InterFace Stories”. Particularly technology firms live mainly from their know-how. To throw this away is the cardinal sin. I have personally experienced monstrous demolition of know-how in Germany, by Siemens and other firms.

“Stay young!”

This is probably the biggest and hardest demand on “old” companies! Keeping young is many-faceted. Company and working culture belong to it, as do the mental states of young and old employees, and simply the average age of the workers.

It is not easy in an aging society to find enough young people to reduce the average age of a firm. But we need them. They know life and the market. They bring dynamism. They are energetic and want to work in a collaborative environment. They bring a fresh wind to the firm. (Comment from the translator: Roland is trying to get better jobs for his 7 children. He has contributed to keeping Germany young)!

An average age of e.g. 46 (I know of a concrete case) is simply too high for an IT firm or department. As growth has its limits, older employees, who cannot all go into management, must be fitted into suitable alternative employment. Early retirement schemes are not the answer. We need the seniors. Perhaps the seniors must be ready to switch to new (worse paid) activities. This conflicts with the traditional rules of the job market, so new thinking and modest demands are needed.

We seniors must stay on the ball. Certainly we have many qualities that we can use constructively. But that will only function when we welcome change. Our children take things for granted that we do not fully understand. I know IT managers and businessmen, who did not know what a blog or podcast was, when I tried to get them to read my blog. And what that funny youtube or a twitter is good for, they don’t know either. This is not a joke. It is bitter reality.

We seniors and our younger colleagues together must see to it that the firm stays young!

Summary

The current decline of European technology concerns is not caused by corruption however objectionable that is.

Shallow American management slogans have been imported to Germany without due consideration, and healthy multi-cultures replaced by mono-cultures. In the business playpen, directors have played company-monopoly with gusto, busily buying and selling, merging and divesting. Megalomania and presumed omnipotence were their companions. Everything was judged to be successful and the rewards of success were quickly paid out by the players to themselves.

In “Germany Inc.”, the good old German company virtues have been forgotten. The challenges of change have been misunderstood or ignored. Real reform has not happened.

The various themes of the abandoned Siemens divisions were not bad. The main weakness was physical and psychological aging in the company. This was treated with the wrong medicine. Mega trends and dreams of world market leadership are useless. Only bold striving for change can help. Sadly, for some technologies in Germany it is already too late.

RMD mehr »

Roland Dürre
Tuesday May 20th, 2008

(Deutsch) IF-Blog 2-wochen-news – #3

Sorry, this entry is only available in German.

mehr »

Bernhard Findeiss
Friday May 16th, 2008

The basics of account management

In my last blog post (see here), I introduced a classification of IdM-Systems based on the FIDIS model.

Based upon this classification, I now want to talk a little bit more about the basics of type-1-identity Management (aka “account management”): What is it, and what are the main challenges and difficulties?

Next time, I will explain why it is worth doing, and sometimes even mandatory.

By the way, this blog post is based upon a talk I gave last year at one of InterFace AG’s “blue Fridays”. If someone is interested in the slides, or wants me to repeat the talk, feel free to contact me at Bernhard.Findeiss@Interface-AG.com .

As mentioned in the last post, account management can be defined as the consistent administration of identities, and their access to (IT-) resources of an organisation during their entire life cycle.

This includes:

Persons, e.g. employees and external consultants, but also technical objects as long as they need access to resources (for example printers which can send automated status emails etc).

Storage of identity based data (mostly supplied by HR systems)

Transfer of data to target systems, e.g. to create accounts, to assign and/or revoke access rights, but also to synchronise data between the IDM system and the target system. The number and nature of target systems significantly contributes to the complexity of IDM projects, by the way.

Support for workflows needed in everyday (corporate) life, like creation/editing/deletion of identities, assignment/revocation of resources, role definition etc.

Account management is not a new topic for most organisations. In fact, it has existed for as long as access controlled (IT-) resources have existed in an organisation.

Until now, however, most of the work has been done manually by specialised administrators. Of course, this is very expensive and time consuming, and it also involves a much higher error ratio compared to doing it automatically via an IDM system.

Also, there is the problem of data synchronisation and consistency. Access to all of a user’s IT systems should be based on the same set of identity data. These are not unalterable, however, but can change over the course of time (through marriage, relocation etc.). Keeping identity data consistent in all IT systems can therefore be quite a challenge, e.g. when 2 systems contradict each other.

To solve this problem, directory services were introduced (starting in the 1990s). They gather all individual-related data and make them available through a standardised interface (with LDAP being the one mostly used). This directory is then defined as “leading” in respect of identity data. All other systems from now on only synchronise with this directory, and so eliminate the problem of data inconsistency.

Unfortunately, it became clear that even directories could not solve all problems. Not all IT systems support the externalisation of identity data. For some systems, (like HR), it might even be undesirable to do so.

By the use of an identity management system, however, even this situation can be managed:

Now, all systems may keep control of their data. Only relevant changes are propagated to the IDM system. The IDM system then manages synchronisation with all other affected systems in the organisation.

Here too, data consistency throughout the organisation can be guaranteed.

This is only one of the advantages of an IDM system. I will mention more advantages in my next article.

Roland Dürre
Monday May 5th, 2008

The InterFace Story #2

mehr »

Sorry, this entry is only available in German.

Roland Dürre
Saturday May 3rd, 2008

From Ottobrunn to Unterhaching #2 (Bike/Train/Car)

Continued: My personal experiences on the way to work:

From my home to Unterhaching and back by bike is about 12 kilometres. With a good bike, this costs about 20 cent/km (counting the original investment, wear and tear on tyres, chain, sprockets, maintenance and repair work). If you need a garage for all repairs, you may have to spend more.

Bike:

Costs: 12 km à 20 cent 2.40 EURO (not counting increased wear and tear on clothes).

Time: roughly 45 minutes for the round trip.

Advantages and disadvantages: Once in a while it rains. How much of a pleasure the ride is depends strongly on the weather, but with time you get used to cold and rain. A tuxedo definitely has not been designed to withstand cycling.

There is more than one way to get from Ottobrunn/Riemerling to Unterhaching. Besides the bike, I could choose the car, public transport, inline-skating or jogging.

Usually, the car is a little faster than the bike, though not necessarily during the rush hour. The costs are subject to your personal view. If I only count the diesel (since I have a car, anyway), then it is rather inexpensive. Take into consideration that the distance by car is a little longer than by bike, let’s say 13 kilometres. With my car, I need about 6-7 litres per 100 kilometres, which means about 1 litre for the round trip. That costs 1.40 € (as of May, 2008). A full-cost calculation would give around 35 cents per kilometre, which means 4.55 Euros for the round trip. Since we have spacious underground parking at InterFace (mostly for our guests), there is no need for me to spend ages looking for a parking place.

Car:

Costs: only diesel 1.40 Euros/ full costs 4.55 Euros (without Interface parking, 40 Euros per month).

Time: about 40 minutes for the round trip

Advantages and disadvantages: Occasional traffic jams, no exercise, but I remain warm and dry. Sometimes I get downright aggressive having to wait yet again at a red traffic light. Getting no exercise would also mean that I would have to pay for a fitness club in the evening.

By the way, there is another motorized alternative: my C1 by BMW. It is a pure object of desire, needs less gas and is something I definitely relish. Except for my conscience whispering: “You might as well go by bike”.

If I want to use public transportation, I can take the local train. From my home to Ottobrunn station is exactly seven minutes on foot. The S6 takes 11 minutes to Giesing, where I would have to wait 10 minutes until the connecting S5 takes me to Unterhaching in another 6 minutes. After five minutes on foot from Unterhaching station to the InterFace building, I would arrive after 27 minutes on trains and on platforms plus 12 minutes walking

S-Bahn:

Costs: two single tickets 4.40 Euros, if I take the strip ticket (4 strips for 1.05 Euros each), it is 4.20 Euros.

Time: 78 minutes for the round trip (provided the train arrives on schedule!?)

Advantages and disadvantages: You can read in the train. There are times when the train is overcrowded and I do not get a seat. On the platform in Giesing, it can be rather windy while waiting for the connecting train. And the problem of punctuality; in the Munich area, the reliability of the train service varies a lot. And if you miss the connecting train in Giesing, then you have to wait another 20 minutes.

Comparing the various means of transport is quite interesting. It may motivate others to start thinking about it. For me, the bike clearly wins, and public transport (unfortunately) comes in last.

In theory, I could also cover the distance between home and office jogging, inline-skating, or by taxi. I never tried the taxi, but jogging and inline-skating are real luxuries. I can do this occasionally because of the beautiful shower room in the basement of the InterFace building and because clean clothes hang in my office wardrobe.

RMD

Translation by Evelyn Gemkow