Software Architect and Architecture

In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called architecture

대부분의 성공적인 프로젝트에서, 일을 하고 있는 개발자들은 시스템 디자인에 대해 공유된 이해를 가진다. 그리고 이 이해를 아키텍쳐라고 부른다.

this understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components but the architecture only includes the components and interfaces that are understood by all the developers.

Architecture is a social construct because it does not just depend on the software, but on what part of the software is considered important by group consensus.

Whether something is part of the architecture is entirely based on whether the developers think it is important.

아키텍쳐의 일부가 될지 말지는 전적으로 개발자들이 중요하다고 여기는 기준에 따른다.

People who build “enterprise applications” tend to think that persistence(Database) is crucial. When they start to draw their architecture, they start with three layers. They will mention “and we use Oracle for our database and have our own persistence layer to map objects onto it”. But a medical imaging application might include Oracle without it being considered part of the architecture. That is because most of the complication is in analyzing the images not in storing them. Fetching and storing images is done by one little part of the application and most of the developers ignore it.

Tell us what is important

Architecture is about the important stuff

Architect’s role

There can be two different types of architects.

A is the person who makes all the important decisions. The architect does this because a single mind is needed to ensure a system’s conceptual integrity, and perhaps because the architect does not think that the team members are sufficiently skilled to make those decisions. Often, such decisions must be mad early on so that everyone else has a plan to follow

B must be very aware of what’s going on in the project, looking out for important issues and tackling them before a serious problem. When i see an architect like this, the most noticeable part of the work is the intense collaboration. In the morning, the architect programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain to the requirements people the technical consequences of some of their ideas in non technical terms- such as development costs.

The most important activity of B is to mentor the development team, to raise their level so that they can take on more complex issues. Improving the development team’s ability gives an architect much greater leverage than being the sole decision maker and thus running the risk of being an architectural bottleneck.

Architecture is the decisions that you wish you could get right early in a project?

Why do people feel the need to get some things right early in the project? The answer, of course, is because they perceive those things as hard to change. So you might end up defining architecture as “thing that people perceive as hard to change”. It is commonly believed that if you are building an enterprise application, you must get the database schema right early on because it is hard to change the database schema- particularly once you have gone live. On one of our projects, the database administrator devised a system that let us change the database schema and migrate the data easily. By doing this, he made it so that the database schema was no longer architectural. I see this as an entirely good thing because it let us better handle change.

One of the differences between building architecture and software architecture is that a lot of decisions about a building are hard to change. It is hard to go back and change your basement, though it is possible.

Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. That, and duplication.

My reservation of Aspect-Oriented Programming is that we already have fairly good techniques for separating aspects of programs, and we don’t use them. I don’t think the real problem will be solved by making better techniques for separating aspects. We don’t know what should be the aspects that need separating, and we don’t know when it is worth separating them and when it is not.

Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. “We have met the enemy, and he is us.”

Knowledge is a only wealth that grows when it is given

if i give you a 10dollars, i will be poor by 10dollars, but if i sit down and share my knowledge with you i will become richer while you become richer as well because when explaining things to you i begin to realize that i don’t quite understand it like the way i thought i understood it.

Diversify your knowledge portfolio

The person who knows one thing really well is dangerous, why?, because the more you will know the more you get comfortable doing something the less you are gonna be capable of doing something else. we should learn at least one new language each year(Pragmatic Programmers).

Criticize ideas not people

Architecting is evaluating tradeoffs

Guide, don’t dictate

It is so easy for us, in times we live in, “oh we don’t have time”, “finish this now” and we can get to the point where we as an architect may decide that we gotta tell everything and people just have to follow and that is dangerous. Give opportunity for people to figure things out, give them a little guidelines but not prescription.

I know of only one way to write readable code — ask a colleague to read it.

Allow Developers to figure it out

It should be safe to be honest

Time box efforts

We make the system so extensible that won’t do anything anymore

In some companies the work architect means i don’t code anymore.

Architectural committee is where innovation goes to die.

Has standardization let the stagnation? if standardization let the stagnation that is a disservice to your organization

world moves on but the architects have standardized on something they knew coming in and they are fearful to change because they don’t know what the change is

Avoid being a powerpoint architect

Every technical decision should have an expiration label.