productization revisited

in my early my university days, i told myself that i'd stay away from software engineering subjects, simply because i thought they were boring. so i instead focused on more exciting stuff like artificial inteligence, distributed computing, automata theory, computer networks, schedulig resource management, etc...

to my great surprise, software engineering now fascinates me tremendously.

in the first few months of working in the company, i made this conclusion: there is a definite relationship between the architecture of a piece of software, and the speed and quality of which that software can be built, deployed, and maintained.

and since speed and quality of software development depends much on the people you have on your team, company policies, and how they actually interact with each other, the corollary is that all these factors influence software architecture. and since the decision of how to maintain the piece of software (by recruiting top-notch Java gurus and pay them 8K a month each, or by outsourcing everything but the user interface to india) is a business decision, you can say that software architecture is also influenced by the model of which the software company decides to operate.

let me run this by you again:

the size of your company, the people you have in your team, whether you have CVS/VSS, whether everyone in your startup team are seated in a small apartment, or whether there are 1000 developers working together on a 7 million dollar project, .. determines what should be the right architecture for your software.

and so here's the next corollary.. as your company grows, and as your team and processes develops, so will the architecture that is right for your software.

when I first joined the company, i looked at the architecture that's been used as the template for all our systems and i silently screamed in agony. the architecture is lean, mean, and enables a small team of highly qualified developers to produce a highly-functional system in the minimum amount of time. development time is minimized because the architecture results in the minimum amount of dependencies across modules, and thus, minimum interactions between developers.

this type of architecture, however, comes at a cost. the softwares developed are hard to maintain, hard to improve, hard to debug, and everyone in the development team has a "don't touch, we won't know what might go wrong if we remove that debug statement" kind of a mentality. improvements to the system is not made by 'improving current code', but by replicating existing system functionality and modifying the duplicate.

this results in a very bloated and pretty much fragile system with a maintenance cost that grows exponentially as time goes by. surely this is not sustainable. if we want to grow our system and have a 'platform for continuous and sustainable growth of innovation', we need to change the architecture.

fortunately i came in at a time when the business direction of the division is changing from a 'customized solution' approach to a 'product-based' approach, in order to grow the company further. so i was put in charge of doing the R&D work of 'revamping' the core architecture of our 'to-be-products'.

mind you that an architectures for software products are much different from architectures for software solutions.

after about 4 months of work, we now have a more 'complex' architecture based on a core-set of plug-n-play modules which will be standard across all of our product implementations (i.e. all of our customers will get the same core set, they can choose not to use some modules, that's fine, the software can still run - this is not possible with the old architecture because everything was so tangled with cyclic dependencies across 3 or more modules), and we also have non-core modules that are built-to-spec, i.e. customized to suit that customers specific needs.

on top of this new architecture, we put in place a product development process that decouples the development cycle of the core modules from the implementation of the software for our clients.

so far i've been involved in various aspects of this productization effort of the company's flagship product. from designing the core-architecture, adding plug-n-play into the modules via inter-module service contracts, to even designing the software configuration management processes.

anyway, it's been fun.. i'm just wondering whether i can write a research paper based on what i've done..