There are three forces that shape a project: domain, process and technology. Add the “-driven” suffix to any of them and you’ll perhaps recognize some of the methods used in projects you’ve been involved in and yet, as soon as one takes too much of a lead against the other two, failure will follow almost inevitably. At the intersection of these three forces we find familiar terms and concepts but first a word or two about each of them:
Technology
Back in the days of the tech bubble, tech was allmighty. Buzzwords like Java, EJBs, PHP defined entire projects. It was the time where software became accessible to a much larger audience. The new wave of enthusiastic geeks embraced everything from new languages to professional certifications to the then-nascent open source. I admit having my share of technology-driven projects back in the day…
Process
Process brings structure and pace to a project. The two complementary components of a project process are methodology and integration. We are all too familiar with methodology: waterfall, RUP or agile methods of software development are vastly documented and practiced; integration largely is defect management, testing, build, deployment and documentation. Today they all come together in what is called continuous integration where all these concepts become interrelated in a repetitive process that produces accountability and visibility into the progress of a project. Process is also the one force that tends to disappear first after a project is finished.
Domain
The domain captures entities and business logic, is driven by the business requirements and is in no way influenced by the two other forces. The most successful way to employ the domain is through Domain Driven Design where the main focus of software development is neither technology nor process but the business requirements.
There are times in the life cycle of a project where these forces have to be kept separate but most of the time they shape each other. At their confluence there are several artifacts that are paramount to a project’s success with code being at their core.
Code
Although each force is important during a project life-cycle, they all work towards producing code. No matter how many UML diagrams, software architecture documents or burn down charts are produced the most valuable and tangible value that a project creates is runnable code.
APIs
Application Programming Interfaces represent the external view of runnable software products. APIs state the intent of the software. They should be cared-for and refined during a project lifecycle, until they become the best representation of the domain they are modeling. APIs also serve for integration purposes and so they should be extended to blend into the domain of the consumers as needed.
Features
Features are defined within a project scope. They can be fully defined prior to coding in a waterfall process or, defined and/or shaped during the project development in an Agile setup. Features specify a system’s requirements (they are called user stories in an agile project).
Test, Build, Deploy, Run
Projects have to be monitored since inception to their natural end. Just like a child’s development stages, projects need to touch milestones, assess velocity and health. They do so by constant testing, building, deploying and running.
Roles
Project roles that drive each of these forces can also be mapped in the above figure. Take the Agile roles for instance:
A fine balance
Imagine any of the forces represented by circles in the picture becoming disproportionally larger than the others. As a result, one or more of the artifacts at the intersection of the forces will become disproportionally smaller than the others upsetting the equilibrium. Whether is less features, less APIs or less testing, the end result is still unbalanced.
As always, people (roles) will drive the forces. Balancing them requires skill from all parts involved and the success or failure of a project depends on giving enough power to each not to overturn the balance. If ancient romans could do it two millennia ago, so can we.