Topics

Featured in Development

Peter Alvaro talks about the reasons one should engage in language design and why many of us would (or should) do something so perverse as to design a language that no one will ever use. He shares some of the extreme and sometimes obnoxious opinions that guided his design process.

Featured in AI, ML & Data Engineering

Today on The InfoQ Podcast, Wes talks with Katharine Jarmul about privacy and fairness in machine learning algorithms. Jarul discusses what’s meant by Ethical Machine Learning and some things to consider when working towards achieving fairness. Jarmul is the co-founder at KIProtect a machine learning security and privacy firm based in Germany and is one of the three keynote speakers at QCon.ai.

Featured in Culture & Methods

Organizations struggle to scale their agility. While every organization is different, common patterns explain the major challenges that most organizations face: organizational design, trying to copy others, “one-size-fits-all” scaling, scaling in siloes, and neglecting engineering practices. This article explains why, what to do about it, and how the three leading scaling frameworks compare.

Ideal Architecture is not always about Ideal Technology or Techniques

According to a commonly admitted definition, the role of a software architect is to define “macro-aspects of a system based on the inputs from its stakeholders.” This implies that architects cannot be driven solely by technical considerations. They need to bear in mind the requirements of different stakeholders which often constraints the choice of technology and architectural design.

In his blogpost, Phillip Calçado emphasizes that, along with system users and project sponsors, the software development team is an important stakeholder because developers are very directly affected by architecture decisions. Hence, the development environment should be taken into account by the architect even though it may limit the scope of his choices and even result in renouncing to a technology that would objectively be the best for the project.

Calçado stresses, for instance, that it is crucial to take into consideration the team’s skill set:

Imagine you join a team of long time VB6 programmers to develop a new website. No one has experience with Ruby on Rails although you know that is exactly the best tool for the job. The website must be delivered in a short time frame, no time for training. Would you go for the best technical choice?

Another constraint may come from team distribution, be it physical or not. In Claçado’s example, a system for stock exchange for traders has three parts - data gathering, user interaction and transactions - with a different team working on each of them. Even if, technically, designing the system as a single module may be the best choice, the architect will rather have to design three modules that are black-boxes so that “teams can work in a fairly isolated stream.”

More generally speaking, Calçado stresses that it is essential to “collect feedback and respect the opinion of the group that will probably be most affected by your decisions.” One of commentators, Alberto Brandolini, goes along the same lines using the notion of “sustainable architecture” that requires the architect to assure that his “architectural design can achieve commitment by the team members.”

Taking into consideration this kind of constraints is important for the success of a project. This does not mean, however, to definitely renounce to a technique that would really add value to a project, because of time and skills availability constraints or resistance from the team. The role of the architect is indeed to elaborate the strategy for introducing change and to integrate it into his design:

[…] the architect should include a migration into the system’s roadmap. […] You can start by using Ruby [or any desired technology] whenever a script or small program is needed, for example and introducing the new web development platform slowly. The most important is that you should have a clear view of what the system should look like in the future and how to make this come true.

Community comments

Compromise?

Your message is awaiting moderation. Thank you for participating in the discussion.

Wouldn't we be diluting the importance of the best solution arrived through systematic means by letting other factors influence the architecture/solution?I understand that getting a commitment from the development team for the architecture is important. But if the current choice of developers are a mis-match to the 'best solution', should we be changing the solution such a way that it can be implemented by the developers in their current state?

Wouldn't we be compromising the long-term impact of the solution and in turn the customer's interests if we were to choose a solution other than the one that suits the problem the best for whatsoever reason?

Then it's not the best tool

Your message is awaiting moderation. Thank you for participating in the discussion.

In both the main article and the quotes it is argued that a given technology may be the best choice but when taking the development environment into account there are reasons to choose a different technology.

[...]even result in renouncing to a technology that would objectively be the best for the project.

Imagine you join a team of long time VB6 programmers to develop a new website. No one has experience with Ruby on Rails although you know that is exactly the best tool for the job. The website must be delivered in a short time frame, no time for training. Would you go for the best technical choice?

Given those statements how can you even present the option that the first technology is the best choice when clearly it isn't given the full constraints of a project. I find that arguments such as these demonstrate a narrow view of what an architectural "solution" is meant to be. The architect must always take into consideration the development environment and skills as well as the business requirements, infrastructure and budget when designing a solution.

I argue that the "best technical choice" is the one that best fits all of the constraints of the project including the development environment, which is not what is implied by some statements in this article. So my response to

Imagine you join a team of long time VB6 programmers to develop a new website. No one has experience with Ruby on Rails although you know that is exactly the best tool for the job. The website must be delivered in a short time frame, no time for training. Would you go for the best technical choice?

would be a resounding YES! because in this case it may very well be classic ASP and VB6 as the correct technical choice given all of the constraints.