Real-Design

Back in the 19th Century in Germany a term was coined to reflect the concept of politics based on practical considerations rather than ideology. Although the term, Real-politick, has long since fallen into disrepute, its initial intent was to convey the desire to avoid an arms race and achieve peace through acceptance rather than hard and fast viewpoints. The more time I spend in architecture and information systems, the more I think we need a similar term; Real-Design would be based primarily on the realities of the client’s needs and existing skill set and software base. Real-Design would be about designing solutions that fit with the immediate requirements of the customer whilst not precluding the move to a more controlled architecture in the future. Real-Design would allow us to state an end goal whilst not attempting to enforce an unrealistic work practice on end user to account for the gaps in deliverable technology and green field architecture.

A good example here is the canonical data model. I have to preference this by stating I am a huge fan of the model. In an ideal world the canonical data model isolates the core system from changes in the external systems, and isolates each of the external systems from each other. The catch is any data not include in the original model has to be included at a later date. And that is an incredibly expensive process in terms of both time and money. To avoid this, you are required to “design the world” before you start, leading to one of two outcomes; a long design cycle, or a flawed model. Neither are particularly desirable outcomes from the customers viewpoint.

So what is a better model? We move towards concepts like the canonical data model to avoid fragmented architectures, and to move us from the issues presented by point to point integrations.  Should we then go back to those problems? I see part of the problem being the way we attack the problem through technology. We attempt to fit a restrictive model over the top of an expansive problem, and then like try and poke the bits that don’t fit back in. Usually by telling customers to change the way they work to account for it.

A Real-Design solution to the problem would be to move towards a “just in time” conversion of only those data elements we care about with a mechanism for capturing the details of the translations in a repository that could be used in design and development time to bring about new integration segments. Or even better, a repository that would be used at run-time to look up the translations.

A Real-Design approach to integration would be the acceptance of the existence of less than perfect architectures within the system, and the development of a solution to play with all of them.

Tags: , ,

Powered by Qumana

Advertisements

0 Responses to “Real-Design”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: