The Architect: The Success Key of the Project

Introduction

Sometimes there is some hidden correlation between two or more process development steps, that could generate many unsuspected problems. In this article the goal is to discover the impact of architect decisions on other actors involved in a project.  

The impact of the architect on the project actors 

Let’s take as example one common architecture mistake, it’s the high coupling with the technology used, here’s a scenario showing this problem: 

A company want to develop a C++ application, the architect choose to use COM components, and decide to put all the implementation inside these components, and not isolated them into a basic C++ classes. 

The question is this mistake very common? The answer is YES , and to check that just search for COM samples and almost all samples put implementation inside COM components. the same remark could be applied for other technologies like EJB. 

What’s the impact of such practice on different actors? 

Human resource manager

If a C++ project is highly coupled with COM technology, all C++ developers searched by the HR  must master also COM. It’s very difficult to find a good C++ developer and find one who master also COM will be more difficult. So it will take more time to find the good profile and the risk to not choose  the right developer is high, and of course it will impact the project development. 

And the big problem is that no one will blame the architect, but the person  on charge to find the developer with these skills, and he is  considered as incompetent if he doesn't find the good candidate. 

Architect and designer

When the project is highly coupled with other technologies and frameworks we lose of flexibility, and any migration or adaptation of the project to other context  like WebService will be more difficult. however if the application is low coupled we have just to adapt it by developing some wrappers instead of changing all the code. 

Developer

Any technology has its difficulties and we need some time to master it. Transmit the  technology complexity to the whole project will add a time overhead, and implies more bugs to the code. 

If someone  has already participate to a COM project, he can imagine the number of bugs generated by the COM layer, it’s not due to COM itself but to lack of knowledge from developers, and it’s also true that COM is very complicated. 

Tester

For unit testing it’s very difficult to isolate just our code and test it if it’s highly coupled with other technologies and frameworks. and unfortunately sometimes a basic test will take hours instead of minutes. 

For example when using COM components , how many times we spent searching in the registry why a component is not existent.

The same remark for other technologies like EJB, many hours are spent to configure the application server  like JBoss. 

Concrete example of the impact of architect choices 

It’s nice to use technologies and frameworks to accelerate the development but use them carefully and avoid as possible unnecessary coupling. 

The good approach is to focus more in the business layer which is the added value of a project and the technical layer must be only an infrastructure, and we doesn’t have to spend a lot of time in it.  

To be more concrete, let’s see how two managers will realize a project using COM technology. 

Manager 1: Focusing on technical layer

The first manager will first try to search for developers who master COM components, it will takes more time and energy but it’s obligatory for him to implement a project as he expect. 

He will begin with a COM implementation and since the beginning of the project he add a complexity to it, and also add useless dependency , even if the team contains just COM Gurus an overhead time will be spend in the COM Layer. 

So finally this kind of manager will participate in an unpopularity of C++, and every basic C++ developer will say “C++ is very complex”. 

Manager2: "Keep it simple" manager

The second manager try to look for only one developer who master COM technology and the rest of the team are basic C++ developers. 

This manager tell to his team to forget COM and just implement POCO objects ,simple classes that use a simple types to implement a business layer, and only one developer who master COM technology develop a wrappers around the POCO objects. 

So finally the "Keep it Simple" manager win a lot of time to look for developers and to implement the project and almost the whole project is developed with a basic C++ concept, and isolate the COM technology complexity and limit dependency of the project . 

With this approach every C++ developer will say "WOW developing project that use COM technology is very simple". 

Conclusion

If you are architect doesn't underestimate your role and  try to avoid useless dependencies, it can multiply the development time of a project.  and make the task more complicated  for the project actors. 

However if the application is well designed, the task became easy for all actors, and the project has more chance to succeed.