Some rules to make the architecture clear and project healthy. Not for architects, but for managers.
- Keep the balance between time and scope of the project, but cut the scope first.
- Use clear terminology.
- Use commodity technologies whenever you can.
- Keep the balance of expertise in a team.
- Run technology projects to increase your capabilities.
- Repeat experience a few times before generalization and avoid universal solutions.
Let's dive deep.
Keeping the balance between time and scope of the project
Basically, you should:
- Define the business value or technical capability to be delivered (the project goal).
- Split the project into smaller ones repeatedly (research, achieve technical capability, do this or that) until each subproject fits into reasonable time and budget.
Why keeping the clear scope is so important:
- It's easier to understand for a new team member. It means the expertise is scalable and eventually, this affects the architecture.
- It's easier to communicate decisions because of team size. This leads to a more effective architecture process.
- It's easier to find the right trade-offs when the scope is perfectly known and the project goal is in the line of sight (you are sure about what you are influencing with a compromise).
In any vague situation сut the scope (save time).
In large organizations, there might be tendencies to bloat the scope to sell the projects. After that, frequently, when things go wrong (because of unclarity) managers just cut the time (but not the scope) harming the architecture. Healthy organizations stop a project that's going to fail, overview results and mistakes, then start another one.
Using clear terminology
All the project stakeholders (you, technical team, business people) should share the same concepts. It's obvious why, but often undervalued.
The main idea of Domain-Driven Design is to segregate a big architecture scope into bounded contexts with ubiquitous language. So, language and scope are related — to manage both things you have to balance the scope, but also to work on the glossary.
If practical common glossary happens to be unattainable, it usually means:
- Too big scope.
- No will to think in the stakeholders.
- Disrespect and incompetence disguised by time-saving.
I recommend reading part 1 (at least) of a well-known architecture book "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans (ISBN-13: 978-0321125217, ISBN-10: 0321125215).
Using commodity technologies whenever possible
With any IT project, you are going to manage unknowns and blockers. Why add ones in form of non-answered questions about unpopular technology? You might have to make trade-offs that you wouldn't normally make, breaking architecture, so why would you?
Usually, this happens when:
- IT manager is still expert and is relying on his / her own expertise in marginal technology.
- Some non-IT manager is convinced by some vendor.
The only valid reason to use non-commodity technology is — it is proved to be perfect with this task. So take care about proving it and notice — the proof of the pudding is in the eating.
Keeping the balance of expertise in a team
If SCRUM is applied, having the universal team members (no fixed roles) and continuous learning from each other inside of the team is a vital part of the methodology. This ensures the balance.
But, if you have dedicated roles, no matter what the reason is (complex project, culture, faking SCRUM), you should think about different levels (senior, middle, junior) inside of each role.
I mean, for every role (analyst, architect, developer, QA engineer, release engineer and so on..) there might be:
- lead - a person responsible for final decicions (must possess high expertise by definition).
- seniors - people with high expertise. It's better to use them for challenging tasks.
- middles - the people that are making 40-90% of regular work.
- juniors - the people that are just started their way in the profession. They save money by doing simple tasks (20%-70% of work).
Take care to have appropriate expertise distribution among the team members and start recruitment with a lead person for each role.
Running technology projects to increase your capabilities
The technology projects (research, technology migrations and so on) are necessary:
- To build technical capabilities itself
- To acquire modern architecture practices
- To keep the balance of expertise in your team
- To keep people energized and committed to work
That's why you aren't going to be a growing company without technology projects.
Repeating experience before generalization
Too early generalization is a form of overengineering.
First, collect cases. Think of a generalized solution challenging its design against the scenarios that will be discovered. Take time for it. Otherwise, chances are pretty high you'll have to break your architecture many times.
Second, modularise your solution and avoid tight coupling.