SAIP (Chapter 16, 17) J2EE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.