The Architect In Me

On the Interaction of Social Issues and Software Architecture

2006-10-31T20:49:00.000-08:00

Most technical fields such as traditional engineering and building architecture have various standard procedures or patterns that can be applied in various scenarios as solutions to recurring problems. In software engineering/architecture however, there are no such standard procedures, the closest we have is in design patterns, and this document represents a variety of those patterns. The twist that is added by this document is one that is often ignored...the culture and structure of the organization. Knowing the social composition of a development team goes a long way to help improve the outcome of a project because it capitalizes on the strengths of the team and also prevents confusion that would otherwise result from unhealthy overlaps. Along with these strategies of divide-and-conquer applied to improve team coordination in development comes the challenge of putting the divided parts back together, and this document does a good job of revealing some of those flags. Most patterns are published listing the flamboyance of applying the patterns; however, very few actually emphasize some of the pitfalls of the patterns--this document does a good job in raising these flags.

DDD: Chapters 10 - 13

2006-10-17T19:28:00.000-07:00

These chapters were the most difficult to read in this book. Highly abstract and I did not necessarily understand some of the patterns discussed in the book--eg. conceptual contours. The other patterns such as "intention revealing interfaces", "assertions" and "standalone classes" seemed to resonate material that is generally discussed in most SE books. The "Side-effect-free functions" pattern provides a good route to program safely, if not the developers use, then for those that future developers who try to maintain the software.

DDD: Chapters 7-9

2006-10-11T18:40:00.000-07:00

Chapter 7 is another reason of why I love this book; the concepts are well explained and the illustrations are very easy to understand through the use of scenarios and diagrams. The ability to nail down the objects within a software model is a key responsibility for all architects, so being able to establish an approach, such as discussed in this book, adds to my skill set. I love reading this book because it talks about concepts that I already know, but adds a new spin on it allows me to make key decisions when things are not too clear--such us with entity vs. value objects, aggregate boundaries, integrating with legacy systems etc.

Chapter 8 expounds on the idea of refactoring and how it should be done in stages before finally arriving at a breakthrough discovery that can greatly improve the model. Refactoring is essentially like a puzzle; it starts off with little hints that gradually improve the model and then once there is a cleaner picture, provides a smoother and easier transition to the end when a complete picture is attained. I am not saying a real life software domain model will ever become a complete/perfect model (there will always be ways of refining it) but you get the point.

Chapter 9 introduces the specification as a way of introducting contraints as part of the domain model. Specification objects are introduced as possible solutions to validation, selection and generation of objects keeping the contraints in mind. It is interesting how domain-driven design is willing to comprise on decoupling the repository from the domain to improve performance by allowing the use of SQL as substitutes to holding objects in memory for purposes of querying. I don't know if I fancy the approach of trying to link the specification to the repository using double-dispatch, but I guess it is probably the cleanest way of mingling sql with domain objects. I guess this is where frameworks like hibernate make life easy for a developer.

DDD: Chapters 4-6

2006-10-07T19:51:00.000-07:00

I find it very interesting how several projects set off with the goal of generating a completely object-oriented model and basing the implementation solely on this model. We have already discussed how challenging it is to keep the code in sync with the conceptual model. Even more difficult, in my experience, is the challenge of keeping business logic out of the UI. Every modern developer knows the rule of keeping java code out of JSPs and yet in the crunch, usually when the PM is breathing down your neck, most developers take the easy way out by settling for "smart UI". Althought, a 100% separation of conceptual layers is probably impossible to attain; I am quite certain that the more separation there is the better. Especially since most frameworks of today provide the separation and allow for object plugins. Also key is the separation of infrastructure from the domain layer, allowing for easy replacement of third part components through the infrastructure layer.

Also discussed in this reading is the expression of the domain model in the form of diagrams, and also certain techniques that are used to improve the representation of objects in the model while keeping in mind the runtime effectiveness of the model. The reading also discusses the differences between entities and value objects, which along with service objects have become a common pattern used to represent models and their communications between layers. I was surprised that no mention of the use of hashCodes in java, especially EJB, was made in the chapter as a means of identifying entities--since most containers use the hashcode to identify entities that are pooled in an EJB container. Last to be discussed is concept of cohesion and coupling within modules, and why the object-oriented paradigm has become the popular choice to model domains.

Chapter 6 reveals very creative ways of representing a domain model, paying particular attention to separation of responsibilities and trying to simplify objects to allow for component replacements, reuse and scalability. Obviously, the concept of a factory in OO design is one that is frequently discussed in patterns such as factory and factory method. This chapter's strategy of creating repositories and trying to mix up the use of factories and repositories is creative and helps simplify the model. Ultimately these patterns discussed in chapter 6 lead us to understand the importance of separation and also how best to merge such concepts into frameworks and allow for plug-in development.

DDD: Chapters 1 - 3

2006-10-03T17:08:00.000-07:00

The first 3 chapters of Domain Driven Design (DDD) focuses on the critical ingredients that are necessary in producing a productive software architectural model. It discusses the importance of knowledge crunching, establishing an ubiquitous language and using the application model as basis for further development.

Knowledge crunching is very key in a team-development project that involves technical and non-technical participants. As is often the case, a group of technical developers are given the task of translating business requirements (from stakeholders) into a feasible technical solution, which makes understanding the requirements very key to the success of the project. Eric Evans emphasizes in his book DDD that key to bridging this knowledge gap is knowledge crunching which involves a healthy interaction between the development team and the subject matter experts (SME). During this process, the architect walks through various scenarios with the SME, a process that naturally starts to generate leading questions and helps generate a deeper understanding of subject. This step of interacting with the SME, to help develop a better understanding of the business rules, is a crucial art that an architect must develop. It also helps if the architect is able to use diagrams (eg. UML) to illustrate the various scenarios, but the most important part of this interaction is communication as Evans refers to as establishing a ubiquitous language.

The ubiquitos language discussed is the set of terminologies that is defined by the parties involved, and is well understood by all parties. It comprises of those technical terms that the SMEs have to familiarize themselves with as well as those business terms that the developers have to capture. A word like "code" is used so commonly, and yet could mean many different things to different people; thus, specifically nailing down the meaning of the the word would save several hours of wrong programming.

With an established ubiquitous language, the team can now translate the business requirements to a model and then to an implementation. Evans establishes the importance of tightly coupling the model to the implementation. In short, a hands-on architect is priceless to the consistency of a development cycle--yielding a software product that correlates with the design model.

SAIP (Chapter 16, 17) J2EE

2006-09-29T21:46:00.000-07:00

I have used J2EE and EJB for several years, and I certainly agree with most critics on the expensive nature of EJBs when considering the heaviness of its transaction management and RMI invocations, making it a relatively heavy weight process. In my opinion, although the use of EJB can be very expensive, the cost is really experienced with the use of entity beens and not as badly with session beens. Even with the use of entity beans, there are many techniques that can be implemented to reduce the costs of using EJB. One of which is using bean managed persistence versus using container managed persistence. EJB by default loads and stores data after every method call; thus, if the programmer can create monitors that control this load and store process for only when data changes need to be made, some performance improvement can be achieved. Also, in this day and age where hardware is cheap, we have the luxury of being able to scale applications both horizontally and vertically, and the ease of clustering and load balancing in EJB makes it a very good candidate for horizontal scaling.

In the Luther application, J2EE is used for several reasons amongst which are separation of user interface and also for the management features available through the application servers. Applicatoin servers, definitely form a huge part of the success of J2EE because of all the features they provide in terms of JDBC pooling, JNDI, JMS etc. These are all features that greatly cut down on the amount of programming required from the programmer and allow significant reuse of componenets that have been properly tested and approved by reputable organizations.

SAIP (Chapter 14 and 15) From One System To Many

2006-09-25T17:42:00.000-07:00

Software re-use is a key concept to object-oriented system developments, and can go a long way to cut down on an organization's development costs in all phases of development, starting from architectural documentation to the reuse of code components. As Bass et al. points out, the extent of reuse varies greatly from reusing snippets of code as utilities to having a framework that requires minor plugins to become its own system.

According to the author, the building of a product line is best achieved by building on an already existing architecture and recognizing similarities and variations between the design of multiple systems. The organizational structure and culture also greatly influences the success of the product line as observed in the case of Celsuis Tech where middle management was completely supportive of the project plan in developing the project line.

The idea of a project line could definetely yield a high ROI, in cases where multiple systems are bound to be developed. However, in many situations people invest so much time into developing a product line or framework which never gets reused or quickly gets outdated. The time invested into making software reusable is a cost, and unless it produces an ROI, is not worth the hussle.

SAIP (Chapter 12): CBAM

2006-09-24T06:32:00.000-07:00

The Cost Benefits Analysis Method (CBAM) is a method of analyzing software architectures to aid in deciding which proposed architectural strategies should be implemented to achieve the key quality attributes of a given system. The CBAM is mentioned as a follow up method after an ATAM exercise to weigh the ratio of benefits to cost (ROI) for a system, using the artifacts from an ATAM.

Weighing the ROI of a system to help guide in architectural decisions is key to every system that has budget constraints or seeks to keep costs to a minimum. In my experience, I find that many software developers are always eager to employ the latest and greatest techologies whenever they have the opportunity. However, in most cases, the latest technology turns out to be an overkill that has significant costs. For instance, purchasing a high-availability Oracle RAC database system for a system that is not mission critical and can survive several hours of downtime. Knowing the ROI of a system in most cases will help avoid such choices and help the architect make better business decisions through the architecture--even if not structured in the format of a CBAM.

SAIP (Chapter 11): ATAM

2006-09-23T19:51:00.000-07:00

Chapter 11 focuses on the Software Architecture review process, specifically one called Architecture Tradeoff Analysis Method (ATAM). ATAM is a step-by-step process that is designed to evaluate a proposed software architecture to determine how best it addresses the quality attributes specified in its requirements.

The results of an ATAM review is invaluable to the success of a project's architecture, but in my opinion, it seems like a very expensive process, although, the author mentions that such a review ends up paying for itself in terms of cost savings by way of avoiding pitfalls that are determined during this process. I agree with this process being a big plus in a very big and mission critical project, but for most mid-sized and small projects (as mentioned by the author), ATAM is overkill.

I think ATAM can be adopted by smaller team projects by getting rid of some of the steps and fine tuning it for smaller groups. Maybe inviting a development team working on a separate project to fill the roles of the evaluators and then having a member of the decision-making stakeholders (the client) be present for a not so lengthy process could be good enough. Better still, I would prefer an approach similar to the role the customer plays in XP, where input is obtained more often and early enough to save the architect the pain of redoing the whole architecture (worst case). I guess if it gets to that point, then maybe the architect need not be the architect for the project, and we probably have a bigger issue at hand.

SAIP (Chapter 10): Reconstructing Software Architecture

2006-09-23T06:53:00.000-07:00

Chapter 10 sends us to every architect's nightmare--the challenge of unveiling another architect's bride. Consider the abstract nature of a software architecture and the various iterations that an architecture goes through before being handed over to a development team, then consider the decisions lost in translation during implementation, and then the enhansment and bug fixes that take place over the years, not to mention upgrades to resources in the environment and the loss of members of the original development team, it is imperative that reconstructing a software architecture from the existing application is a very challenging task.

It becomes a question of degree of difficult when reconstructing an architecture. The quest is less difficult if you can round up important contributors to the original application--specifically the original architect or a team lead. Anytime a reconstructor can find some one who is able to answer questions pertaining to the architecture, the easier it is to reproduce the archictural documentation. However, we find in most cases that the original architect is no longer with the organization and various teams of developers have tailored the system in various ways, so more often than not, there is hardly anyone belonging to the original team of developers available for a reconstruction. This is where I disagree quite a bit with Bass et al., because in their suggested approaches, they seem to assume that there is an architect of the existing system present to answer questions.

The authors also suggest the use of tools to reverse engineer the system and to extract the architecture of the sytsem. In an environment that is built on a single platform with a single language, these tools can be very productive, but they are much less productive when the system is made up of different languages --since these tools are normally language specific. Also the author mentions that these tools run against the code base often miss extraction of the runtime objects, especially in a system where polymorphism is greatly used.

Ultimately, although reconstructing an architecture is not a simple task, it is an unavoidable task if a legacy system is to be reengineered successfully from a system that lacks proper documentation. There are several approaches that can be considered to ease up the process of reconstruction, and the more tools available the better.

SAIP (Chapter 9): Documenting Software Architectures

2006-09-20T18:45:00.000-07:00

This chapter reemphasizes the importance of documenting software architecture and prescribes possible templates and approaches to documenting an architecture. The authors place the audience/stakeholders as the most important target for putting together an architectural document and suggests UML as the most popular notation for represting architectural elements in the document.

I agree with the authors' suggested cookbook for writing an architectural document, particularly for not restricting the architecture to a said number of views as we witness in the 4+1 model of architecture. The author also gives examples of views that could be considered and provides us with ways of tying these views together. Views are developed based on the mix of stakeholders and the becomes an essential tool for communicating amongst the various stakeholders. The use of view catalogs and templates to ease navigation and validation of the architecture is great and, in my opinion, should be adapted in all documentation.

In my experience, architectural documents could be the most cumbersome and time-consuming documents to put together. Especially since most of it is put together before the project is tangible. Most of it is highly abstract and evolves with the project. In projects where time constraints are tight, it becomes increasingly difficult to keep the document in sync with the project architecture. And particularly in cases where the specified architecture fails feasibility tests, due to erroneous requirements or lack of resources etc, it becomes very difficult for the architect to leave real development behind and focus on correcting several pages of invalid documentation. Therefore, I embrace the idea of having teams document the various structures they work on, using an organization standard, and possibly having the architect tie the pieces together. That way, each team is responsible to keeping the documents in sync with the project, while allowing junior developers to gain a knack for documenting architectures and a better sense of understanding other people's architectures.

SAIP (Chapter 8): Fligh Simulation

2006-09-18T19:45:00.000-07:00

Chapter 8 of SAIP expands on chapter 7 by providing an implemenation example of the skeletal approach described. Here, a highly complicated system that author predicts could easily comprise of over a million lines of code, is represented as a simple skeleton of six modules. The architectural pattern was inspected and redefined to assign functionality to the various modules through the use of object-oriented decompostion. Various partitions were established and the units divided into groups. An n-square chart was used to map out the relationship between the various partitions and to indicate the flow of information between groups.

Once again another case study that helps us to grasp some of the techniques used to solve real-life architectural problems, while addressing the very important quality artributes that drive the system, and using a modular approach that helps to simplify the system and establish a framework for group development and integration of group components.

SAIP (Chapter 7): Designing the Architecture

2006-09-18T18:35:00.000-07:00

This chapter introduces amongst other things a development process called the Evolutionary Delivery Life Cycle (EDLC). EDLC is a process modelled to evolve iteratively through several releases while heavily relying on customer feedback. The architecture is driven by the most prominent functional, quality and business requirments known as architectural drivers. This process bears some similarities to Extreme Programming (XP) and Rational Unified Process (RUP), where the driving force is in the use of use-cases. The main difference appears to be in the fact EDLC includes the quality attribute requirements as a significant part of establishing the architecture.

Unlike XP and more like RUP, EDLC divides the system into various components that can be split up amongst teams of developers based on expertise. The author advises that a high-bandwidth of communication needs to be established for intra-team communication and smaller bandwidth for inter-team, warning that an overdose of inter-team communication could become a disturbance. Therefore, it is highly important the architecture defines an appropriate modular division for team development. I agree with the authors assessment of the importance of team communication during large projects. I think that factor is often overlooked, and probably a good way of assessing a successful project manager or architect is their ability to put together cohesive teams--not just for their skillset but also for thier chemistry.

EDLC incorporates Architecture Driven Design (ADD), ADD captures a sufficient portion of the architecture, just enough to be able to establish a skeletal system that the software can continue to iteratively build on. The skeleton provides stubs that allow the various components to interface with each other, allowing the different modules to develop indepent of each other.

SAIP (Chapter 6): Air Traffic Control

2006-09-18T13:17:00.000-07:00

This case study reveals how various tactics are used to provide architectural solutions that address the various quality attributes of a very demanding and complicated system that holds a ton of stakeholders and is highly fault intollerant.

A case study of this nature always comes in handy as a practical way of illustrating a proposed process to software architecture. It helps to put things in perspective, and let's the reader know the timing of each step in the process and which tactics can be used. Even though, the author clearly states that this project never went live, which sort of takes away from the project's credibility, it still allows us to get a better understanding of the process as discussed in previous chapters.

The questions that creep into my mind as I read through the chapters were more in the area of:
What kind of architect is required for a project like this? Can any architect come in and learn enough about avaition before scoping this out?
It almost sounds like an architect must be a jack of many trades to be able to determine what network topologies are availabe, what sort of hardware redundancy options are available, what kinds of security layers, etc.

SAIP (Chapter 5): Achieving Qualities

2006-09-14T18:47:00.000-07:00

Summary of Chapter 5 of SAIP
This chapter builds on the previous chapter (4), which discusses general and specific scenarios in developing a system. How can these qualities be achieved? This chapter takes it to the next step by providing the architect with tactics to achieve these qualities. As defined by Bass et al., "a tactic is design decision that influences the control of a quality attribute response." Just as tactics can be obtained by studying previous architectural solutions to achieve quality attributes; we can also obtain tactics by studying existing patterns to determine the architectural strategies used to attain levels of software quality. For example, in this chapter we see how fault recovery, fault detection and fault prevention can be used to achieve greater levels of software quality.

SAIP (Chapter 4): Understanding Quality Attributes

2006-09-14T17:53:00.000-07:00

Summary of Chapter 4 of SAIP
This chapter discusses the other essentials of software architecture outside of the functional requirements. It discusses the non-functional requirements (quality attributes) that the architect needs to consider in fulfilling the software requirements. These quality attributes are achieved through the various phases of the project, but often begins by getting a good architecture in place. This chapter provides some key strategies to communicating quality attributes through the architecture.

The book lists 6 parts to developing general quality attribute scenarios to represent the software requirements and then shows how these parts are represented in qualities such as availability, modifiability, security etc. For these general requirements to be made useful however the general quality attribute scenarios need to be made more specific (concrete) to the application under discussion to serve both documentation and requirements for future phases, and in some cases make the requirements testable.

SAIP (Chapter 3): Architecture for the A-7E Avionics System

2006-09-10T15:16:00.000-07:00

Summary of Chapter 3 of SAIP by Bass et al.
In this chapter, we are introduced to the motivation behind the architecture of the A-7E by the Navy and some of the modular structures used to define its architecture. The architectural structures used in this architecture are decomposition and uses (modular) and process (Component-and-Connectors). I particularly liked the motivation behind this project--Parnas' goal of proving that his design techniques, such as information hiding and cooperating sequencial processes, can be used in a system with tight constraints and inflexible requirements. In an era (pre 1977) where performance was the overriding goal in embedded systems, it was key to achieve a system that is object-oriented, allowing for change while also maintaining high performance.

Key to modular design is the concept of information hiding. Information hiding, as used in this context, is the encapsulation of the system details that are likely to change together into a single compenent, hiding it from other components. Other components are then only able to see the interfaces of the component, which are the details that are fairly constant over the life of the system. We are introduced to the term "module guide," which is a document that describes the modular structure of the system in a tree structure-- a node representing a module and its children representing submodules. The module guide does not describe intermodular activity, but servers as a roadmap to understanding the modular structure of the design.

In the final design, we see how the various structures are implemented. The modular decomposition structure is used to represent objects and logical components of the system and their design-time relations and serves as a means of dividing the project into implementation units. The modular uses structure is used to reveal how the various components relate to each other at runtime using their interfaces (procedures). The process structure then describes the parallelism of the system through the use of sequential processes. I thought it was particularly interesting that the architect decided to use a multi-processor design for a system that had a uniprocessor; an indication that a good architect must be able to look beyond the current environment and allow for system extensibility since enrionments are constantly evolving.

SAIP (Chapter 2): What is Software Architecture

2006-09-09T10:14:00.000-07:00

Summary of Chapter 2 of SAIP by Bass et al.
Chapter 2 focusses on explaining the definition of software architecture introduced in chapter 1. It clarifies what is meant by structures, their relations and which properties (private or public) that play key roles in developing the architecture. What is a structure or architectural element? These terms are very open in the definition and can be filled in with various components such as objects, libraries, third-party products, databases etc, thus making the definition extremely powerful in the way architecture can be represented.

Further discussed is the difference between architectural patterns (or styles) and architectures. Emphasizing that, while selecting an architectural pattern is often an architect's first design step, the two are very different, with architectural patterns serving as constraints for a system architecture. The author uses the classic architectural pattern, client-server, as an example; indicating that several architectures can enforce the client-server pattern and yet be considerably different architectures.

Also mentioned is the role of reference models and reference architectures in defining a systems architecture. A reference model is established here as being the division of a system into functional components and the dataflows between them that can be separately developed. The reference architecture then becomes the mapping of the reference model onto the software elements (a software element could map to several functional components, or be simply one-to-one).

The author does a good job of distinguishing system architecture from software architecture and then goes on to specify the importance of specifying which architectural view is being discussed--during architectural discussions. He distinguishes the structure of an architecture from its view--the view is the structure as seen by a particular stakeholder, while the structure represents the actual set of elements and their relationships.

SAIP (Chapter 1): The Architecture Business Cycle

2006-09-08T23:45:00.000-07:00

Summary of Chapter 1 of SAIP by Bass et al.
Chapter 1 primarily addresses how architecture generally fits into phases of software engineering. It defines software architecture as the "...structure or structures of a system, which comprise the software elements, the externally visible properties of those elements, and the relationships between them." The authors seeks to correct the general misconception that the design of a system is manufactured from a single ingredient--software requirements, and further elaborates on the key environmental properties that need to be further considered to gain a solid architecture. In short Bass et al. view the architecture process as a cycle, Architectural Business Cycle (ABC): technical. business and social environmental factors influence the architecture which subsequently influence the development of future architectures--emphasizing the importance of case studies and the study of previous architectures in developing new system architectures.

This chapter lists some of the popular environmental influences that should be considered when developing a software architecture. Some of the key influences discussed include:

The developing organization--employee skillset, long-term investments, available resourses etc.
Architect's background and experiences and the technical environment.

How does one know if the architecture is good? The authors address this question by reemphasizing the fact that each no one architecture solves all problems--an architecture satisfies a family of systems. However, there are guidelines to the process of engineering an architecture that will generally help to improve the outcome of the architecture as well as its feasibility. Some of these processes include having a very small subgroup of the team as architects (if not just one person), having a measurable architecture etc.

I generally agree with the author's approach to software architecture and the need to have a well structured organiazational process in developing an architecture to enhance reuse and uphold the concept of ABC. However, methodologies such as XP seem to be very successful and yet deviate enormously from this approach or the architectural rules suggested by the authors, which even further indicates that there is never one answer to developing a software solution.

The 4+1 View of Architecture

2006-09-04T16:07:00.000-07:00

Summary of the Architectural Blueprints - The 4+1 View Model of Software Architecture by Philippe Kruchten

In this article the writer attempts to add a new twist to the general definition of architecture that we have witnessed so far in our readings. He agrees with the definition by Perry and Wolfe that Software architecture = {Elements, Forms, Rationale/Constraints} and applies this definition to 4+1 views, primarily represented by the way the various stakeholders view the system. The +1, to me, is what separates this definition of architecture from the others we previously saw because it makes the scenarios (use-cases) a key part of the architecture and thus provides a means of validating the architecture. Also as the writer mentions, besides the scenario view, the other 4 views can be omitted based on the architectural needs of the system.

Architecture, Design and Implementation

2006-09-02T18:45:00.000-07:00

Summary of Architecture, Design and Implementation by Amnon H. Eden and Rick Kazman

In this article, the authors try to describe qualitative differences between three key steps of software development--architecture, design and implementation. To accomplish this goal, they introduce two key terminologies (Intension/Locality thesis)):

Intensional (vs. Extensional): An abstract specification that covers an unbounded range.

Non-Local: (vs. Local): An abstract specification that covers all parts of a software system.

The article describes each of the steps as they relate to these two attributes of software development. By defining such abstract concepts with such terminology, the authors provide us with a formal means of discussing such abstactions.

Personally, I found this article to provide a good separation between the three concepts that can be used as used as a guide in writing up softward architecture/design documents, specifically in cases where these tasks are performed by separate members of a development team.

Intro to Architecture...

2006-08-28T08:40:00.000-07:00

Summary of Readings
An Introduction to Software Architecture, by David Garlan and Mary Shaw
This is a very interesting and detailed paper that discusses the importance of software architecture and also provides details of various approaches to developing a software architecture.

I particularly enjoyed the practical illustrations through the use of case studies. I had actually read about the Parnas problem in one of my earlier classes with Prof. Johnson--I want to believe it was Software Engineering II--so I could particularly relate to the approaches discussed. Overall the case studies were a good illustration of how different architectural styles address different design problems, and how a set of architectural styles can be combined as a solution to developing a framework.

As old as this paper may be, it still covers the very foundation of architectures that we use today, and the definitions remain the same in terms of elements and their connectors.

Published Software Architecture Definitions, by Carnegie Mellon Software Engineering Institute

This reading tries to separate the the definitions of Software Architecture into three main categories...
(1) Modern definitions
(2) Classic definitions
(3) Bibliographic definitions

It notes that modern definitions emphasize four main attributes of software architecture and and its attributes. They are as follows:

Software architecture is an abstraction that emphasizes the external properties of a system and suppresses the internal details of the implementation.
A well architected system contains more than one structure, and is often structured in a way that makes it divisible amongs implementation teams.
Every system has some kind of architecture. The architecture might not be obvious or even comprehenisible, but it still exists--which emphasizes the need for proper architectural documentation and revision.

Further reading through the classic and bibiographic sections, reveals that there is great consistency in the definitions over the years. The 3 keys that are consistent in all definitions, however, are the elements of the system, the interfaces they provide to the outside world, and the connectors between the multiple interfaces of the elements.

It is evident from these readings that it is essential, in becoming a good architect, to familiarize myself with various architectural styles, if not for any reason, to be able to discuss and understand existing architectures. But even more so, to be able to combine these existing styles into new structures and frameworks that can be utilized in solving software problems.