New product development is complex. One of the challenges I always see with development teams embarking in new product development is with the decision on how much architecture is enough.
I am sure we all have crossed the stage of BIG DESIGN UP FRONT (BDUF). It doesn’t work with changing requirements and I am sure all the software development effort we have today has changing requirements.
Industry has evolved over a period of time and has come up with an answer called YAGNI (YOU AIN’T GONNA NEED IT). Objective of this is that unless you need something, don’t build it.
Ok, what is the big deal on this?
Let us say you are building a house. Your foundation will form the structure for your building. If your foundation doesn’t support a certain design, there is no way you can build your house with the design. Meaning, it is very difficult to reshape the building once the foundation is done.
What is the solution for this?
There is no silver bullet. Balance is very important to anything one does, which I call as Minimal architecture definition.I see, people struggling with the definition of minimal architecture.
What defines a minimal architecture?
Minimal Architecture is not about your Visio diagrams or the colourful dubbas (boxes) in a PowerPoint presentation which can be checked in to your source control and helps you clear CMM or ISO Audit.
Minimal Architecture is something that,
- Gets you started with your development
- Enables development with minimal rework. One way to evaluate is the cost of rework during your development. I am talking about rework and not refactoring. I have seen many people calling the rework as refactoring (So that no one bothers to ask why there is rework).
- Can evolve. Requirements will evolve over a period time, so does the architecture and design.
- Is Testable. A Common question I see with stakeholders is that will this work? Human nature is that it will be very hard to believe anything until seen. Is there a way the architecture/design can be tested against the business goals so that it gives confidence to the stakeholders? Till it happens, architecture is a set of boxes aligned in a certain way J
- Can scale. When I talk to product teams about scaling, the immediate answer I get is we do not know the requirement. True, you may not know the exact requirement as it is a new product. But you should be having some rough idea on the target market. Can your architecture address your current market and can scale if there is a future need. As I mentioned earlier, the structure of the house will be dependent on the foundation. If this is not done, there is no way you can say whether your architecture can meet your business needs.
Obviously, there can be more. In my opinion you will have a decent bet on the architecture if the above are answered and obviously you can scale. A little effort in planning can help you do much better during the development.
One of the things which I learnt is, all these has to be reviewed on a regular basis and it requires participation not just from the team, but also from all the key stakeholders.
Can this guarantee Success? May be/May not be. At least you will have a decent idea about your project and whether it can succeed. It can at least guarantee you that, you don’t have to bring in a consultant towards the mid/end of project to review your architecture.
Lean Architecture for Agile Software Development