This paper examines the respective roles and responsibilities of instructional designers and software architects as well as the context of the environment that each type of professional typically operates in. The extent to which instructional designers are seemingly rediscovering design and development team structures and methodologies, grounds already heavily covered in the computer science field, is explored. The thesis of the paper is that instructional designers have much to gain from the computer science literature covering the architectural approach to software design, and that recognizing this literature may liberate instructional designers to focus on pushing the boundaries of learning theory and instructional design concepts.
Software architects and instructional designers belong to distinctly different, but related, professions, with their own unique literature describing roles, responsibilities and practice. It is my thesis that much of the literature of the instructional design and technology field seemingly rediscovers the grounds already covered in the computer science field. In writing this paper, I have focused my attention in the area concerning software development practices and team structure and dynamics that lead to successful end products, themes covered by authors such as Gustafson and Branch (2002), Lang (2003), and Davidson (2003) within the instructional design field. This "rediscovery" phenomenon is especially evident of the literature covering the instructional designer's roles on teams developing hypermedia and other computer based instructional solutions (as opposed to non-computerized instruction).
The heavy focus on researching development practices and methodologies is understandable as Brooks states (as cited in Lang, 2003, p. 243), "software systems are amongst the most complex of all human inventions. It can be difficult to visualize their conceptual structure because they do not contain any readily identifiable geometric representation."
The terms architect and designer as nouns, and system and software as adjectives to these nouns are used interchangeably within the literature. For example, Kuhn (1998) describes Mitchell Kapor's suggested role as an "architect," never mentioning the term "designer" as evidenced in this quoted phrase:
In his 1991 "Software Design Manifesto," Mitchell Kapor suggested that software practitioners needed to "rethink the fundamentals of how software is made" and proposed the architect's role in building design as a fruitful analogy for software professionals seeking to reform software practice. (p. 65)
Yet, reading Kapor's 1991 paper (republished 1996), we see that Kapor clearly uses the term "software designer" throughout his manifesto, "The software designer should be the person with overall responsibility for the conception and realization of the program" (p. 4).
Indeed, the definitions of "architect" and "designer" are so similar it is no wonder the terms are used interchangeably. From Merriam-Webster (2004):
1: a person who designs buildings and advises in their construction.
2: a person who designs and guides a plan or undertaking.
1: one who creates and often executes plans for a project or structure.
2: one that creates and manufactures a new product style or design.
For the purposes of this paper, the software architect, system architect, system designer and software designer roles are all considered the same roles. As with the software architect role, a similar case is made for the terms of instructional designer and instructional technologist:
The term "instructional designer" is less familiar outside the field of instructional technology. Instead, one hears job titles such as industrial designer, curriculum developer, learning specialist, instructional technologist, or sometimes even project manager. Yet people in these titles are often carrying the responsibilities of an instructional designer. (Liu, Gibby, Quiros, & Demps, 2002, p. 196)
This paper refers to these roles as software architect and instructional designer respectively as these are the most predominant terms used in the literature cited. When referring to the software architect, reference is made primarily to the literature found in the software development and computer science fields whereas the instructional designer-centered passages are culled from the literature in the instructional and educational fields.
This paper utilizes the literature review method to draw its assertions and conclusions by examining numerous research papers and printed materials in both the computer science and instructional design fields. A wide range of literature covering methodologies, models, notation systems, roles and general practice were examined in an effort to understand the totality of the culture and terminology utilized in the respective fields. In doing so, I aimed to draw consistent and cohesive lines between the two fields. A balance of topics was sought in each field with roughly half of the referenced works pulled from the computer science domain and the other half from the instructional/educational domain.
The software architect role on a development team, although not a new concept, is one that, until recently, was struggling to take root and gel with the software development community. One of the first authors to gain widespread notice in drawing an analogy between software development and the building construction process, specifically that of the architect's vantage point was Hooper (1986) in her chapter titled, Architectural Design: An Analogy. Since then, there has been an outpouring of papers, books, and discussions of the architect analogy and composition of development teams around the notion of architecting software systems.
Generally speaking, "architects are seen as people who spend the lion's share of their time up front: listening to clients, understanding the totality of their needs and resources, scrutinizing feasibility, forming a practical vision of a structure, and creating a blueprint" (World Wide Institute of Software Architects [WWISA], "Role"). The Software architect responsibilities include: (a) identifying requirements/needs; (b) drafting deliverable specifications; (c) designing the system's layout/blueprint and development approach; (d) verifying the specification; (e) reporting the verification results; (f) reporting the results of feasibility studies (Bredemeyer, & Malan, 2000; Dikel, Kane, & Wilson, 2001; Muller, 2004; WWISA, "Role").
In addition to the above systematic approach responsibilities, "an architect is the client's advocate and the one most able to assess the totality of the client's needs and resources before construction even begins" (WWISA, "Client"). "To attain the role of true advocate, the architect needs an expansive repertoire - culling design elements from an unfettered spectrum of choice. An architect ceases to be an advocate if tethered to a prescribed set of technologies, tools, or methodologies, only narrowing the solutions available to the client" (WWISA, "Role").
"Architects have a unique vantage point. Having responsibility across the whole system, they can solve problems in a way not available to component designers and implementers" (Malan & Bredemeyer, 2002). Because of the software architect's spanning role, he is also thrust front and center into the political arena in which he needs to identify the stakeholders (those interested in a software system's construction) and lead them through the entire process. An architect "must understand whose interest and participation is essential, what they must do, and what it will take to get their sustained participation and commitment" (Dikel et al., 2001, p. 131). The architects are the ones that help the developers understand architecture and the rationale behind various architectural decisions, in short, acting as consultants to the developers and lead the development community and stakeholders to rallying around the architectural vision (Bass, Clements, & Kazman, 1998; Bredemeyer & Malan, 2000; Dikel et al.).
Without a software architect filling the roles and responsibilities above, software systems almost always end up being developed in a haphazard manner without a clear vision or blueprint for how the system will be developed. The result, as Foote (as cited in Dikel et al., 2001) states, "a haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle" (p. 9). When a client engages in software development without someone filling the role of software architect, then "all but highly technical clients encounter a validation problem. The client does not really know how the finished product will look and function, the length or outcomes of construction phases, the cost, the roles, or the accountabilities" (WWISA, "Client"). "It is as though a collection of specialists are brought together, many with Ph.D's in 'Building Science.' They all have their favorite tools and materials and plan to use them wherever they go" (WWISA, "Philosophy").
Wiley (2003) aptly describes the instructional designer as "a group of people who have some understanding of both learning processes and advanced technologies, care about facilitating learning and believe that technologies can play an important role in realizing certain instructional objectives" (p. 72). There are several responsibilities commonly recognized for the instructional designer: (a) working with a client; (b) working with a subject matter expert (SME); (c) analysis of client needs, tools available, and end users; (d) envisioning, developing, and creating the solution's design; (e) evaluation and verification of the design; and (f) working with other members in a team to bring about the design (Cheng-Chang, Deets, Phillips, & Cornell 2003; Liu et al., 2002; Pettenati et al., 2001; Visscher-Voerman & Gustafson, 2004). As Liu et al. sums up, "The instructional designer must understand the needs and wants of the client, the objective and the audience of the finished project, the capabilities of the programmer, graphic artist, and available tools; and must have design and project management skills" (p. 196).
In a manner similar to the software architect role, an instructional designer's role is, neither clearly leading nor supporting (Bredemeyer & Malan, 2000; Cheng-Chang et al., 2003). The instructional designer aims to help the client make the right design decisions based on a project's goals. As with the software architect, an instructional designer must keep abreast of technological changes and should be able to discuss the possibilities of various technologies knowledgeably with the client and facilitate choosing the appropriate development path (Liu et al., 2002).
Much like the architect who is concerned with an application's process flow and usability, an instructional designer must plan instructional content and flow that the causes the student to use cognitive strategies to learn the material actively (West, Farmer, & Wolff, 1991).
With a good understanding of the client's needs and the content, an instructional designer will develop a blueprint to be executed by other team members, such as programmers, artists, and video/audio specialists (Liu et al., 2002). The idea of a blueprint is synonymous with that of the software architect's role as well as the traditional building architect's role.
Although the language and terminology are slightly different between the computer science and instructional technology fields, it should be clear how similar the role of the software architect and the instructional designer are. Both are portrayed as working closely with the client and being strong usability advocates as well as overseeing the development of a general blueprint of the project. A software architect gathers requirements while an instructional designer analyzes needs; the architect drafts specifications that are developed while the designer designs instructional materials that are to be developed; the architect performs unit and system integration tests while the designer performs formative and summative evaluations, etc. These are all congruent tasks and responsibilities. The main difference is that instructional designer is portrayed as having mastery of the learning theories and instructional design application whereas the software architect is generally portrayed as one who specializes into any number of domains.
While the software development field is still working to define and integrate software architects into the development effort, the field is also still in the throes of developing viable software development models (of which the architect analogy also springs). "Existing software process models do not provide enough insight into actual development processes to guide research on software development technologies" (Curtis, Krasner, & Iscoe, 1988, p. 1284).
Software architecture design is still considered an art by many (Bengtsson & Bosch, 1999; Curtis et al., 1988). As Weinberg opens in his 1971 classic, The Psychology of Computer Programming, "Computer programming is a human activity." The importance of an explicit design of software architecture for the construction of reliable evolutionary systems has only recently grown up considerably. "Modern applications involving distribution, portability, interoperability, component reusability and real-time approaches require an early definition of the system architecture in order to fulfill nonfunctional requirements, such as maintainability and reliability, which are crucial for the achievement of the overall functional purpose of the software system under construction" (Losavio, 2002, p. 166). Bengtsson and Bosch note, "since software architects generally have to balance a set of quality requirements, lack the data required by the aforementioned techniques and work under time pressure, the result is that, during architectural design, assessment is performed in an ad-hoc, intuition-based manner, without support from more formal techniques" (p. 5).
These attitudes about software development and architecting are widespread in industry literature and this is in spite of the existence of countless numbers of development, organizational, and social behavioral models that attempt to prescribe reliable approaches to the software development life-cycle. Whereas the instructional design field fixates on the ADDIE (analysis, design, development, implementation, & evaluation) model as their generic model of systematic instructional design approach (Gustafson & Branch 2002), the software development field has traditionally revolved around the waterfall model, widely regarded as the first formal description of software development by Royce in 1970 (as cited in Sommerville, 1989, p. 7) for the systematic approach to software development. Much like the ADDIE model, the waterfall model, as described by Sommerville (pp. 7-8), has the following general stages: (a) Requirements analysis and definition; (b) System and software design; (c) Implementation and unit testing; (d) system testing; and (e) installation/operation and maintenance.
The various models that are based on the waterfall approach are generally seen as dead-ends since they do not account for an evolutionary or iterative component of the development cycle. Bengtsson and Bosch (1999) sum up the general sentiments of the field when they state that "designing architectures is necessarily an iterative activity and that it is impossible to get it completely right the first time" (p. 5). The idea of an iterative approach has led to a second very common model in the software industry as proposed by Boehm in 1988, known as "the spiral model of software development" (as cited in Denning & Dargan, 1996). However, both of these general models are designer and product centered rather than user and action centered and unlike other engineers, "software engineers have not achieved success in the engineering design process. They have not developed a systematic method of producing software that is easy to use, reliable, and dependable" (Denning & Dargan, p. 108). Denning and Dargan go on to state that "the school of human-centered design emerged in Europe in reaction to the shortcomings of product-centered design as practiced in the standard engineering design process." Indeed much of the literature today (including virtually all of the computer science literature cited herein) focuses squarely on software architecture, a practice that is aimed at designing software that is user-centered and service oriented.
The instructional design field has a long history of developing, researching, and describing methods and models of instructional designs apparently beginning with the Barson project at Michigan State University in 1967 (Gustafson, & Branch, 2002, p. xvi). As briefly touched on earlier, the instructional design's basic generic model is captured in the ADDIE acronym to delineate the following "five major activities: (1) Analysis of the setting and learner needs; (2) design of a set of specifications for an effective, efficient, and relevant learner environment; (3) development of all learner and management materials; (4) implementation of the resulting instruction; and (5) both formative and summative evaluations of the results of the development" (Gustafson, & Branch, 2002, p. xiv).
Gustafson and Branch (2002) detail and illustrate numerous systematic design approaches and models that instructional designers are purported to use. Many of those models, when compared to software development models are quite strikingly similar. This similarity is very likely because many of these models have their roots in the spiral model first proposed by Boehm in 1988, which is also referenced in the instructional design field as evidenced by Gustafson and Branch's citation (p. 9) of the Boehm model as well as various computer science literature such as Denning and Dargan (1996, p. 110). But even more telling is the fact that the general breakdown of the activities for the ADDIE model and the waterfall models are essentially the same in both models when one side-steps the differing terminology used in describing the two models.
Through defining and outlining the roles of the software architect and the instructional designer, it should be clear that these roles share strikingly similar characteristics and mutual responsibilities. The software architect might perform a requirements gathering session while an instructional designer performs a needs analysis, but these are, in reality, the same activities in which both are seeking to understand what the needs are and the scope of the problem to be solved is. Just as architects seek to test the validity of the end-product through ongoing unit testing and final system integration testing prior to shipping, the instructional designer performs ongoing formative evaluation with final summative evaluation to produce the right instructional end-product. Where the software architect must have a solid understanding of the client's and end-user's needs and what makes for usable software, the instructional designer must understand the client's and learner's needs and what makes for an effective learning tool. The software architect must contrive of a general roadmap/blueprint using sound architecting principles to design, envision and specify the overarching design elements of the software just as the instructional designer must come up with an approach to learning that is consistently incorporated and follows sound principles of learning theory and instructional design concepts and develop the blueprint to get there.
Despite these similarities, after reviewing the research literature of the instructional design field, one easily gets the impression that the field was developed in total isolation of other fields, and indeed, H?kinen (2002) remarks:
The field of instructional design has developed separately from other theoretical orientations such as research on artificial intelligence, organizational learning and collaborative teaching and learning. Thus, the main problem of instructional design has been its isolation from other fields of teaching, learning and technology. (p. 467)
Hannafin stated (as cited in H?kinen 2002) that instructional designers have not been very open to new alternatives; they have not reassessed the basic foundations or assumptions of the model" (p. 466). I contend that we need to get away from the notion that we are an entirely unique group with unique system development needs, especially when computer software and hypermedia systems are involved. The reality is that "instructional design has been influenced by research and development both within and outside the field of instructional design" (H?kinen, p. 466). One might contend that instructional designers have unique knowledge of instructional methodologies that separate them from the software architect, but how is that different than the generally recognized requirement (Dikel et al., 2002, p. 13; Hohmann, 2003, p. 54; Bredemeyer & Mahan 2000) that software architects must be experts in their domains before they can be considered an architect? If instructional designers, especially those that deal primarily with producing hypermedia and other computer based instructional materials, really are software architects in disguise, then the instructional technology field as a whole is grossly under utilizing the literature of the software development field, not to mention more or less ignoring what's going on in computer science as a whole. Waters and Gibbons (2004) suggest that this is the case as evidenced by our lack of an advanced and elegant notation system and our inattention to notation systems that exist in other fields outside the instructional technology field.
What would be the advantage of opening ourselves up to ideas, tools, and methodologies from other fields? One example from the computer science field that can be incorporated into the field of instructional design is described in the recent 2003 study by Lohr, Javeri, Mahoney, Gall, Li, and Strongin. They examined the use of Rapid Application Development (RAD) methodologies that are prevalent in today's corporate software development centers:
In RAD scenarios, a prototype of the product is quickly created, tested for usability, and then revised. RAD can be contrasted with traditional software and training development models in which a great deal of time is spent on analysis and design prior to any product prototyping. (p. 41)
With obvious implications for instructional designers in the higher education context, they elaborated on RAD as follows:
Because RAD is just that, rapid, it brings with it a set of dynamics that most academic settings do not usually confront. The lead designer for this study had previously been through RAD processes numerous times, albeit in corporate settings?Although RAD has found an almost hallowed place in fast-paced corporate settings, the researchers in this study were initially reticent about its usefulness in an academic setting. However, the results of this study have shown that RAD can be applied to an academic arena quite effectively. (pp. 53-54)
Miller (as cited in Waters & Gibbons, 2004) strongly urged the instructional designers "to look to other fields, such as chip design or computer programming, to see how notation systems have moved to a higher level of sophistication and, in the process, contributed to the maturation of the technological field as a whole" (p. 67). This urging should apply to software design principles, development practices and methodologies as well.
"In June of 2002 the Standards board of the IEEE Standards Association approved the first truly international standard for instructional technology" (Wiley, 2002, p. 68). Wiley contends that none of the participants in this standard were members of the AECT and challenges the instructional technology field to be concerned about this lack of participation stating, "it should concern [all instructional designers] because the vast majority of the people on [the IEEE] list of contributors know only slightly more about learning theory and instructional design than [the instructional designer] knows about pointers in C++ and the structure of IP datagrams" (p. 68).
The field of instructional designers should not stand by and allow "the world's perception of the relationship between learning and technology [be formed] by large groups like IEEE/LTSC, IMS, and ADL/SCORM, who are creating specifications and setting international standards to which vendors of the online learning products your university requires you to use are already adhering" (Wiley, 2002, p. 67).
What can we, as instructional designers, do? The field of software development is by no means a fully-mature field, but those in that field are fully cognizant of the issues involved in software development, software usability, systems architecting, and social behaviorism as it applies to designing and developing software (Winograd, 1996; Weinberg, 1971; Norman, & Draper 1986). The field of computer science and software development's full time focus is on improving these models and processes and researching what works and what doesn't. Instructional designers should be taking full advantage of this research while focusing their attention on pushing the boundaries of their own domains. "The academic literature is already strewn with hundreds of development methods" (Lang, 2003, p. 253), why add more noise? Wynekoop and Russo (as cited in Lang, 2003) warned that "by failing to evaluate current methodologies, practices and needs, researchers may develop methodologies that are not only irrelevant, but flawed" (p. 253). If we do want to continue to research development and design methodologies for systematic approaches, then we should at the very least team up with the foremost experts in the software development field to jointly research and publish our results.
The field of instructional technology, at least in the area of computerized instruction, should be all about connecting learning theory to better software designs that lead to highly effective learning modules. "Unfortunately, hardware technology has too often been harnessed merely to accommodate to the traditional conceptions of learning. It has been easy, but not very challenging way to use the potential of new technology to improve the quality of learning" (H?kinen, 2002, p. 464). We need to focus on articulating and improving upon what we do and know best; that of designing instruction through the application of learning theories and instructional design concepts.
Last, but not least, instructional designers should also ramp up participation in the large groups that have a potential to deeply affect the instructional technology field, such as the IEEE, who are actively treading on our turf through, for example, their attempts to develop a notation system for instructional systems. Waters and Gibbons (2004) assert that "if designers become more aware of the function of notation systems and design languages, we will be better equipped to deal with public instructional designs in a common work space. This will allow better communication among design team members, and use the greater skills and energies of the team to create more interesting, varied, and powerful designs."
After all, if building architects can specialize into various areas (commercial, residential, medical, steel, concrete, lumber, etc.), then why can't instructional designers be a highly specialized area of software architects? The time for making some fundamental changes in our mental models of ourselves as instructional designers is long overdue.
Barbacci, M. R. (1998, September). Are software architects like building architects? The Architect. Retrieved October 25, 2004, from http://www.sei.cmu.edu/news-at-sei/columns/the_architect/1998/September/architect-sep98.htm
Bass, L., Clements, P., & Kazman, R. (1998). Software architecture in practice. Reading, MA: Addison Wesley.
Bengtsson, P., & Bosch, J. (1999). Haemo dialysis software architecture design experiences. Proceedings of the 21st International Conference on Software Engineering, 516-525.
Bredemeyer, D., & Malan R. (2000, June). The role of the architect. Retrieved October 25, 2004, from http://www.serc.nl/lac/LAC-2001/3-skills/papers/Architects%20versus%20Architectural%20Engineers.pdf
Cheng-Chang, P., Deets, J., Phillips, W., & Cornell, R. (2003). Pulling tiger's teeth without getting bitten: Instructional designers and faculty. The Quarterly Review of Distance Education, 4(3), 289-302.
Cox, S. & Osguthorpe, R. T. (2003). How do instructional design professionals spend their time? TechTrends, 47(3), 45-47, 29.
Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large systems. Computing Practices, 31(11), 1268-1287.
Davidson, J. (2003). A new role in facilitating school reform: The case of the educational technologist. Teachers College Record, 105(5), 729-752.
Denning, P., & Dargan, P. (1996). Action-centered design. In T. Winograd (Ed.), Bringing design to software (pp. 105-119). New York, NY: ACM Press.
Dikel, D. M., Kane, D., & Wilson, J. R. (2001). Software architecture: Organizational principles and patterns. Upper Saddle River, NJ: Prentice Hall.
Gustafson, K. L., & Branch, R. M. (2002). Survey of instructional development models, 4th ed. ERIC Clearinghouse on Information & Technology.
Häkkinen, P. (2002). Challenges for design of computer-based learning environments. British Journal of Educational Technology, 33(4), 461-469.
Hohmann, L. (2003). Beyond software architecture: Creating and sustaining winning solutions. Reading, MA: Addison Wesley.
Hooper, K. (1986). Architectural design: An analogy. In D. A. Norman & S. W. Draper (Eds.), User centered system design: New perspectives on human-computer interaction (pp. 9-23). Hillsdale, NJ: Lawrence Erlbaum Associates.
Kapor, M. (1996). A software design manifesto. In T. Winograd (Ed.), Bringing design to software (pp. 1-9). New York, NY: ACM Press.
Kuhn, S. (1998). The software design studio: An exploration. IEEE Software, 15(2), 65-71.
Lang, M. (2003). Hypermedia systems development: A comparative study of software engineers and graphic designers. Communications of the Association for Information Systems, 12, 242-257.
Liu, M., Gibby, S., Quiros, O., & Demps, E. (2002). Challenges of being an instructional designer for new media development: A view from the practitioners. Journal of Educational Multimedia and Hypermedia, 11(3), 195-219.
Lohr, L., Javeri, M., Mahoney, C., Gall, J., Li, K., & Strongin D. (2003). Using rapid application development to improve the usability of a preservice teacher technology course. Educational Technology Research and Development, 51(2), 41-55.
Losavio, F. (2002). Quality models to design software architecture. Journal of Object Technology, 1(4), 165-178.
Malan, R, Bredemeyer, D. (2002). Less is more with minimalist architecture. IT Professional, 46-48.
Merriam-Webster Online. (n.d.). Definition of architect and designer. Retrieved November 27, 2004, from http://www.webster.com
Muller, G. (2004, April). The role and task of the system architect. Retrieved October 25, 2004, from http://www.extra.research.philips.com/natlab/sysarch/RoleSystemArchitectPaper.pdf
Norman, D.A., & Draper, S. W. (1986). User centered system design: New perspectives on human-computer interaction. Hillsdale, NJ: Lawrence Erlbaum Associates.
Pettenati, M. C., Giuli, D., & Khaled, O. A. (2001). Information technology and staff development: Issues and problems related to new skills and competence acquisition. Journal of Technology and Teacher Education, 9(2), 153-169.
Schekkerman, I. J. (2001, July). The architect & the architectural engineer, two different roles. Retrieved October 25, 2004, from http://www.bredemeyer.com/pdf_files/role.pdf
Sommerville, I. (1989). Software Engineering, 3rd ed. Reading, MA: Addison Wesley.
Visscher-Voerman, I., & Gustafson K. L. (2004). Paradigms in the theory and practice of education and training design. Educational Technology Research and Development, 52(2), 69-89.
Waters, S. H., & Gibbons, A. S. (2004). Design languages, notation systems, and instructional technology: A case study. Educational Technology Research and Development, 52(2), 57-68.
Weinberg, G. (1971). The psychology of computer programming. New York, NY: Van Nostrand Reinhold Company.
Wiley, D. (2002). O, instructional technologist, where art thou? TechTrends, 46(4), 66-67.
Wiley, D. (2003). A modest manifesto v0.6. TechTrends, 47(2), 72, 71, 32.
Winograd, T. (1996). Bringing design to software. Reading, MA: Addison Wesley.
World Wide Institute of Software Architects (WWISA). (n.d.). Philosophy. Retrieved October 24, 2004, from http://www.wwisa.org/wwisamain/phil.htm
World Wide Institute of Software Architects (WWISA). (n.d.). Role of the software architect. Retrieved October 24, 2004, from http://www.wwisa.org/wwisamain/role.htm
World Wide Institute of Software Architects (WWISA). (n.d.). Client Information. Retrieved October 24, 2004, from http://www.wwisa.org/wwisamain/client.htm