Break past technology dependency

Our applications tend to mould their functional design to cater to technological limitations of the platform at a point of time of the project's implementation. These additional designs, I would rather call crumbs, over time are felt to be integral part of the design. It doesn't hurt us initially.

Fast forward, 20 years, when we are at a point of migration of these applications to new high end architecture, with cutting edge steel and chips, supporting these migrations. We feel the pain of not having expertise or courage to weed out crumbs from the initial design requirements. Blame this to either missing initial expertise - all gone or retired, or lack of capability to digest and map new technological offerings from bay area companies to these age old "functionality" .. or crumbs, and continue to live with them.

Just shows cost of incomplete or non-existent enterprise planning documents - targeting building blocks of the enterprise - process and information. I wouldn't risk delving into the other units, people & motivation. Operation models variation over time is another story...

Wiki

Old bottle New Wine?

We all have been there, processes are slowing down, so we throw in money, get latest gizmos from market and hope to solve problems. Typically this is the flow I see happening:

Old Process Old Toolset
Old Process New Toolset
New Process New Toolset


The 2nd phase is where we typically get stuck in. Unfortunately most likely the new gadget didn't come with a manual to treat it well.. So we continue to push the old process thru the new toolset - hoping for miracles.

To the sofware companies, pl. pay attention to change in process required when selling the softwares. People, roles matter.

BYOB?

Ever wondered if the framer and the foundation guys brought their own blue print, what would happen to your home design. What's the probability you would be happy with your home, provided the frames line up with the basement walls. Thats what the blue print of the home does for you, thats why you hire an architect to build a model and give that to the foundation guys to use, and give a similar one to the framers.

So why so often, we see applications being designed and expanded, typically in small scale and sometimes in enterprise space, without a blueprint ever being considered? Would that design suffice your dream. What's the chance that you are going to be happy with your solution, that you paid for. Welcome to the world of data models/process models.

Hopefully this blueprint building effort will give you a chance to have a say in what you are paying to be built, not get blindsided after the whole application/solution is built.

Crystal Ball

Today's assumptions, when become tomorrow's factor. That kicks in efforts to refactor - the app supporting the process. BTW changing the data model would help. The worst case is when assumptions are so very deep rooted that we don't even acknowledge them as assumptions. They are just ... way things work. These can be worse than the normal assumptions. Refactoring this change just got bit more expensive. Sorry about it.

Watch for the grain

Examples of mundane daily chores like "driving a car" to explain a complex thought is simple yet powerful. We use our inherent understanding of the daily chore to understand a different abstract idea, like strategy of a company being " direction, talent and basic controls". we find it easy to understand the concept and need for each of the components as we make association to known accepted knowledge of driving the car - steering wheel for direction , gas pedal for the power bit, and basic controls for keeping us in the speed limit. Our unquestioned understanding and acceptance of the chore of driving a car helps us get over questioning the abstractness of the idea we are trying to present/explain/analyze.

The problem lies in incomplete or inaccurate choice of example. If example's components are not completely in sync with the prongs of the main idea, the risk of the idea being questioned is high, not the example's validity. Realignment of thoughts are necessary in that scope of time to come up with a new example. For example - if the last corellation of driving a car - for. eg. the car's dashboard was not recognized to be a valid candidate for being an example of basic controls of organization, we question the example or even worse, the idea is not complete.

Shadows on the Ground

Dragging thru requirements of what we would like in data store can be challenging. What appeares to make things more fun are overlapping effects of multiple processes going together. Having to deal with cummulative effects of different processes is one issue, but identification of these layers of functionality is another. These might have different owners and drivers and needs to satisfy but impact the ground ( data model ) all together.