Who needs an Architect?

For the start of this article, the author starts telling us about the architecture and the difficulties that you may have defining the software architecture's function. As it's stated into the first page, we can find a definition according to the IEEE's definition, but it's considered by Ralph Johnson as a bogus definition, understanding that all the terminology used it's from the developing perspective, ignoring totally about the "others perspective" and just focusing in the opinion of the developers as the most important components into a particular system.

One of the most interesting parts that I've found into this text is when the author mentions that a great architecture tries to eliminate the architecture. This perspective, that we must procure for all the system to be modifiable and to be easy to change, it's not really familiar to me, because I didn't learn for the systems to be modifiable, even when sounds logical when you think in agile methods as one of the most popular tendencies to make new software. This is not only a really good justification for us to learn about patterns, but also a great way for getting conscious about the actual "bad practices" we've been learn all our career, even when we document or we have unit tests in all our programs, maybe we haven't questioned the way that we conceive the process for making software itself.

Finally, the most important thing to change for me is to stop seeing the software and the software projects as something that won't change in time, maybe stop thinking that all of the things that I'm programming will follow the initial thoughts or the original design, and start programming in order to prevent that any change that may be made in a near of far future could damage the program that I'm making right now.