all bits considered data to information to knowledge


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.

Comments (0) Trackbacks (1)

Leave a comment