GEOG 583
Geospatial System Analysis and Design

Reading Assignment

PrintPrint

Read

What is a Software Architecture? by Peter Eeles of IBM. This will give you a high-level, authoritative view of what a software architecture consists of.

Think About

What parallels do you see between the designs of software architectures and the other design activities we have covered so far in this course? In a lot of ways we are covering the major pieces of an overall "structure" of design in this course.

Read

Esri guide to the ArcGIS Software Architecture, pages 1 through 6.

Respond

This is a good summation of how Esri conceives their system architecture. It's aimed at ArcObjects developers, so don't worry about programming details at this point. Just try to get a feel for how the pieces fit together, and in particular, try to think of how the definitions of software architecture from the first reading play out in the context of ArcGIS (or other GIS systems). Respond to the readings by posting your take on how the second reading (on Esri's architecture) fits into the categories in the first reading (on software architecture). What is missing from the Esri document that the IBM article mentions? To get credit for this assignment, you must post at least one original comment and respond to at least one comment by your fellow students. I encourage you to include links to other content that bolsters your argument.

Note

To post a comment, scroll down to the text box under "Post new comment" and begin typing in the text box, or you can choose to reply to an existing thread. When you are finished typing, click on either the "preview" or "save" button ("save" will actually submit your comment). Once your comment is posted, you will be able to edit or delete it as needed. In addition, you will be able to reply to other posts at any time.

Don't see the "Post new comment" area below?  You need to be logged in to this site first. Do so by using the link at the top of the menu bar. Once you have logged in, you may need to refresh the page in order to see the comment area below.

 

Comments

ars345's picture
Submitted by ars345 on

I think the ESRI reading generally addresses the points made in the categories within IBM paper; however there are some missing elements and too much detail in places. For example, the ESRI document identifies the significant changes to the ArcGIS architecture going from ArcGIS 8.0 to 9.0 in one-sentence summaries (which are good) but then goes on into the kind of detail that the IBM paper warns against. This detail does however does however allow ESRI to make a good case for the changes introduced in the new version, specifically the concern about maintaining compatibility which is always a concern for users when a new upgrade rolls out. In fact, I would have moved compatibility to the top of the list for key concepts to reassure the user right away. These four concepts do fit well into the IBM paper’s definition of a design because they are the collection of components that are all interrelated.

The ESRI paper addresses stakeholder needs in the discussion of modular architecture and the attempt to balance performance with manageability in the development of software modules with the number of DLL files. Addressing compatibility, scalability, and platform support are other areas where I think the paper acknowledges stakeholder needs.  

To help my own understanding of software architecture and design, I found this short video that helped:

https://www.youtube.com/watch?v=Rn1g6V-vlHw

It proposes another definition of software architecture:

“The software architecture of a system is the set of structure need to reason about the system which comprise software elements, relations among, and properties of both”

The video argues that software architects should build models to reason through the parts of their design where they are most concerned about failure. The video notes that all other professions do this, but it’s not common for some reason in software architecture. The IBM paper does this a bit with the UML sequence diagrams, though not with the expressed goal of identifying problems with the architecture.

cjj149's picture
Submitted by cjj149 on

I missed the incorporation of scalability within my own comments and I am glad you pointed that out. When reading the ESRI article I envision the different versions of GIS provided at a price rate as modularity. In a sense the different versions or levels of the software are both modular and scalable. The specific tools are still broken out in modules yet they have been scaled to meet the end users processing requirements. You need more processing tools then you can scale the tool up for a certain price. I read that ESRI paper as an educational tool for an in-depth look at the system specific architecture whereas I viewed the article by Eeles as an introduction to how architecture works. ESRI was very specific with details of its software where Eeles discussed architecture on multiple levels.

cjj149's picture
Submitted by cjj149 on

There are many core elements from the article by Peter Eeles of IBM that stuck with me while reading the second article by ESRI. This can first be seen in the modularity of ArcGIS that satisfies the stake holder’s or end users mission by structuring multiple variants of the tool based upon end users requirements at an identified cost structure. In other words ESRI provides certain versions of ArcGIS based upon what you need it to do and prices it accordingly balancing stakeholder’s the needs. The modularity is also supplemented by providing additional tools or extensions above and beyond the base architecture for a predetermined price. In ESRI’s case a good example would be the spatial analyst extension which covers a range of tools revolving around calculating spatial relationships but goes above and beyond the base GeoAnalyst Tools. These tools and extensions are then broken down again into significant elements of groups or subgroups of tools required for doing specific tasks of like kind. (Projection and Transformation Tools for example.) Thus each module has its own sub architecture of elements that are a piece of the entire software programs architecture pie. In comparing the two articles the other thing that I notices was that Eeles article provides a base breakdown of what an architecture is and how to approach its development whereas the ESRI article went in-depth on the concepts of how its architechture is specifically designed.

akw5276's picture
Submitted by akw5276 on

I like what you’re pointing out here in terms of extensibility. I too, think ESRI has provided a great model other developers can learn from. A good architecture should consist of a main frame that provides a core capability upon which diverse users may extend when need be. This principle applies in many industries such as the automobile industry, the gaming industry and fashion, to name a few. Its simply put, the ability to accessorize in order to extend a core product thus facilitating a personalized experience. This is extremely important to end users/ customers for many reasons. One basic reason people buy things is so they can call it & make it their own. 

tbn5056's picture
Submitted by tbn5056 on

This discussion of modularity/scalability/personalization is interesting and I wonder if it works its way into another of Eeles' definitions of architecture that we haven't touched on yet - that an architecture influences team structure. For an established company like Esri that has been in the industry for many years, it would be interesting to learn how the internal team structure has evolved to fit its products. Are there teams that specialize in extensions that build upon the main structure, or is the same team who works on the core capabilities also responsible for the expansions? It seems to me that there would likely be at least some degree of specialization for a company as large as Esri, but that would also provide inflexibility should they ever want to make substantial changes to their products.

adn126's picture
Submitted by adn126 on

You propose a very interesting question in regards to specialization and flexibility.  I have heard of numerous companies that take an interesting approach to employee onboarding by exposing them to the entire corporate structure.  I have a fairly new coworker who began working for a large multi-national company in the early 1990's with a degree in systems engineering.  The company kept her on a schedule where over three years, she worked in nearly every department of the company including research and development, finance, information technology, and human resources.   At the end of this period, she was able to choose her specialty, but she had a much better understanding and appreciation of the internal structure.  While this may seem excessive at least in terms of time spent, cross training absolutely has its benefits.  Especially for a company as large as Esri, both their team structure and software structure could potentially benefit from one another, especially when using the analogy of the software development life cycle.

tbn5056's picture
Submitted by tbn5056 on

The first article walked through several variations on the definition of software architecture, then found the the common ground between those definitions and expanded on those ideas. It noted the common use of "components" within the definitions which was also used heavily in the Esri article. From the other common themes identified in the IBM article, here are a few ways I saw them come out in the Esri documentation:

An architecture is influenced by its environment - A lot of the discussion in the Esri document focuses on the changes from ArcObject v8.3 to v9. As a result of this version change, the focus was that "ArcObjects 9 should remain equivalent, both functionally and programmatically, to ArcObject 8.3". If that is the end goal, then the ability to drastically change the architecture is severely limited. Therefore, the architecture for v9 is heavily influenced by the technical environment in which it already exists.

An architecture balances stakeholder needs - Similar to the architecture of ArcObject v9 being limited by its environment, the stakeholder needs were considered to ensure that it remained compatible to its user needs while still accomplishing its internal goals. The documentation also identifies that "the requirements of a particular object, in addition to its basic functionality, vary depending on the final end use of the object". This tells me that how the architecture was developed in terms of its "product families" was largely the result of identifying the stakeholders' needs.

An architecture defines structure/behavior - As the author in the first article stated that the structural element of architecture is fairly intuitive to people. Less intuitive is the behavior, which in ArcGIS is manifested in its modularity concept - that a well-defined system has components with strict guidelines on where they fit and how they should interact with other components.

 

apb5481's picture
Submitted by apb5481 on

That is a good observation on the part about "An architecture is influenced by its environment". ESRI knows they have something good with their ArcGIS line of products, but like any big company this can restrict their creativity. They may not usually need to drastically change the architecture, but at some point they may have to.

It would be interesting to see how often a company like ESRI does make drastic changes in their architecture. The IBM article talks about stable architecture being able to withstand minor changes, but I wonder how often a "major" change comes along for a company like ESRI. When it does, do they start from the beginning to rebuild and accomodate the new changes or do they try to fit them into the current structure? A well designed architecture likely leaves room for the ability to adapt and evolve.

akw5276's picture
Submitted by akw5276 on

Peter Eeles, Senior IT Architect, IBM, did a great job in pointing out a key declaration that cripples many organizations from the start and furthermore reveals its ugly face again and again each time a new member or outsider is introduced to the design/development team. His exact words regarding architecture are, “…be aware that these different terms exist, but that there is no consistent definition of these terms in the industry and how they relate.” Considering this truth, the ESRI paper delineates an architecture that falls within this collation made up of ambiguous definitions because ESRI’s architecture is styled specifically to meet the needs within a very specific scope, embodies decisions based on rationale and focuses on significant elements which lend themselves to a desired end-stated behavior that is both modular and scalable.

The key take away, in my opinion, is that lexicon and establishing an organizational definition is extremely important. Failure to acknowledge and manage semantics can result in widespread confusion and ultimately a blurred and frustrating outcome for both the developers and end users. 

ysh104's picture
Submitted by ysh104 on

Were you satisfied the ESRI article was able to both define and describe the core characteristics of their software architecure in the 6-page excerpt as recommended by Eeles in the IBM paper? What do you identify as key potential problems that may arise from the  failure to define a software architecture?

pad189's picture
Submitted by pad189 on

The article by Peter Eeles provides a comprehensive examination of the key characteristics that comprise software architecture and defining architecture. I think the ESRI ArcGIS software architecture paper addresses the core characteristics that were outlined in the article. The only exception (perhaps) is the balancing of stakeholders needs and, specifically, identifying the nonfunctional requirements within the ESRI paper. The paper addresses some of the stakeholders needs (user and developer) with "the ArcGIS architecture provides rich functionality to the developer" and "ArcGIS Desktop applications have a rich user experience, with applications containing many dialog boxes and property pages that allow end users to work effectively with the functionality of the object", but it's not clear until you look at the engine libraries on what the functionality is and, even then, what does rich rich user experience entail? I realize this might not be integral to the ESRI paper, but is an observation worth mentioning and something that could be explored a bit more.

ars345's picture
Submitted by ars345 on

I think you raise a valid point about the ESRI paper not clearly identifying stakeholders and defining what it means for the user to have a “rich experience”. After thinking on this a bit, I’m hypothesizing that the ESRI paper makes the assumption that its readers are probably either ESRI personnel or power users who intuitively understand what “rich experience” means. I don’t think this is a particularly sound practice, but ESRI can probably get away with it because that’s the kind of language that corporate and government seniors like to use to describe their products and services. I think as the GIS market becomes more diverse and more competitive, I would surmise people will be less willing to accept ESRI’s word that its products contain a “rich user experience” and demand more details.

bth160's picture
Submitted by bth160 on

I wonder if ESRI, in this instance, at least, needs to even identify their stakeholders. They've been in business for a long time and I would assume that they already know who their stakeholders are and that the stakeholders themselves know who they are in regard to ESRI. It seems to me that they would be content diving into the subject matter and identifying a stakeholder if they may have a particular interest in the subject matter.

ztr103's picture
Submitted by ztr103 on

The distinction I think that should be made here is that the software architecture described in this excerpt is specific to the use of ArcObjects within the various ArcGIS product families.  While the description of ArcGIS Desktop as providing a “rich user experience” is not substantiated here, it doesn’t need to be.  It’s just a passing mention, and unrelated to the rest of the excerpt.  The stakeholders that this excerpt are concerned with are solely the developers – those creating extensions on top of the provided architecture used to build the elements of those product families – and I think it actually does a good job of addressing their concerns.  When new versions of software are released one of the first questions from developers is ‘how does this change my products that are built on top of what is being changed’, followed at least to some degree by “why did you change this”.  I think ESRI actually does service to their developer stakeholders here, as evidenced in their discussion justifying splitting of the singular library into smaller ones and the associated tradeoffs.  I think a dive into a discussion about costs and other limitations presented by other stakeholder types and experienced by ESRI in making this transition are probably relevant only in other contexts.  However, if we look at Eeles’ list of stakeholder types, it’s not a stretch to imagine ESRI’s consideration of developers as also customers, maintainers, and admins, who also need to be marketed to by convincing them of the rationale behind changes that have taken place in a product on which they rely.

pad189's picture
Submitted by pad189 on

Zack and Andrew, thanks for the comments. I'm not a developer and looking at the paper is a bit challenging in this context. I'm trying to understand how it would impact other users. I realize gaining buy in from developers is important and the ESRI paper addressed the logic behind the changes.

I think it would still be helpful if ESRI clarified a bit more on the "rich experience" as Andrew suggested. The paper even mentions end user requirements stating that "ESRI has developed a modular architecture for ArcGIS 9 by a process of analyzing features and functions and matching those with end user requirements and deployment options based on the three ArcGIS product families". It's still unclear to what those end-user requirements are unless it goes back to the four key concepts outlined?

nap127's picture
Submitted by nap127 on

To add a little more about the ESRI stakeoholders.  The article does mention how external esoftware won’t necessarily have to be updated due to version updates.  This would be beneficial to the developer but maybe more importantly the end user because they would not have to purchase new versions of their add-on software.

ztr103's picture
Submitted by ztr103 on

Based upon the target audience, the ESRI excerpt does a great job of laying out the basics when it comes to how its updated architecture checks all the boxes so to speak.  The backbone of their explanation of behavior definition lies in their acknowledgement that while various objects might have different requirements based on functionality, they have continued to focus on a “commonality of function” in their architectural design.  The elements considered ‘significant’, in this case objects and the libraries into which they are organized, are defined as such based on their familiarity to the developer ‘user’.  I think this is an important note to make as it implies the effect stakeholders have on determining not just how an architecture is defined, but what pieces are used to define it.  In essence, the attributes of the group ‘developers’ helps define the environmental constraints within which the architecture was designed.  The job the ESRI excerpt does of describing the rationale behind and the tradeoffs associated with their decision to restructure libraries between releases of ArcGIS 8 and ArcGIS 9 speaks to their interest in the addressed stakeholders.  They go to lengths here to justify splitting what was previously a single larger library into multiple smaller ones.  In considering functionality and dependency, they arrived at a rationale for a redefined / updated modularity.  Their rationale continues by describing the effects on scalability of their decisions related to memory usage and threading.  The final aspects of the design environment are laid out in their discussion of multi-platform support and compatibility.  ESRI describes these elements not as though they are only unique to this particular update, but perhaps more akin to a template of considerations in which they have worked and intend to work.  This leads their overall process to feel like an established style which they intend to persist, and gives a feeling of presumed stability as well. 

If anything, based upon the software architecture components as laid out in Mr. Eeles’ article, I believe the ESRI except is perhaps lacking commentary on maintainability.  That is to say, if and how they plan on the architecture persisting or at least being expanded if the need for new objects, methods, or even libraries arises.  I think this is pretty well covered and applies within their discussion of modularity, but it’s not explicitly mentioned.  The excerpt is focused more on looking back towards what has changed rather than forward to what could (though again, some of those considerations are implied).

ysh104's picture
Submitted by ysh104 on

I agree that the six page excerpt from ESRI's ArcGIS Engine Developer Guide does a good job of describing its software architecture. Most of the characteristics of software architecture described as "core" by the IBM article are covered: as you mention above the architectural style (scalable, modular, multi-threaded, and component-based) and design rationale (version consistency and stability).

I like your descriptive phrase "a template of considerations in which they have worked and intend to work" to refer to their architectural style. It's a nice turn of phrase. 

ysh104's picture
Submitted by ysh104 on
  • Architecture focuses on significant elements: the significant elements that the ESRI architecture focuses on are ArcObjects COM components within 3 application environments--ArcGIS Engine, Server and Desktop—organized into libraries. The relative stability of ArcObjects components speaks to the conscious execution of its architectural design.
  •  Architecture defines behaviour:  ArcObject class types interact through interfaces to organize and access properties and methods.
  • Architecture embodies decisions based on a rationale: The architecture has been designed to ensure object-level compatibility between application releases. The ESRI architecture is written in C++ which allows multiple platform support as long as a system has a C++ compiler.

The ESRI article (pages 1-6) fail to discuss hardware requirements which are essential to a system architecture nor does it discuss the needs of stakeholders beyond developers.

This is a link to a very lengthy ESRI white paper  (252 pages!) –System Design Strategies—that delves into enterprise system designs recognizing all platform components including servers, workstations, and storage systems.

tbn5056's picture
Submitted by tbn5056 on


Thanks for sharing that link. I sifted through the document (no, I didn't read all 252 heart-stopping pages) looking for what you identified as missing - the needs of stakeholders beyond developers. There is a bit of it here and there and I thought it was interesting that on page 192 (section 11.2.1) that in the case study the user types were places into three categories, one of them being "The ArcGIS Desktop user type", which align with an already provided service, then the needs assessment is evaluated by looking at workflows.

Submitted by sur216 on

I think you raise a few points that I forgot to include in my own write up. The ESRI paper does not include the Hardware requirements for the new version of ArcGIS. It might not be particularly important for the developers, whom they address most brightly as the main stakeholders they discuss in this paper, but it is important for the other end users. I agree with all your points concerning the the existence of significant elements, a clear rationale in the ESRI paper. However, I think that minor attention had been paid to the interface design and I think that the substantial changes concerned the structure of the new platform.

I also skimmed through the first paghes of the link that you included. I think this is a comprehensive description of all the components and it is worth th etime to read it completely. Thanks for sharing it!

Submitted by sur216 on

The ESRI’s paper provides some points about the substantial modifications put in place for the new version of ARCGIS (i.e. ArcGIS v9). Through the first pages we can easily understand that the new modifications, as they discuss, are aimed to provide a more suitable platform for developers by improving the “commonality of function” (Page 25). In fact, the rest of the paper where they discuss about the new capacities added to this software (i.e. Modularity, Scalability, Multiple Platform Support, and Compatibility) are all centered on creating a new platform which better adapts with other environments and attract more developers to use ArcGIS. Therefore, other stakeholders that are discussed in the IBM paper (i.e. maintainer, project manager, end user, marketer, etc.) are not the addressed in this paper. Highlighting the new modifications as they fit to the developers’ needs makes sense, however, since as it is discussed in the IBM paper, architecture should focus on significant elements and avoid extraneous details. I think the ESRI paper is clear and well-grounded in terms of describing the major structural elements.

From my point of view, the four new capacities discussed in the ESRI paper try to expand the boundaries of ArcGIS which is directly related to the discussion of “environment” in the IBM paper. As Pere Eeles discusses “the environment determines the boundaries within which the system must operate, which then influence the architecture”. This could be looked as an Architecture Style as well. The new alterations in ArcGIS is aimed towards involving more software developers with substantial changes mostly centered on objects and components of the new ArcGIS. To put it more clearly through an analogy, ArcGIS architecture tries to design a structure that is more compatible to different design purposes. The same strategy was conducted for social housing in Europe after WWII, that is, designing a structure that can meet the purposes of all types of users, by relying the same things that the ESRI paper discusses (modularity, scalability and compatibility) and they called it international style. Today, this type of architecture is known as modular design.

Submitted by djp299 on

Nice Post!

You added some great points about the two articles.  You shed light on what the ESRI article and IBM article discuss with the systems architecture.  ESRI keeps changing certain aspects of their software.  The ArcGIS platform is integrated with different software and selecting the best software and strategy can have an impact on its performance, the systems management and requirements.  It makes me wonder how often they will change because of technology?

Submitted by djp299 on

The ESRI article and IBM article were interesting articles to read.  I thought it explained the basics for understanding programming architecture fairly well.  A lot of the responses had the same feelings as I that ESRI expanded on the new capabilities of the software being introduced.  From not being a programmer, it is interesting to note the platforms developers use when working with ArcObjects. In the ESRI article the author explains more about the new components that are being added to the new version.  In the IBM article the author discusses the architecture and its influences, such as the system stakeholders.  The stakeholder vs architecture becomes a clear dilemma on how the system can be created.  In the ESRI article, the stakeholder is discussed with trying to find a common ground with the performance of the new software.  Overall, the IBM article was more precise and broke down what makes the architecture.

bth160's picture
Submitted by bth160 on

After reading both articles, Esri's information appears to fit in line with some of the more specific pieces of information IBM covered, namely components and system, while touching on the stakeholders and environment.
I did notice that Esri uses architecture and components quite a bit. Whether it was to talk about the "architecture modularity" or the ArcGIS architecture, it seems that they do what IBM mentions in that there isn't Adm agreed upon language. I'd argue that the for "architectures" discussed are systems if you compared it to the IBM reading, and various components are discussed within each of their updates.

Stakeholders and their environment are discussed in the scalability section, primarily application developers and programmers.

ars345's picture
Submitted by ars345 on

I think you’re right to note that ESRI does use the term “architecture” a little more freely than what the IBM article thinks appropriate. This is a major difference between the two articles and it shows different understandings of the term. I think these different understandings create enough ambiguity to warrant more standardized definitions, particularly because GIS technology will only continue to evolve and become more complex. This makes it critical to have a common language for basic design terms.

apb5481's picture
Submitted by apb5481 on

I thought that the ESRI article was a good example of the different aspects of architecture talked about in the IBM article. It covered many of the main points, and I believe the ones it leaves out, such as Stakeholders and Hardware requirements are assumed to be already known by anyone using ESRI products. Generally speaking one should not assume that the end users are familiar with a product, but ESRI is so ubiquitous that they are probably ok to do that.
I did think that ESRI did a good job of defining the structure and focusing on significant elements with some nice color coded graphics and a list of their four key components along with a summary of each. While they don’t talk much about the stakeholders, they appear to being trying to balance stakeholder needs. In the modularity section they say “for each criterion, thought is given to the end use” and the fact that compatibility is one of their key concepts shows that they are concerned with the end user.
Overall it is clear that while the ESRI team was not writing their paper with the IBM framework in mind, they do share similar definitions of “architecture” and have designed their products and white papers as such.

adn126's picture
Submitted by adn126 on

Due to the fact that Eeles' article did not cover any one particular type of software, keeping definitions vague was necessary to remain applicable in a variety of topics.  In the case of the Esri article, while the software can be used in a multitude of ways, the end users and their activities can be planned, to an extent.  While stakeholders were mentioned briefly, Esri has provided users the ability to act as their own designers with such features as modularity and extensibility.  By designing their product in such a way as to allow the user to create their own custom tools and processes, it allows Esri to have more time to develope more tools and other features.  Unfortunately, this means that the user does need at least a basic understanding of GIS and knowledge of Esri's products.  At the same time, Esri knows that they have a specific audience who, in many cases, use their software to develop products for those who have less skill in GIS.  It is unlikely that a person, company, or agency will spend tens of thousands of dollars for a piece of software without having someone who can understand how to operate said software.  For example, I work with many people who often have a mental picture of what they need from GIS (e.g. classifying a remotely sensed image, creating buffers based on an attribute field, quantitative symbology, etc...) but they rely on someone with knowledge of the software and principles to efficiiently perform those operations.

bjo132's picture
Submitted by bjo132 on

I think you make a good point, and this speaks to the shrewdness of ESRI.  They designed a product that was able to be developed and gave is stakeholders the tools to do so.  They could have easily kept these tools in house and required its user to go through them to develop custom applications.  Allowing user the ability to develop applications within their platform is part of the reason as to why they currently hold such a large market share.

nap127's picture
Submitted by nap127 on

The ESRI software architecture description contains many of the same elements as the article by Peter Eeles.  The differences may be due to different takes on the definition of the term architecture or just amount of detail needed for the stakeholders need to know.

An architecture defines structure

The ESRI article the structure of the architecture was described in the way ArcObjects can be used by multiple application.  It describes how those objects can be used simultaneously.  This could be shown using a diagram, however ESRI chose to describe them verbally. 

An architecture defines behavior

The ESRI article described how the programs will have modularity and how they will work together and how ArcObjects will enable that.

An architecture focuses on significant elements

The ESRI article focuses on many significant objects.  It describes the 3 ARC programs, ArcObjects, DLLs, operating systems, program languages, and scalability.

An architecture balances stakeholder needs

The IBM article says architecture needs to balance stakeholder needs.  Stakeholders in the ESRI article could be developers, end users, or even the 3 ARCGIS products themselves.  The article states how the speed needed by an end user is dealt with using DLL’s which affects how the ArcObjects are created, used, and deployed. 

An architecture embodies decisions based on rationale

The ESRI article describes their rational as to how they are going to handle storing the ArcObjects and how too many DLLs is bad but also too few is also bad.  A happy medium must be found.

An architecture may conform to an architectural style

Though the ESRI article doesn’t explicitly define the architectural style it uses it does state that is uses unified software architecture.  We were not told what the scope of that structure is though.

An architecture is influenced by its environment

In order to solve the API issue between ArcObjects and some interfaces ESRI provided an alternate implementation showing they were influenced by some interfaces.  They however were not influenced by the fact that VB cannot support several implementations.

An architecture influences team structure

Team structure was emphasized with the description of how ArcObjects were going to be packaged and several DLLs and why.

 

bjo132's picture
Submitted by bjo132 on

The article by Peter Eeles provides a thorough assessment of software architecture as well as key characteristics that further define architecture. I found this reading to be very helpful, as it clarified the context of each of the architecture concepts.  The second reading by ESRI forces on the specific architecture the makes up the ArcGIS platform, which is made up of components called ArcObjects.  These components are divided into three specific application environments: ArcGIS Engine, ArcGIS Server, and ArcGIS Desktop.  As many of you have pointed out, the ESRI article did not clearly discuss the stakeholders and their needs.  Even though their needs may be understood, I still find this to be a misstep.  We always need to be cognizant of the requirements and needs of the stakeholder – they are the reason we are employed. 

I searched out some additional definitions of software architecture and how it relates to software design.  In some descriptions of the SDLC (Software Development Life Cycle) they are interchangeable, but the consensus is that they are distinct. They are comprised of different stages, areas of responsibility, and levels of decision-making.

  • Architecture is the bigger picture: the choice of frameworks, languages, scope, goals, and high-level methodologies.
  • Design is the smaller picture: the plan for how code will be organized; how the contracts between different parts of the system will look; the ongoing implementation of the project's methodologies and goals; Specifications are written during this stage.

btn113's picture
Submitted by btn113 on

After reading the IBM article, I have a better grasp on how to talk about software architecture. Especially helpful were the "an architecture is" headlines that defined some of the main components of software architecture. The ESRI article seemed to be a more pointed document relaying the structure of their system. I found that ESRI fit especially well into the defines structure and behavior headings. Their document even illustrates the way the system is to be used. The ESRI acrchitecture also "balances stakeholder needs", specifically they outline tradeoffs of modularity and the need to find a size that will work for everyone. 

Subscribe to Comments for "Reading Assignment"