Design organization for the success of software design

As an experienced software architect, you would need to think about both the organizational and technical perspective, in order to ensure the implementation quality of the software design, most importantly, it involves:

a. design the way that team is going to implement the software architecture;

b. design the team organization to eliminate potential bugs in the software implementation;

c. design the team structure to eliminate the un-necessary software component dependencies in the implementation.

To further elaborate, let’s look at a simple example.

The example design

Assume that we’ve three relatively independent functionalities to be developed, and the implementation of those three functionalities are distributed among three main components, while all of those three components depend on one common component. The components and their relationship as shown in UML diagram below:

a. three functionalities will be implemented in Class_B_1, Class_B_2 and Class_B_3;

b. Class_B_1, Class_B_2 and Class_B_3 inherits the abstract class Class_B;

c. Class_B has reference to the interface A, and interface A is implemented by Class_A;

In this simple example, the three functionalities are relatively in-dependent, therefore, their boundaries between each other are clear.

Suppose that we've three development units (could either be a small group or just three individual software developer), what would be the way that they're allocated to work on the implementation of those components?

Independent and parallel development

Approach 1, assign each DU (development unit) to each individual functionality component:

a. DU 1 will work on Class_B_1;

b. DU 2 will work on Class_B_2;

c. DU 3 will work on Class_B_3;

In addition to work on their specific functional components, both of those three DUs will work on the implementation of Class_A (and Interface_A when any of those DUs feel necessary).

The nature expectation of this approach is the higher speed, because three DUs are working at the same time on those three functionalities, so, they should complete the development in a shorter time, comparing with the any others that may have dependencies between DUs.

However, the expectation may not come into the reality, for the DUs that may not at the high lever of maturity, in both organization and technical aspects. At a high possibility, what actually happen would be:

a. The boundaries between each functional component and the common component would be vague;

b. The responsibilities of the shared component would be accumulated soon, and complexity will be increased a lot at the same time;

c. Very complex dependency could be created (such as below diagram shows):

d. The shared component (Class_A) will soon become the hot-spot of the whole system, i.e. it will have more revisions (could be two to three times more than average), more code changes than any other components. Therefore, this component will probably have more potential bugs than others;

Because of all those reasons, it will end up with many potential issues at the integration, and big problem will be created when maintain those software components. The superficial benefits would be offset by all those disadvantages.

Dedicated DU for the shared component development

In approach 2, there will be partially parallel, but a development unit will be assigned dedicatedly for the development of the common component:

a. DU_1 will work on functional component of functionality 1, the Class_B_1;

b. DU_2 will work on functional component of functionality 2 and functionality 3, the Class_B_2 and Class_B_3;

c. DU_3 will work dedicatedly on the shared component, the Class_A (and Interface_A)

Now it is obvious that the dependency between DU_1 and DU_3, DU_2 and DU_3 is created, and because of this dependency, the development speed may not be as faster as all three DUs develop in parallel. Another potential issue would be the DU_2 is working on two functionalities, could be overloaded. But are those always true? Probably not, because:

a. The dependency could be remitted by the cooperation between the individual development units, the more seamless cooperation, the less delay would be;

b. The work-load of DU_2 could be shared by DU_2 according to the real progress;

There will be more benefits with this approach, such as:

a. Clear boundary between functional components (Class_B_1, Class_B_2, Class_B_3) and shared component (Class_A, Interface_A);

b. Responsibilities of shared component will be reduced, and possibility of following the SRP(Single Responsibility Principle) would be greatly increased;

c. Interface of the shared component would be strictly controlled;

d. Dependencies between functional components and the shared component would be greatly reduced;

Therefore, less issue would be created at the integration point, and less efforts spent for the maintenance. So, with this approach, both the goal of schedule and quality could be met.

Other approaches and how to determine?

Are there any other approaches given the example design? The answer is definitely yes, but the optional approaches would be somewhat between the two that has been mentioned above, to some extent.

So, how should the correct approach to be selected, to archive the goal of development speed and quality? In my opinion, it could be determined by the organizations’ maturity in technology and self-discipline, like below diagram shows:

a. For organizations who’s high maturity in both technical and self-discipline, approach I could be selected; but it should not be a problem for them to select approach II;

b. For organizations who is less mature in technical and self-discipline, approach II would be the one most suitable;

c. For others, the approach between I and II could work for them;

To conclude, the success of the software design should not only be in technology, but also in the organization design, architects should design the organization, as well as software components, ensure the two designs support each other.