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.


Architect by any other name

Just as house construction industry winds down, architects are suddenly in vogue – software architects, that is. The concept of software architecture goes back to late 1960s beginning of the 1970s, when Edsger Dijksta and David Parnas pointed out importance of the software structure, and laid down foundation for Software Architecture Study.

There is a fair amount of confusion in the industry about the software architecture: perfunctory sampling of the job ads on some popular online job-searching sites reveals that recruiters are looking for Software Architects, System Architects, Enterprise Architects, Data Architects, Java Architects, .Net Architects, all of the above Architects and then some. This reflects confusion in the software industry in regards what is it exactly that architects do, their role in organization and in the projects.

It is important to realize that there are at least two distinct architectural roles for any sizeable software project: Enterprise Architect and Solution Architect. Here I coalesce the multiple titles into two basic archetypes of software architecture; from there various flavors can be extracted and judiciously applied: Enterprise Data Architect, Database Solution Architect or any other combination of titles that makes sense in a particular organizational structure. As the saying has it: "Wisdom begins with calling things by their right names";  before I could elaborate upon the subject of the article we must define these two roles.

 Enterprise Architect is a planning role that is responsible for mapping current and future states of an organization's IT environment, and providing transition road map between the two for all the software development projects.

 Solution Architect is a project team role that is responsible for the detailed system design of the solution being delivered to the business.

 Each role is contributing to the delivery of the software-intensive system by creating artifacts that describe the system’s architecture; each artifact opening a window into the system for one or more of the project stakeholders.