all bits considered data to information to knowledge


Metaphorical modeling

I am a big proponent of modeling - data modeling, business process modeling, system modeling… Reducing complex systems and behaviors to the most important attributes for a given context facilitates better understanding, and helps to architect better solutions. Metaphor follows the same pattern - while not a full blown model, it highlights but a few features, magnifying them, and stripping of unnecessary details; by providing analogies in a different context it helps to break patterns of conventional thinking - often resulting in an innovative solution.

It had occurred to me that IT/Business uneasy symbiosis could be represented as a two-sided mirror erected at the border between the respective domains - IT and Business. Each looks at the other side convinced that “this is how they look!”… but each sees only reflection of its own.

NB: This is a variation of a proverbial “hammer and nail” metaphor: IT is looking for IT solutions for business problems (shelfware?), while Business is busy inventing business solution for IT woes (outsourcing, anyone?)

The domain of an Enterprise Architect (not to be confused with Enterprise IT Architect) spans entire enterprise, including both IT and Business; to offer a solution, an EA must have dual citizenship in both worlds.


Degrees of separation: yin and yang of software development

A software-intensive system could be beautifully modeled in colorful n-tier diagram, with messages flying back and forth, domain isolation and what have you not. But here’s the rub: models do not throw exceptions.

 At some point you have to step down from the cloud and make a decision about implementation technology. Some would argue that technology could drive the design but I belong to the other camp: technology might influence design but it always comes in second.

 Consider a technology agnostic concept of portal as part of your system design. A portal is a portal is a portal, right? Not quite. as some portals yield itself to specific directions in a sense that they might or might not play nicely with other part of the system you’re designing. Even by saying “portal” you’ve already made some assumptions: TCP/IP transport, HTTP protocol, and web-based implementation. Then you need to consider existing infrastructure your system is going to live in (that is, unless you are given architectural carte blanch and unlimited budget, the stuff programmers lull themselves to sleep after 12 hours of coding in RPG); then comes executive preferences and appetite for risk – after all these are the people funding the project; then developers skill sets (either present or potentially acquired in the future), and the culture – some of them might be allergic to, say, Java, and yet some would not move a finger unless Assembler is involved…

 How intimately an architect ought to be involved with technology to have a clear vision and an open mind?  At what point do you cross over from an abstract into a concrete world, and how many steps are there in between?

 The yin and yang of software development.