“Do you think architecture is expensive? What about the lack of architecture?”
I always ask my students in class: “What is worse: Bad planning or no planning”? I don’t really expect a definitive answer. My purpose with that question is to help them develop an architect’s mindest and to make them aware of architectural concerns. Personally, I think that a bad plan is worse than no-planning because with no-planning maybe we can still adapt as we go. The ideal scenario, however, would be to have a great plan which is actively maintained and adjusted. But how to start? How to make a great plan?
The principles that guide a software’s blueprint can be split in two categories: (a) The System’s Design concerns; and (b) The architectural concerns.
On System Design, we plan the tech stack, the data flow, code organization, the classes and it’s interconnections, and so on. The level of detailing that we will establish will depend on many factors such as the type of software we are creating, the profile of the developers we have, and much more. Embedded software for airplanes, for example, will generally be more documented and planned in detail than an e-commerce app.
The discussion on who, how, and how much of System Design we should perform is extensive and not really the goal of this article. The main point I want to make refers to the second type of principles that should guide the creation of software blueprints: The architectural concerns.
As a Front-end Architect, you should take into consideration a wide range of criteria that will allow for the success of the application on both the short and long terms. That variety of concerns makes it so that sometimes we don’t have a clear definition of what is and what is not our responsibility. So the best thing any Architect can do is to take to themselves the responsibility of making software development and software products successful, by any means necessary.
To achieve that success, sometimes we need to go around and make sure that good practices are being followed. If they are not, we step in to do one of two things: (a) Do the right ourselves; and (b) Delegate responsibilities to people so they can do the things that are necessary.
No architecture can be successful if the planning is done wrong. If the initial premises of a system are incorrect, the project itself has a high chance of failing. In the best-case scenario, if the team finds ways to adapt to survive, the adaptation will likely come too strong and cause substantial modifications to the system, which would lead to higher costs of maintenance, lower quality of code, and unpleasant work environment.
In other words, it is essential for architects to make sure that the initial premises of the project, which substantiate all the subsequent architectural decisions, are correct and precise. That is why architects should always be involved in the planning phases of all projects. Also, during those meetings architects have a special opportunity to make other stakeholders aware of the latest technologies, things that are coming or being deprecated on the technical world, observations related to benchmark and trends, what other teams have already done around the company, etc.
Now that we have established that architects should watch out for the premises that guide the fundamental decisions related to software development, the next step is for us to know what exactly we should be looking for. Which directives should we give to those involved on the planning phase? Which information do we need in order to make well-educated decisions and make software development and software products successful?
The worst thing that can happen is for us to be successful in what doesn’t matter.
Fabio Nolasco
That brings us to the main topic of the article: User-centered Planning. Companies like Amazon put a great focus on customers, and rightly so. They might might miss or sacrifice things related to employees’ satisfaction, but they make their customers so happy that their rewards become quite visible. We will discuss the importance of working on “employee retention” on another occasion. For now, I just wanted to point out how “customers” are (or should be) in fact the number one source of directives to guide architectural decisions. Not the only one, but certainly the main one.
That is why I was so happy when I saw this video from Google DSC. It is an excellent reminder of how fundamental it is to have a well-defined set of problems that our systems are aiming to solve… and how those problems should be captured and understood from the customers’ perspective. Two of the most critical and essential principles for high-quality software planning.
Thank you, Arman!