New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Ideal Architecture is not always about Ideal Technology or Techniques
Posted by Sadek Drobi on Feb 22, 2008
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.
Compromise?
by
Kiran Dasari
Posted
Then it's not the best tool
by
Larry Guger
Posted
-
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? -
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 toImagine 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.
2 comments
Watch Thread Reply