When we look at disseminating enterprise architecture information, we need to consider what information we need to disseminate, to whom we need to disseminate it, when we need to disseminate it, and how we are going to disseminate it. All of this is driven by why we need to disseminate this EA information.

Preparing for Dissemination

We can disseminate three states of EA architecture representations: draft views, stable views, and accepted releases. Like software, EA data needs to be version controlled in the draft phase, placed under configuration management when it becomes verified and stable, and released as an integrated set of views after the whole has been accepted as correct, complete, and consistent via a formal process.

Though informal processes guide configuration management of architecture representations in very small enterprises, large and complex enterprises require formal configuration management processes. Formal processes are needed because communicating an architecture change has a cascading impact on so many other elements of the enterprise and affects so many stakeholders of the enterprise that inadvertent mistakes or oversights can be very disruptive. Notification of an architecture change involves understanding the implications of the change and requires a plan that incrementally implements the change and provides stakeholders the dates and schedules for events that will impact them.

Formal configuration management implies the need for a configuration control board (CCB), which is usually the EA executive steering committee (EAESC) or equivalent, with the CIO or other appropriate high-level executive as the change authority (the person with signature authority to place submitted draft material under configuration management, approve change requests, and approve an architecture for release, usually with the recommendation of the rest of the CCB). The CCB is supported by a business review board or committee (BRB/BRC) and a technical review board or committee (TRB/TRC). The BRC consists of business or operations managers. The BRC reviews EA artifacts or change requests that impact operations and provides recommendations to the CCB. The TRC consists of IT managers. The TRC reviews EA artifacts or change requests that impact the technical infrastructure of the enterprise and provides recommendations to the CCB. Both of these supporting groups may need security specialists as consultants. All three of the boards should have formal charters and formal processes for their activities.

Key features of configuration management process include the following:

• A controlled baseline must be maintained for the released version and read-only access provided to all users to prevent corruption of the EA. In other words, the configuration management repository or tool will contain the authoritative version of the controlled material and changes can be made only via formal change request processes. Formal configuration identification must be maintained to identify the specific release of the EA that will be disseminated. A controlled baseline is a formally identified release of enterprise architecture with a date and an identifier.

• A formal process must be identified for validation of the EA information before considering a release. The accuracy and validity of the disseminated EA release is essential for continued credibility and trust in the reliability of the EA information. If the latency of validation is a hindrance to the use of EA information, markings must be made that indicate the reliability status of the information as well as an indication of when a validated product will be available.

• The formal approval process for an EA release must have a designated signature authority. This signature authority is usually the chair of the CCB/EAESC.

• Access controls must be in place for the CM repository. There must be a formal process for authorizing access to the various classes of EA information in the repository, such as stable drafts, full releases, and parts of releases. Access will usually be based on roles. Although it is possible that an EA may not have any confidential information, the aggregation of the information may present a security risk. In the wrong hands, the compilation of enterprise information in the EA could create a vulnerability to the enterprise by providing sufficient information for infiltration and disruption. Some of the information (or an aggregation of that information) may need to be controlled and accessed on a “need-to-know” basis (such as network models, critical performance factors, system interfaces, and so on). The access controls must enable the incorporation of EA information into people’s everyday duties. For example, executive and managerial staff should be able to incorporate EA information into communications, briefings, and directives. Application architects should be able to use the information to analyze artifacts against their own reality and identify opportunities for improvements. Enterprise architects should be able to use the information to apply what-if analysis against the baseline and use the baseline information as a basis for the next release.

Marketing and Communications Plan

One of the key steps in preparing for disseminating the EA is the development of an EA marketing strategy and communications plan during the planning phase of the EA program. The purpose of the plan is to keep senior executives and business units continually informed, to disseminate EA information to management teams, and to secure continued support from subject matter experts and analysts and to get them to act as a target audience.

The CIO’s staff, in cooperation with the chief architect and support staff, defines a marketing and communications plan consisting of constituencies, level of detail, means of communication, participant feedback, schedule for marketing efforts, and method of evaluating progress and buy-in.

One of the recommended means for marketing the EA is a primer to inform business executives and stakeholders of the EA strategy and plan. The primer can be used to express the enterprise’s senior management’s vision and the role of EA in accomplishing that vision.

An EA marketing and communications plan may divide the dissemination strategy into multiple phases. Each of these phases needs different types of dissemination. Table 7-1 shows an example.

Table 7-1   Sample EA Marketing and Communications Plan

Identifying the Audience for Architecture Dissemination

Table 7-1 shows the purpose of disseminating information, when some information might be disseminated and how the information could be disseminated. But it is also important that you know the roles of the stakeholders to whom information should be disseminated and what information should be disseminated to these roles. The common type of stakeholders and their information needs are discussed in the following sections.

Architecture Sponsors

The architecture sponsors are senior management people who have understood the need for architecture, have underwritten the cost of development, and are interested in solving the set of problems that drove that initial need. Unfortunately, in many enterprises, the unspoken need to undertake the development of EA is to comply with regulatory mandate or the demands of a higher power—an oversight office such as the Office of Management and Budget in the federal government. Sponsors generally include the chief information officer, executive management, and executive teams charged with effecting enterprise transformation. These stakeholders need to see the Enterprise Level architecture information and any management status reports on progress.

Architecture Team Members

Members of the architecture team, as facilitators of transformation, are the “evangelists” and proponents of the architecture they are building. Dissemination of the EA in the development or draft stages also enables team members to share information using collaborative techniques through the project social network. The architecture team includes the chief architect, modelers, business analysts, technical specialists, and others, as described in Chapter 6. The extended architecture team includes SMEs who provided the data for the architecture development. The SMEs will need to see draft views to correct and validate them. However, each SME will need to see only the small set of views for which they are providing input.

Architecture Stakeholders

Other stakeholders are business, systems, IT infrastructure, and operations staff who are affected by the analysis, findings, and recommendations that are generated by the architecture effort. Sometimes members of this audience may be hostile to the EA effort because of threats to current ways of doing business. Members of each stakeholder tribe need to see the portions of the architecture that will directly impact them. To ensure project buy-in, you may need to show these stakeholders early drafts as well as the views as they are being entered into the configuration management repository.

Executive Management

The EA represents the anatomy and physiology of the enterprise. Executive management has a stake in understanding the implications that analysts arrive at by analyzing the EA. Management is responsible for being at the helm of transformations and therefore makes up a very interested audience—especially if the enterprise is looking at transformation as a survival technique. These stakeholders are interested in the high-level transformation or sequencing plans and the Enterprise Level architecture information.

Business Partners, Suppliers, Customers, Agents

The EA exposes the operational, systems, services, and data “plumbing” of the enterprise. This is of interest to business partners who need to interface with the enterprise at each of these plumbing levels. Operational interfaces involve handshakes between business processes. Interfaces between systems and services involve orchestration of services among enterprises as well as contracts that preserve the interface structure durably. Data interfaces between partner enterprises have to rely on semantic data standards as well as messaging and format standards. The architecture is an explicit representation of these factors and is therefore very useful for planning interfaces at all levels. However, external partners need access only to the elements of the architecture that directly impact their interfaces with the enterprise. Sometimes they will require more detailed information if they need to certify that the enterprise has sufficient security controls in place to provide a safe and secure interface.

Reusers

Dissemination of architecture models in a manner that can be used by the receiver for facilitating their own tasks is essential to the adoption of the EA as a valuable enterprise asset. For example, planners of a new initiative may want to describe the context of their planned initiative in terms of locations served, organizations involved, key business processes to be automated, key capabilities to be acquired, and key systems to interface with for data supply. All of this information may be available inside the architecture. By downloading and tailoring the data that comes from the EA, the team planning the initiative can produce an early concept of operations that has taken a small effort but is rooted in enterprise reality. In some cases, such as in the DoD or federal government, the sharing of EA information will be done through a central repository available, with appropriate access controls, to a larger enterprise.

Communities of Interest/Communities of Practice

In recent years, with awakening interest in collaborative workspaces, wikis, and social networking has demonstrated the importance of forming communities of interest and communities of practice—people with shared motivation, working collaboratively on interleaved tasks with similar interests and skills. COIs and COPs are natural targets for architecture dissemination. Architecture content can be dramatically improved by employing facilitated wikis and managed social networking interfaces, in which members of the COI/COP who are familiar with the subject matter can provide corrections and improvements. However, these COI/COP represent emergent enterprise tribes who need to be handled carefully in order to get and preserve their buy-in.

Architecture Presentation Techniques

Dissemination of architecture information to human beings is complex as it involves cultural, semantic, and clarity issues among others. Questions about presentation include the following:

• How is the information presented? Is it easily comprehensible by the target audience based on past experience and knowledge and familiarity?

• Does the information presentation conform to applicable standards?

• How dense is the information representation? Is the display making good use of whitespace?

• Is the information disseminated in a useable format? Can the information be readily used to build value-added presentations and perform analysis without the user having to retype or manipulate the disseminated data?

• What kinds of information patterns provide the most leverage? Sometimes, certain layouts of data tend to naturally represent a model. For example, comparisons of numeric data can use commonly understood pie and bar chart graphics. Taxonomical representations lend themselves to a hierarchical or tree diagramming patterns.

Although information is the lifeblood of enterprise architecture, it can be overwhelming to decision-makers when presented in a raw format. Many of the architecture views and models standardized by frameworks can be shared among trained architects and are useful for analysis. However, architects must be able to communicate architectural information in a meaningful way to process owners and other stakeholders who are not trained architects. The results of architectural-related data collection need to be presentable to nontechnical senior executives and managers at all levels. Many managers are skilled decision-makers but have not had technical training in architectural description development. Presentation views are always dependent on the quality of the architectural information that is collected through the rigor of architecture methods. As Figure 7-1 illustrates, presentation techniques pull from the architectural information store and display the data in a variety of meaningful ways to stakeholders.

Figure 7-1   Architecture data collection versus presentation (graphic from the DoDAF)

Presenting architecture data to managers often means complex technical information has to be translated into a form for presentation that is useful to management. An “information bridge,” built by the various presentation techniques such as those shown in Figure 7-1, is the link between the architect and management. The bridge provides the means to recast technical information in graphical or textual terms that are consistent with the culture of the management organization (see Figure 7-2).

Figure 7-2   Dissemination as an information bridge (graphic from the DoDAF)

Choosing an Appropriate Presentation Technique

In any business, decisions must be made at multiple levels of the organization. Whether some one is a senior level executive, a process owner, or a system developer, he or she will need to make judgment calls based upon the available data. Each level of decision-making, in turn, has both a unique purpose and understanding of architectural description, making it important to tailor the data to maximize its effectiveness. The presenter, with the help of an experienced architect, must determine the audience of a presentation before choosing the type of presentation technique to use. Figure 7-3, based on the rows of the Zachman Framework, summarizes the multiple levels of decision-makers within a typical organization that make up an audience.

Figure 7-3   Zachman Framework perspectives of an enterprise (graphic from the DoDAF)

Each level has differing requirements for presentation of data. Level 1 planners may find a graphical wall chart more useful in making decisions, whereas a level 4 builder will most likely require a more technical presentation that relates more directly to the architectural description. Level 5 subcontractors are the workers who will perform the work required and generally need varying levels of technical data and other information to accomplish their task.

To narrow down the type of presentation required, ask the following question: What information does the decision-maker need to make a data-supported decision? For each decision level, there is a data set that can be manipulated using a presentation technique. After analyzing the audience and type of information, the presenter should consider the various types of techniques discussed in this section.

Figure 7-4 provides a simplified representation of the presentation development process.

Figure 7-4   Presentation/dissemination development cycle (graphic from the DoDAF)

It is imperative to realize that when you choose how to present data sets, there is no limit on what views to use. There are countless ways to display information to decision-makers, and it is up to the presentation developer to determine the most effective way to accomplish this task.

Fit-for-Purpose View Display Formats

This section describes a basic set of view development techniques to start from. Each technique was created to serve a unique purpose. Details are provided on five different presentation techniques that have proven to be useful in engaging various audiences.

Remember that some stakeholders may not necessarily want to see information in the way that the architect represents it in architecture views. Dissemination often involves building composite views that may be different from the original supplying views.

If there is one thing this book has stressed, it is the importance of building integrated architectures where all the views consistently share the same common architecture elements. Building an integrated architecture unifies the data consistently and enables the building of new composite views from the same data without compromising accuracy and faithfulness of semantics and structure of the originally modeled elements. These composite displays, or Fit-for-Purpose views, are built to suit the viewpoint of the audience rather than to conform to some view technique the audience does not understand.

Fit-for-Purpose views can be created using the architecture data from an integrated architecture to provide forms of graphical presentation other than those used to build the architecture models such as activity model, logical and physical data models, and business process models. Fit-for-Purpose views use presentation techniques that are more common to briefings and decision analysis.

The following five techniques commonly used:

• Composite views   Display multiple pieces of architectural data in formats that are relevant to a specific decision-maker

• Dashboards   Integrate abstracted architectural information for a given business context

• Fusion views   Display multiple pieces of architectural data and incorporate disparate pieces of information that are not captured within the architectural description

• Graphics   Visually represent manipulated data

• Reference models   Capture the elements of the architectural data and translate those elements into text

Fit-for-Purpose views provide wide flexibility for the architect and process owner to create architectural views easily understood and useful to management for decision-making purposes.

Standardized View Display Formats

Part III of this book discusses the details of the standardized DoDAF views that are recognized and understood by a large community of architects. These views have been used for more than a decade and stand upon tried, proven, and heavily adopted modeling techniques and methodologies such as structured analysis and design, ICAM Definition for Functional Modeling (IDEF), state transition descriptions, and business process modeling notation (BPMN). The representation of views for each of these methodologies is generally standardized by the methodology. For example, IDEF0 uses the activity node tree, context diagram, and decomposition diagrams to represent activity models in a graphical way based on a recognized standard.

Standard model layouts generally fall into the categories shown in Table 7-2.

Table 7-2   Standard Model Layouts

Although the DoDAF provides a set of standardized views, views from other frameworks such as TOGAF (Chapter 22) and FEAF2 (Chapter 23) can also be used either for architects or for presentation to other stakeholders.

Audience Presentation Tips

Presenting multiple architecture views to mixed audiences of multiple specialties, interests, and concerns is challenging and often nonproductive in getting agreement, eliciting deeper questions, and securing agreements on follow-up actions. Dividing up the groups based on specialties and getting partial agreements sometimes becomes useful toward making progress in the architecture development process.

Here are some points to remember when presenting architecture representations to different audiences:

• People usually care about only the things that concern them and in which they have an interest or stake. Presenting a number of views that are not relevant to your audience is pointless. Select the right views to present to an audience in order to elicit feedback, comments, agreement, and assistance in formulating next steps toward implementation.

• People understand at the rate of comprehension they are accustomed to. Presenting diagrams with several cryptic symbols and connections does not engage everyone. Walkthroughs and progressive buildups are required to carry audiences across the comprehension bridge. An ill-understood model is effort wasted.

• A diagram must be self explanatory to the maximum extent possible. Legends cue audiences to the meaning of content. Titles describe the subject of the diagram as well as the architecture view that it represents. Strive for uniformity of colors, styles, and themes to accustom the eyes of the audience to the content rather than the container.

• The goal of an architecture presentation is to describe the results of discovery and analysis and to recommend courses of action. The presenter must be able to describe these elements of the presentation succinctly, and to provoke debate and discussion and potentially agreement on the way forward using the specific selection chosen from a number of alternatives.

• Though hierarchy is a way to break down complex representations into a number of simpler ones, hierarchical presentations may also serve to disconnect the audience from the big picture. As a result, they may become involved in discussion detours when the architecture must be assessed as a whole. Often we present a single-page complex diagram at the risk of comprehension to provide a bigger picture than would be provided by a series of hierarchical diagrams.

• Architecture terms usually represent the language of the architect. Architecture languages are standardized by frameworks such as the DoDAF. However, when presenting architecture representations that depict views of the business model, the architect must use the language of the business; when presenting views of the operating model, the architect must use the language of the operations staff; and when presenting views of technology, the architect must use the language of the technology and infrastructure support personnel.

Delivery of Dissemination

In this section, we discuss the various ways in which architecture information can be disseminated.

Web Delivery

By far, the most convenient and popular delivery of repository content is through the Internet, with a web server at one end and a simple web browser application at the other. Web-site publishing is supported by many architecture tools in the marketplace. They generate a collection of hypertext markup language (HTML) files that are linked through cross-file references. A home or index page is provided, generally with a navigation structure that has links to the various views that make up the integrated architecture. Navigation is accomplished via elements of one view to elements of other views. Web output is also combined with interpretive text that describes architecture elements.

The generation of HTML web pages with embedded graphics and text representing the views that are disseminated results in snapshots of the architecture. If the contents of the architecture repository were to be updated, they would not automatically be reflected in the web site until a new web site is generated and published. For architectures that are released relatively infrequently, this is still a good solution.

More sophisticated web delivery systems use scripts to generate the web pages automatically on the fly from active repository content. Any changes to repository data are instantly reflected in the web pages. These systems tend to be repository side applications rather than features of the architecting tool, because the scripts need knowledge of the repository schema.

Architecture Web Site/Web Portal

The static web generation of architecture views for an integrated architecture, as discussed earlier, is easily accomplished by commercial architecture tools. But architecture dissemination often requires more than just the dissemination of views. In an architecture community of practice, other items such as reference models, policy and guidance, templates, and other information need to be disseminated. An architecture web site or an architecture portal is often built to service a community of architecture team members as a minimum and for an extended community of stakeholders when mature.

Architecture web sites must follow all the rules of good web site design:

• Clear “floor plan”

• Consistent layout of topics and navigation paths

• Appropriate use of fonts, colors, and emphasis

• Design unity with complementary web sites

• Consistent look and feel

• Comprehensive search capabilities

• Facilities for zooming and panning large graphical images

• Appropriate density of information

Architecture web sites and portals can also be built with capabilities for wikis and social networking and provide a collaboration workspace for some tasks such as these:

• Refining vocabulary and terminology

• Refining taxonomies/classification schemes

• Critiquing and improving architecture views

• Suggesting improvements to the architecture program

• Validating views

Discovery Services

In contemporary computing, discovery services are an important part of net-centric operations. In net-centric operations, information and software services are dispersed over a network. A using or invoking application uses “discovery services” to find appropriate data and services that it can use to accomplish its purpose. Discovery services require that the owner of the information or service “advertise” these services in a transparent manner to the discovery services. The advertising of data and services is done in much the same way as libraries once advertised their holding using index cards. The index cards that “exposed” information and services were formatted in a consistent manner per some predefined metadata standards. One such standard is the DoD’s Defense Discovery Metadata Specification (DDMS).

Architecture repositories can expose their information and services to the world outside (or at least the entitled and authorized world outside) using metadata specifications. The burden of searching, discovering, and materializing the data or invoking the service is the responsibility of consuming applications.

Repository Services

Repository web services are a way to provide dissemination for external applications or web users. Repository web services must be published and registered on a service broker such as a Universal Description, Discovery, and Integration (UDDI) registry. Repository services can run unattended and provide 24/7 services.

Operating repository services imposes a supplier’s burden on the architecture repository and the architecture team. This burden is expressed as a commitment to a service level agreement to make repository services available as advertised.

Offering repository services is generally undertaken after an architecture effort has reached a maturity stage that warrants continuous availability of dissemination as a web service. Chapter 8 introduces the concepts of governance and describes the stages of maturity of architecture management.

Dissemination to Computerized Systems

An architecture description can be viewed as an integrated collection of blueprints stored as electronic documents or as information in an architecture repository. This information may be disseminated through two types of computerized systems:

• Dissemination of EA data between automated computer systems applications, such as architecture modeling tools (see Chapter 6 for examples)

• Dissemination of EA data and views to a receiving enterprise repository or registry

We distinguish between these two types of dissemination because each of them has different needs for semantic and structural data standards for the exchange to be successful.

Dissemination Between Automated Computer Systems Applications

This form of dissemination requires agreed upon protocols for information semantics as well as information formats. In addition to these, it also may require automated services at either end, one to push information and the other to pull the information in.

The most common form of dissemination between automated computer systems is the dissemination of architecture data from one modeling tool/repository to another. These exchanges are supported by bilateral agreements between pairs of senders and receivers, by custom software, or by a common exchange standard that is used by all tools.

The DoDAF and related defense frameworks are moving toward the Unified Architecture Framework/Profile (UAF/P) to support exchanges between UML- and SysML-based architecture development tools. Once both UML tools have been customized to the UAF profile, architecture data can be exchanged using XML.

An example of an older format for exchange of information between automated tools is the Common Data Interchange Format (CDIF). Another one for exchange of IDEF0 Activity Models is the IDL or IDEF0 Description Language.

Dissemination to Another Receiving Enterprise Repository or Registry

This form of dissemination requires agreed-upon protocols for information semantics as well as information formats. Consider the following examples.

The Federal Enterprise Architecture (FEA) reference models are disseminated by the OMB through the use of XML. The tags for the FEA reference models are standardized and the semantics published so that an organization receiving the information can decode the contents. The use of this dissemination is to enable agencies to comply with the federal mandate for mapping their agency EAs as well as their planned investments and initiatives to the FEA reference models.

The DoDAF recommends that enterprises implementing their architectures register the Overview and Summary information (AV-1) model with the Defense Architecture Registry System (DARS). The DARS specifies a XML format for submissions of architecture summaries. These are kept in DARS and available as a ready resource for interested stakeholders and modelers.

Export/Import Files

Traditional forms of dissemination of architecture data has relied on import/export capabilities within architecture tools and architecture repositories. These capabilities produce electronic files of architecture data. The files can be formatted in many ways. Here are a few examples:

• Tab, comma separated, or some form of delimited data file   These are the most popular because the format is both general and transparent and enables ready use of the disseminated information.

• Extensible Markup Language (XML) files   These are popular because the data is self-identifying. XML tags inside the file specify the nature of the data that is enclosed between tags. The format also enables parsing as well as schema constraint enforcement—important when tools and repositories also allow imports using the same file format.

• Standardized architecture data exchange specification   These standards are established by standards bodies such as Object Management Group, Organization for the Advancement of Structured Information Standards (OASIS), or large volume buyers of tools and repositories with an interest in establishing data exchange standards such as the DoD or financial services firms.

• Binary files   These are proprietary format files that can be understood only by the applications for which they are created. They cannot be used in any other context.

• Microsoft Office   MS Office has become a de facto standard for word processing, spreadsheet, and presentation software in many organizations. Disseminating architecture data in these formats will provide analysts with easy-to-understand, ready-to-use architecture data for their own value-added tasks. Disseminating images using PowerPoint enables audiences to build briefings from readily available, previously constructed models.

• Acrobat PDF   Dissemination of architecture data that must not be altered is accomplished by generating Adobe Acrobat PDF files.

Summary

Architecture representations are primarily built for promoting common understanding of the enterprise and its various facets. Dissemination of architecture representations is key to sharing that understanding with a broader audience than simply the architecting team. In this chapter, we discuss the aspects to be considered about the dissemination of the EA to an audience that can use it as a knowledge base to support creative efforts, perform detailed analysis, plan actions, make decisions, communicate, solve problems and establish governance, to name a few uses. The process for dissemination starts with identifying the audience for the EA. We discuss various common techniques for presenting the architecture in a format that the appropriate audience is used to. We discuss methods by which architecture representations and narratives are delivered to the intended audience as well as methods to exchange architectural data with other repositories and automated systems that can consume that information for various purposes.

Questions

1. What are the steps you would take to market the adoption of EA in your enterprise? Who are the key decision-makers? Influencers? Stakeholders? Potential SMEs?

2. What are some of the steps you would use to raise the awareness of EA in your organization?

3. What are the different methods for disseminating the architecture views and information about the architecture development project? Discuss the pros and cons of each method. What method is most applicable to your own organization and why?

4. Build a simple EA marketing and communications plan for your own enterprise. Assume that your enterprise is at a preinception stage in the diagram presented earlier in this chapter. What are the risks inherent to the plan? How do you plan to address, mitigate, or eliminate these risks?

5. Identify the stakeholders for enterprise architecture in your enterprise. Describe their roles briefly and their interest in the architecture. Describe the various architecture viewpoints that are useful for each type of stakeholder; use any of the frameworks discussed in this book to define these viewpoints.

6. What is a Fit-for-Purpose view? Describe some examples of customized views or displays you could use from an IDEF0 activity model that shows the flow of resources between activities as well as a description of the performers of the activity. Hint: Think of RACI matrices.

7. Starting with any subset of the DODAF views described in this book, what kinds of Fit-for-Purpose views would be useful to your organization? How would you construct them from the standard views built during the course of the architecture project?

8. What are the issues in managing the configuration of released architectures? How will you address configuration management of your own architectures? What is your strategy for approaching change control? How will you control changes and keep track of the changes for historical purposes?

9. What are the ways in which you plan to communicate the views you have built using architecture tools? How will you ensure that the intended audience does not need the specialized architecture development tools that you have used to build the views?

10. Discuss the issues that arise when architecture work has to be exported from one repository to another? What are the issues related to methodology mismatch? To metamodel mismatch between the sending and receiving repository systems? What are issues related to non-standard uses of architecture terminology? How do you plan to address your own enterprise’s submissions of architecture data and pictures to another collaborating enterprise? To a reporting enterprise?

11. Discuss the applicability of the presentation/dissemination development cycle presented in this chapter to your own enterprise. How would you streamline and standardize this process for your enterprise?

12. Provide some examples of the types of Fit-for-Purpose views discussed in this chapter. Which type of view is useful for which type of audiences?

13. What are some examples of formats for standardized views? What is the usefulness of having standardized views? Discuss the correspondence between standardized views and standard types of models that are prescribed by methodologies such as the Rational Unified Process, Integration Definition for Information Modeling (IDEF1X), or business process modeling notation (BPMN). What are the pros and cons of using standard models prescribed by methodologies versus defining models that are tailored for a specific audience?

14. What are the different methods of disseminating architecture data? How would you plan a distributed dissemination scheme for multiple departments in your enterprise when they do not have access to the same repository?

15. What are some of the pros and cons of providing architecture discovery services so that people interested in your architectures can search, discover, and help themselves? What are some of the security issues? Authorization issues? Entitlement issues? What types of policies would you recommend for such a service-based dissemination strategy?

References

Barnlund, D.C. 1968. Interpersonal Communication: Survey and Studies. Boston: Houghton Mifflin.

Chapanis, A. 1961. “Men, Machines, and Models.” American Psychologist, 16(3)113–31.

CIO Council. 2001. “A Practical Guide to Federal Enterprise Architecture, Version 1.0.” www.gao.gov/assets/590/588407.pdf.

Department of Defense. 2009. Department of Defense Architecture Framework Version 2.0. http://dodcio.defense.gov/Library/DoD-Architecture-Framework.

Deutsch, K. 1952. “On Communication Models in the Social Sciences.” Public Opinion Quarterly, 16: 356–80.

Education, Audiovisual & Culture Executive Agency, University of Macedonia. 2009. “EA Training 2.0: Innovative Enterprise Architecture Education and Training Based on Web2.0 Technologies.” http://eacea.ec.europa.eu/LLP/projects/public_parts/documents/ict/2008/mp_143434_ict_FR_eatrain2_.pdf.

Gerbner, G. 1956. “Toward a General Model of Communication.” Audio-Visual Communication Review, vol. IV: 171–99.

Kaplan, A. 1964. The Conduct of Inquiry: Methodology for Behavioral Science. San Francisco: Chandler.

Lackman, R. 1960. “The Model in Theory Construction.” Psychological Review, 67(2): 113–29.

Sereno, K.K. and C.D. Mortensen. 1970. Foundations of Communication Theory. New York: Harper & Row.

The Open Group. 2011. “TOGAF Version 9.1.” The Netherlands: Van Haren Publishing.

Watzlawick, P., J. Beavin, and D. Jackson. 1967. Pragmatics of Human Communication. New York: Norton.