Windows 7 - more proof on why iPhone is better

A while back I posted why Phone adverts tell you that the phone is rubbish

Well lets compare

Windows 7 Mobile


Apple FaceTime


The difference remains. Apple have the confidence to show you people actually using their phone, Microsoft have the confidence to not show you people actually using the phone but doing other stuff to pretend that their phone is cool

If people can't even fake an advert to make a phone look useable, what does that say about the devices themselves?

Technorati Tags: SOA, Service Architecture

MDM made easy - why people make Master Data Management hard

Okay so I've spent a while in the last 10+ years on various MDM (Master Data Management) programmes and its come down to a very simple reason why lots of MDM programmes fail..

People screw up MDM programmes by forgetting what MDM actually is.

The first bit is that people look at the various different MDM packages and then really miss the point. Whether its Oracle UCM, Informatica, SAP MDM, IBM MDM, Initiate, TIBCO or anything else people look at it and go...

Right so this is what we do, what else can we fit into it

Now this is a stupid way to behave but its what most people do. The use the MDM piece as the starting point. The reality is that MDM is only about two things

1. The cross references of the core entity between all the systems in the IT estate
2. The data quality and governance around the core entity to uplift its business value

And that really is it. The more attributes that are added beyond the those required for these two elements then the more expensive and more complex and less effective your MDM solution will be.

The other core part of this is that there really are only a very limited number of bits to MDM, its about three things

1. Things - assets, accounts, parts, products, etc
2. Parties - individuals, organisations, customers, suppliers, etc
3. Locations - postal addresses, email address, web addresses, physical address, geo locations, etc

That really is it from an entity perspective then you've got the relationships for those entities (and remember a relationship is just the keys to do the match) which means

1. Parties to Things
2. Parties to Locations
3. Things to Locations
4. (Parties to Things) to Locations (e.g. a persons specific account address)

There really isn't much else to do it really is just

So all you need for MDM to succeed is the above entity model and a list of attributes required to uniquely identify a high quality version of that entity.

So why do people screw up?

Well first off is because they do something like picking a customer mastering package and then trying to master product information or product relationships within it (e.g. Asset to Location).

Secondly because they start extending the number of attributes rather than creating a cheap ODS.

Thirdly because they create their own versions of the relationships because of a belief that business rules that they have change the entity model rather than actually just being data quality rules against the standard entity model.

So the reality is that MDM is simple, its about the data quality and matching, which means its about the business governance of information.

And that is the real reason that most MDM programmes fail to deliver, because in order to get to the business governance of information and make MDM simple you have to do an awful lot of hard work in building up the trust between the business areas and IT that governance can be done in a way that benefits rather than impacts business.

MDM isn't a technology solution its a simple business solution, the problem is that IT people tend to make it a complex IT solution because they can't make it a simple business solution.

Technorati Tags: SOA, Service Architecture

Simplicity is hard

One of the things I get to do a lot of is look at IT estates that are a complete and utter mess. Systems overlap in functionality, are difficult to maintain and the links between them are more complicated than Glenn Beck's issues with reality. When doing a Business Service Architecture it becomes clear that the big issue here is that IT doesn't learn the lesson of Unix Do one thing and do it well. In SOA, particularly business driven SOA this is the whole point of services, they do one thing and they are designed to be integrated.

Having the "services" as clean though is pointless if what you have under the covers is just the same old crud with some REST or WS-* lipstick on top, you actually have to have an implementation that is clean all the way down or you are still screwed.

The BSB Specification was based around that principle of doing one thing well, and the whole point of the DSB/BSB split is to keep it simple.

This then becomes the real issue, its actually really hard to architect and deliver simply. In the MDM space for instance you see MDM solutions that morph into MDM + ODS + Reference Data Management solutions. "clean" ERP installations are destroyed by customisation and the Java solution gets some crufty bolt ons because "it was easier to do it there". The delivery builds the blob with lipstick on it and suddenly we are no better off.

Why does this happen? Well more and more I believe its because the SIMPLE pictures that describe a business architecture are either not drawn at all or are abandoned because of their simplicity. People, architects especially, don't like putting in place the rigour and control that is required to deliver a simple solution, its much easier to deliver a blob and let people cope with it in support. Simplicity isn't a valued commodity because it doesn't allow people to show off their understanding of complexity.

"Je N'ai fait celle-ci plus longue que parceque je n'ai pas eu le loisir de la faire plus courte.
--I have only made this letter rather long because I have not had time to make it shorter."
Pascal. Lettres provinciales, 16, Dec.14,1656. Cassell's Book of Quotations, London,1912. P.718.

Simplicity takes time and effort and the end result is much more satisfying, easier to explain, easier to maintain and easier to use. Most people however take the easy route to complexity.

Technorati Tags: SOA, Service Architecture