Taking care of clarity in the architecture

Some rules to make the IT architecture clear and project healthy. Not for architects, but for managers.

  1. Keep the balance between time and scope of the project, cut the scope first.
  2. Use clear terminology.
  3. Use commodity technologies whenever you can.
  4. Keep the balance of expertise in a team.
  5. Run technology projects to increase your capabilities.
  6. Repeat experience a few times before generalization.

Let's dive deep.

Keeping the balance between time and scope of the project

Basically, you should:

  1. Define the business value or technical capability to be delivered — the project goal.
  2. Split the project into smaller ones (research, achieve technical capability, delivery of functionality).

Repeat the steps mentioned above until each planned subproject is within a reasonable time and budget.

Why keeping the reasonable scope (of each subproject) is so important:

  1. Anything is easier to understand for a new team member. It means the expertise is scalable and, eventually, this affects the architecture.
  2. It's easier to communicate decisions because of team size. This leads to a more effective architecture process.
  3. When everything is perfectly known and the project goal is in the line of sight, it's easier to find the right trade-offs. The stakeholders are sure about what is affected by a compromise.

In any vague situation сut the project 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 for architecture, but not the project ambitions. 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 business concepts. It's obvious why, but often undervalued.

The main idea of such a popular book about Domain-Driven Design is to divide a large architectural scope into bounded contexts, within which people use an ubiquitous (equally understood) 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:

  1. Too big scope.
  2. No will to think in the stakeholders.
  3. Disrespect and incompetence disguised by time-saving.

I recommend reading part 1 (at least) of a book "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans (ISBN-13: 978-0321125217, ISBN-10: 0321125215).

Using commodity technologies

With any IT project, you manage unknowns and blockers. Why add ones in form of non-answered questions about unpopular technology? You may be forced to make compromises that you normally wouldn't have to make by breaking the architecture, so why?

Usually, the use of unpopular technologies happens when:

  1. IT manager is still expert and is relying on his / her own expertise in marginal technology.
  2. Some non-IT manager is convinced by some vendor.

The only good reason to use non-commodity technology is — it has proved its perfect suitability for the task at hand. So take care about the proof 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 expertise balance.

But, if you have dedicated roles, no matter what the reason is (complex project, culture), 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 naturally might be:

  • lead - a person responsible for final decisions (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).

In a healthy team, there should be a moderate rotation and continuous growth from juniors to seniors. This guarantees motivation, constant attention to problems and expertise handover.

More importantly, the role starts with a lead. If you understand that you need a dedicated role, but there is no one in a team to put in the lead position, take a good senior from the side. If you put a junior in the leading position the consequences will be:

  1. He / she will be growing 2-3 times slower than he / she could with a good lead.
  2. He / she may start blocking everything that he / she has not figured out and jealously worry if someone goes deeper into his / her sphere. Protective behaviour is explained by high degree of assigned responsibility and insecurity.

The one thing is to divide the available seniors into roles, but it's quite another to think that by recruiting juniors instead of them you save money.

Running technology projects to increase your capabilities

The technology projects (research, technology migrations and so on) are necessary:

  1. To build technical capabilities itself.
  2. To acquire modern architecture practices.
  3. To keep the balance of expertise in your team.
  4. To keep people energized and committed to work.

That's why you aren't going to be a growing company without technology projects.

Understanding the above, you don't have to formally "squeeze the result" from technological projects, focusing only on the 1st goal. Without training, mistakes and their correction (take time for it), there is no good architecture and, therefore, there's no future for the technological capability you create.

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 the architecture many times.

Second, modularise your solution and avoid tight coupling.