The following is a table of all the Change Requests created during the Company Review of TOGAF Version 8, together with a recommendation for how each Change Request should be disposed of (e.g., Accept, Accept as Amended, Reject).
Click on a File/Tag link to go to a Change Request as entered in the company review draft. Note that the hyperlinks in this table go only to the individual HTML file - they do not preserve the frames structure of the TOGAF document. You may find it helpful in reviewing these comments to load the full company review draft in a separate window under your favorite browser.
| Ref. | File/Tag |
Submitter |
Severity/ Nature |
Title/Rationale |
Change Request |
Agreed Recommendation |
| 1 | p1/enterprise.htm/8 | pm_smith | Minor Editorial |
Remove (Systems) Systems architecture is a broad context, not isolated to applications. The term 'systems' can be used as a general term to describe any complex development initiative, and applies equally well to the business, information, and technical architectures. |
Application Architecture; and | ACCEPT. Rationale: The FAQ text does not include "(Systems)". |
| 2 | p1/enterprise.htm/10 | c_greenslade | Minor Editorial |
Information System Architecture Elsewhere in the document
we use the term Information |
The combination of Data Architecture and Application Architecture is also refered to as the Information Systems Architecture. | ACCEPT as amended. Insert the proposed text "The combination .... Information System Architecture" where indicated in the draft. (Note: "System" is singular. The ADM graphics show "Systems", and need to be corrected.) |
| 3 | p1/enterprise.htm/15 | w_stahlecker | Minor Editorial |
Position TOGAF as agnostic Make TOGAF more acceptable,
avoid confrontation or |
replace original text by quoted text ... such an industry standard method, which 'is agnostic about tools and technologies and can be used' with any recognized enterprise framework, .... | ACCEPT as amended. Insert the new text at the point indicated, but replace "agnostic about" with "neutral towards", so that the full sentence now reads: "The Open Group's goal with TOGAF is to work towards making the TOGAF architecture development method just such an industry standard method, which is neutral towards tools and technologies and can be used for developing the products associated with any recognized enterprise framework, such as ....etc." Rationale: The point about using the TOGAF method in conjunction with the deliverables of another framework is important, and should be retained. (Not clear if the comment intended this to be omitted or not.) "Neutral" is felt to be a more acceptable term than "agnostic". |
| 4 | p1/enterprise.htm/31 | w_stahlecker | Minor Editorial |
Point out the integrative nature of TOGAF's ADM Go beyond
defensive statements of being able to cooperate by pointing out the possible role of
TOGAF's ADM as a |
...(described in Part III), to 'reflect different levels of abstraction in an architecture development process. This way TOGAF can turn misunderstanding between actors at different levels into cooperation. It provides a context for the use of multiple frameworks, models, and architecture assets in conjunction with the TOGAF ADM.' | ACCEPT as amended. Replace the sentence: "This way TOGAF can turn misunderstanding between actors at different levels into cooperation." by: "In this way TOGAF facilitates understanding and cooperation between actors at different levels." Rationale: Amended text is less controversial. |
| 5 | p1/preface.htm/1 | j_spencer | Major Editorial |
Clean up graphics Poor quality |
(on behalf of Tony Carrato, IBM:) In general, I'm pretty
happy with TOGAF 8 - looks like a good job. One thing, though, that's bothered me at least
since TOGAF 4, is the terrible quality of the graphics. They aren't even as good as if
they were done with PowerPoint or Visio. It's often suseful to include a TOGAF graphic in
a presentation - I always find I've got to redraw them, rather than copying and pasting
from TOGAF. Can we clean those up? |
ACCEPT as amended. Invite contribution of any improved TOGAF graphics that any TOGAF users have felt the need to develop. Review each invidual graphic and try to improve those felt to be in most need. Focus on improving ADM graphics, including the flowchart, and the TRM. At least make text readable and printable. |
| 6 | p1/preface.htm/1 | kirank | Major Editorial |
Overall comments (a) Navigation:
The Framework document is unintuitive and difficult to navigate. When I am on a web page
deep into the Framework it does not provide any contextual cues as to where I am relative
to the overall document. |
Overall comments:{br} (a) Navigation: The Framework document is unintuitive and difficult to navigate. When on a web page deep into the Framework it does not give any contextual cues as to where one is relative to the overall document.{br} (b) Each phase of the framework should be prefaced with a scope statement stating the purpose and relevance of the phase to the current architectural activity. |
(a) ACCEPT. Consult with Open Group web site designers to try to leverage HTML generating contextual cues. (b) REJECT. Existing phase descriptions include both an "Objectives" and an "Approach" subsection, which address this comment. |
| 7 | p1/preface.htm/1 | l_stucki | Minor Editorial |
Hyperlinks missing or inoperable Confusing navigation |
I clicked on the 'Part I: Introduction' link at the top of the very first page and it didn't seem to go anywhere. | ACCEPT as Amended. The link is operable. The Part I index is already loaded when you first load the TOGAF document into your web browser. Clicking the link simply reloads the index, hence giving the impression of nothing happening. However, the comment about confusing navigation is accepted, and dealt with under a separate comment. |
| 8 | p1/preface.htm/1 | m_dekkers | Minor Editorial |
Browser Titlebar reflects version 7 The browser titlebar should reflect v. 8 |
The Open Group Architectureal framework (TOGAF) Version 8 | ACCEPT.
|
| 9 | p1/preface.htm/14 | a_bodor | Minor Editorial |
...of the key concepts behind IT enterprise architecture and missleading |
Remove ''dashed' IT' from the title line | ACCEPT. |
| 10 | p1/preface.htm/23 | j_jiang | Minor Editorial |
Demo for version 8 | Af for version 8 | REJECT pending clarification. |
| 11 | p1/preface.htm/24 | j_spencer | Major Editorial |
Printable PDF file | (On behalf of Tony Carrato, IBM:) The ability to grab TOGAF
as a single PDF file, for printing, would be very useful. |
ACCEPT as amended. Make it clear that a PDF file is available for download. A PDF file is already available, from the TOGAF informational web site, but that fact is not made clear, either in the TOGAF document or the web site. Also clarify that the TOGAF document is optimized for hierarchical HTML use, and that the sequential format of the PDF is sub-optimal. |
| 12 | p1/preface.htm/24 | w_stahlecker | Minor Technical |
Usability of TOGAF Increase usage of TOGAF |
No additional editing request to the document per se. We have
a range of potential audiences for TOGAF with preferences ranging from on-line reading to
paper-bound. While TOGAF was an early example of web-navigable documents in The Open
Group, the mode of navigation was not evolved very much. So there seems to be a need to
improve TOGAF for on-liners and paper-feeders. I suggest this as a work item for 2003. |
ACCEPT. Make best efforts to improve the PDF for Version 8. Consider ways of achieving a quantum improvement in the PDF as a work item for 2003. |
| 13 | p1/preface.htm/24 | xia_li | Minor Editorial |
Download | No Change | REJECT pending clarification. |
| 14 | p1/togaf_faq.htm/3 | pm_smith | Minor Editorial |
Add 'Enterprise' The title should resemble the subject it refers to. |
What is an enterprise? . . .an architecture? . . .an
architecture description? . . . an architecural framework? |
ACCEPT. |
| 15 | p1/togaf_faq.htm/16 | hd_trestini | Minor Editorial |
Make this the first paragraph for this section I believe that for non-technical readers, this paragraph builds the concept very well. The prior paragraph will read better following this one. |
Make this the first paragraph for this section | ACCEPT. |
| 16 | p1/togaf_faq.htm/31 | w_stahlecker | Minor Editorial |
Link to business Reflect the inclusion of business process aspects in TOGAF's scope |
Replace by: 'The primary reason for developing an
architecture is to provide the fundamental technology and process structure for an IT
strategy, which turns IT into a responsive asset for any successful modern business strategy.' |
ACCEPT as amended. Rephrase to read:
"The primary reason for developing an enterprise architecture is to support the
business by providing the fundamental technology and process structure for an IT strategy.
This in turn makes IT a responsive asset for a successful modern business |
| 17 | p2/p2_a_vision.htm/15 | m_iacob | Major Editorial |
Move this to the Preliminary Phase I think that a request
for architecture work should be the starting point of the preliminary phase. It makes no
sense to start defining principles and a framework if there is no |
Move this paragraph to the Preliminary Phase. | REJECT. Rationale: The document describes the on-going process - i.e., the process once Architecture is established as a discipline in the enterprise. It would be confusing to have the Request for Architecture Work as part of the Preliminary Phase, since that Phase is executed only once, whereas the Request has to be generated for each iteration of the main ADM cycle. |
| 18 | p2/p2_a_vision.htm/18 | m_iacob | Minor Editorial |
replace be informed by 'be informed by' is a strange formulation |
Put 'constraints will normally comply with the business
principles...' instead of 'constraints will normally be informed by the business
principles...'. |
REJECT. Rationale: The text is trying to say more than just "comply with". The latter implies conformance with the letter of what is written. What is intended here is embracing the spirit of what the principles are trying to achieve. "Informed by" is felt to be common usage. |
| 19 | p2/p2_a_vision.htm/19 | m_iacob | Minor Editorial |
Rephrase no need for the use of future |
Replace 'The business principles, business goals, and
strategic drivers of the organization will normally already be defined elsewhere in the
enterprise.' with: Normally, the business principles, business goals, and strategic
drivers of the organization are already defined elsewhere in the enterprise. |
ACCEPT. |
| 20 | p2/p2_a_vision.htm/20 | m_iacob | Minor Editorial |
replace inform and involved; strange use of the words |
(a) Replace inform with determine or equivalent. (b) Replace involved with concerned, and involves with entails. |
REJECT (a), as above. ACCEPT (b). |
| 21 | p2/p2_a_vision.htm/23 | m_iacob | Minor Editorial |
undertaken instead of undetaken wrong spelling |
undertaken instead of undetaken | ACCEPT. |
| 22 | p2/p2_a_vision.htm/24 | m_iacob | Minor Editorial |
loose will no need for the use of future |
goals have been documented... | ACCEPT.
|
| 23 | p2/p2_a_vision.htm/25 | m_iacob | Minor Editorial |
replace buy-in what is the meaning of buy-in? |
use insight instead of buy-in | REJECT. Rationale: Buy-in implies commitment. |
| 24 | p2/p2_a_vision.htm/39 | m_iacob | Minor Editorial |
originator doesn't go with them grammar mistake |
replace originator with originators replace scrtach with scratch |
ACCEPT. |
| 25 | p2/p2_a_vision.htm/40 | m_iacob | Minor Editorial |
scrtach is misspelled spelling mistake |
replace scrtach with scratch | ACCEPT. |
| 26 | p2/p2_a_vision.htm/57 | m_iacob | Minor Editorial |
these instead of this grammar mistake |
replace all this with all these | ACCEPT. |
| 27 | p2/p2_a_vision.htm/58 | m_iacob | Minor Editorial |
What is SoW standing for? What is SoW standing for? |
Define SoW. | ACCEPT. Change "SoW" to "Statement of Work". |
| 28 | p2/p2_a_vision.htm/59 | w_stahlecker | Minor Editorial |
Make Scenarios methodmor visible | Begin current (59) with 'Business Scenarios: ' in bold | ACCEPT as amended. To make the Scenarios method even more visible, make "Business Scenarios" a minor heading under "Steps". Rationale: Beginning with 'Business Scenarios:' in-line in bold would clash with a lot of the surrounding text, which uses the same means of emphasis. |
| 29 | p2/p2_a_vision.htm/74 | m_iacob | Minor Technical |
Architecture Vision and Business Scenario, are they alternat It
is not clear here what is the relationship between the Architecture Vision and the
Business Scenario, and whether |
Might be an idea to put Architecture Vision and Business Scenario as separate outputs. | ACCEPT as amended. Make Business Scenario document and the Architecture Vision separate deliverables. Add the text: "Multiple scenarios may be used to generate a single vision. In TOGAF terms, the Architecture Vision may also be referred to as a 'conceptual level architecture'."
|
| 30 | p2/p2_b_busarch.htm/6 | m_iacob | Major Technical |
What about the product aspect (product can be both good or s One
of the things I miss when looking to several |
Add (and of course define) the product aspect to the list. | ACCEPT as amended. Include new text as follows: "To develop a target Business Architecture, describing the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment. These are based on the business principles, business goals, and strategic drivers." |
| 31 | p2/p2_b_busarch.htm/16 | m_iacob | Minor Editorial |
replace buy-in it is not clear what buy-in means |
use insight instead of buy-in | REJECT, as before. |
| 32 | p2/p2_b_busarch.htm/21 | m_iacob | Minor Editorial |
spelling mistake spelling mistake |
replace Descirption with Description | ACCEPT. |
| 33 | p2/p2_b_busarch.htm/23 | m_iacob | Minor Editorial |
split sentence in two. Sentence too long. |
Replace 'In such a case, the architect simply has to document
the working assumptions about high-level architectures, and the process is one of
gathering evidence to turn the working assumptions into fact, until the law of diminishing
returns sets in.' with 'In such a case, the architect simply has to document the working
assumptions about high-level architectures. The process is one of gathering evidence to
turn the working assumptions into fact, until the law of diminishing returns sets in.' It
is not at all clear what 'the law of diminishing returns' is about. |
REJECT. Original is preferred. |
| 34 | p2/p2_b_busarch.htm/24 | m_iacob | Minor Editorial |
Loose with, add s, add be With doesn't add anything here and can be skiped. Grammar mistakes for the rest. |
(a) Put 'Baseline descriptions...' instead of 'With baseline description...'. (b) Put 'to be carried' instead of 'to carried'. | a) ACCEPT as amended. Expand as follows: "Business processes that are not to be carried forward have no intrinsic value. However, when developing baseline descriptions in other architecture domains, architectural components (principles, models, standards, and current inventory) that are not to be carried forward may still have an intrinsic value, and an inventory may be needed in order to understand the residual value (if any) of those components." (b) ACCEPT. |
| 35 | p2/p2_b_busarch.htm/32 | w_stahlecker | Minor Editorial |
Incomplete wording | Complete the statement | ACCEPT. Add "and use cases" |
| 36 | p2/p2_b_busarch.htm/34 | m_iacob | Minor Editorial |
add s | 'models above' instead of 'model above' or use 'model types above' | ACCEPT as amended. Use 'model types above'.
|
| 37 | p2/p2_b_busarch.htm/85 | a_bodor | Critical Technical |
architecture, and on whether existing architectural descript it is in error |
the 'Approche' link does not point to a valid location, however it exists on the same page | ACCEPT. |
| 38 | p2/p2_b_busarch.htm/89 | m_iacob | Minor Editorial |
mistake spelling mistake |
replace 'activy models' with 'activity models' | ACCEPT. |
| 39 | p2/p2_b_busarch.htm/100 | a_bodor | Critical Technical |
architecture effort, as describe under 'Approache', it is in error |
the 'Approach' link does not point to a valid location | ACCEPT. See comment 37. |
| 40 | p2/p2_b_busarch.htm/100 | m_iacob | Minor Editorial |
supplementary clarifications needed It is not very clear to me what is the difference between for instance function and activity, and consequently between a function model and a process model. |
I would suggest you to be more specific when speaking about functions, activities, processes and models that include them, and may be to point out the significant differences between them. | REJECT. Rationale: No specific wording suggested. (Such terms could / should be defined in the Glossary. This could be a work item for 2003.) |
| 41 | p2/p2_c_info_sys.htm/13 | m_iacob | Minor Technical |
Question. What kind of design techniques can be used in the design of Data and Application Architectures? |
Indicate design techniques that can be used in the design of Data and Application Architectures. |
REJECT. Rationale: Covered (to the extent necessary) in the detailed descriptions of Data Architecture and Application Architecture. |
| 42 | p2/p2_c_info_sys.htm/18 | chris_blake | Minor Editorial |
Terminology Unclear |
Technology Architecture Design | ACCEPT. Also make all "Architecture"s cap A. Make "design"s small d. |
| 43 | p2/p2_c_info_sys.htm/20 | chris_blake | Minor Editorial |
Terminology Confusion |
Technology Architecture Implementation | ACCEPT. |
| 44 | p2/p2_d_tech.htm/14 | m_iacob | Minor Editorial |
mistake spelling mistake |
TeleManagement instead of TeleMangement | ACCEPT. |
| 45 | p2/p2_d_tech.htm/36 | m_iacob | Minor Editorial |
mistake grammar mistake |
'as described under' instead of 'as describe under' | ACCEPT. |
| 46 | p2/p2_d_tech.htm/47 | m_iacob | Minor Editorial |
omission 'and document' what? |
'and document them' instead of 'and document' | ACCEPT as amended. "identify and document candidate technology architecture building blocks (potential re-usable assets)" |
| 47 | p2/p2_d_tech.htm/49 | m_iacob | Minor Editorial |
omission Route what for review? |
'Route the Baseline Description for review' instead of 'Route for review' | ACCEPT as amended. ''Route the Technology Baseline Report for review' instead of 'Route for review'. |
| 48 | p2/p2_f_mig.htm/8 | m_iacob | Minor Editorial |
rephrase strange formulation |
Use either 'What are the implications of this project on
other activities?' or 'What are the dependencies between this project and other
activities?' |
ACCEPT as amended. Replace existing by:
|
| 49 | p2/p2_f_mig.htm/20 | m_iacob | Minor Editorial |
omission omission |
'find that a change' instead of 'find a change' | ACCEPT. Also correct: "not the least of which are those associated..." |
| 50 | p2/p2_intro.htm/5 | hd_trestini | Major Editorial |
Re-phrase the sentence Throughout the document, it is difficult to quickly identify the purpose / description of the framework elements. |
Replace sentence with: 'The TOGAF Architecture Development Method (ADM) is the result of continuous contributions from a large number of architecture practitioners. It describes a methodology for developing an enterprise architecture, and forms the core of TOGAF. It integrates elements of TOGAF as well as other available architectural assets, to meet the business and information technology needs of an organization. |
ACCEPT. |
| 51 | p2/p2_intro.htm/5 | w_stahlecker | Minor Editorial |
Proposal to add a bit of history Position the ADM as what it is: The collection of many years of expertise of many architects, and not the result of a single brilliant theory |
Append: 'The ADM is the result of continuous contributions from a large number of architecture practitioners.' | ACCEPT as amended above. |
| 52 | p2/p2_intro.htm/7 | a_bodor | Minor Editorial |
TOGAF cosists of three main parts: It is duplicated on the next line |
Remove the title line | ACCEPT. |
| 53 | p2/p2_intro.htm/8 | m_iacob | Minor Technical |
Remove TOGAF parts from here Why you repeat the parts of TOGAF here? They are already in the F.A.Q. no 8. You can eventualy refer to it. The paragraph is called Relationship to Other Parts of TOGAF not Parts of TOGAF! |
Remove this part. Instead a 'The ADM and the Resource base' would be more than welcome. | ACCEPT as amended. Three separate commenters found a problem with this subsection. Restructure the text as follows. "Relationship to Other Parts of TOGAF (retain the level 3 heading ) There are two other main parts to TOGAF, besides the ADM: * The TOGAF Enterprise Architecture Continuum....etc. (implementing comment 55(b)) * The TOGAF Resource Base....etc. [Move rest of detailed text to "Enterprise Continuum: Introduction" in Part III] The ADM and the Architecture Continuum (existing heading demoted to level 4) [Move first two sentences to "Enterprise Continuum: Introduction" in Part III] As mentioned above, the TOGAF Enterprise Continuum provides a framework and context for the leveraging of relevant architecture assets in executing the ADM. These assets may include architecture descriptions, models and patterns taken from a variety of sources, as explained in Part III. At relevant places throughout the ADM, there are reminders to consider which architecture assets from the Enterprise Continuum the architect should use, if any. In some cases, for example in the development of a Technology Architecture, this may be TOGAF's own Foundation Architecture (see Part III). In other cases, for example in the development of a business architecture, it may be a reference model for e-Commerce taken from the industry at large. The practical implementation ..... [as per existing text] The ADM and the Resource Base (new level 4 heading) The TOGAF Resource Base is a set of resources - guidelines, templates, checklists, and other detailed materials - that support the TOGAF Architecture Development Method. The individual sections of the Resource Base are described separately in Part IV so that they can be referenced from the relevant points in the ADM as necessary, rather than having the detailed text clutter the description of the ADM itself." |
| 54 | p2/p2_intro.htm/9 | hd_trestini | Minor Editorial |
Enumerate each main part of TOGAF For consistency reasons, we should enumerate each main part, and describe them appropriately in the document. |
Add '1.' before title. | REJECT. Rationale: Replacing the bullets by numbers would add confusion, since the line items also refer to Part numbers within TOGAF (Part III, Part IV), which would be different from the ordered list numbers. (So we would end up with: "2. TOGAF Enterprise Architecture Continuum, described in detail in Part III..... 3. The TOGAF Resource Base, described in Part IV....". ) |
| 55 | p2/p2_intro.htm/10 | hd_trestini | Minor Editorial |
Enumerate each main part of TOGAF For consistency reasons, we should enumerate each main part, and describe them appropriately in the document. |
(a) Add '2.' before title. (b) Also, is it appropriate to
provide this level of description here? This could be confusing for a reader, as this part
is not described in detail in this section. Could reduce the paragraph to the following: |
(a) REJECT. See comment 54. (b) ACCEPT as amended. End the revised text at "specificity". Also see comment 53. |
| 56 | p2/p2_intro.htm/10 | w_stahlecker | Minor Editorial |
Improve description of the Continuum Highlight the use of
'Architecture Continuum' as a tool to de-conflict or avoid arguments across different
levels of |
Append to sentence 1: .... relevant architecture assets 'and provides navigational help when discussions move between different levels of specificity'. | ACCEPT as amended. '... different levels of abstraction'. Also see comment 55. |
| 57 | p2/p2_intro.htm/11 | hd_trestini | Minor Editorial |
Add space before this section. For readability purposes, should add a space between the main paragraph and the two components. |
Add a space before this section. | ACCEPT. |
| 58 | p2/p2_intro.htm/13 | hd_trestini | Minor Editorial |
Enumerate each main part of TOGAF For consistency reasons, we should enumerate each main part, and describe them appropriately in the document. |
Add '3.' before title. | REJECT. Rationale: See comment 54. |
| 59 | p2/p2_intro.htm/15 | hd_trestini | Minor Editorial |
Re-write sentence Re-write for better readability. |
Re-write: 'The ADM describes the process of moving from the TOGAF Foundation Architecture to an enterprise-specific architecture (or set of architectures). It leverages the elements of the TOGAF Foundation Architecture, as well as other relevant architectural assets, components, and building blocks along the way.' |
ACCEPT as amended. 'The ADM describes the process of moving from the TOGAF Foundation Architecture to an enterprise-specific architecture (or set of architectures). This process leverages...." Rationale: ("It" in the proposed text refers grammatically to "The ADM".) Also see comment 53. |
| 60 | p2/p2_intro.htm/16 | hd_trestini | Minor Editorial |
Re-write for better readability. Re-write for better readability. |
Re-write: 'The TOGAF Foundation Architecture is not the only resource available to an architect in using the ADM. There is a wide range of architectural models, components, and building blocks (relating to different technology domains), that an architect will seek to leverage. This much wider context is referred to in TOGAF as the Enterprise Architecture Continuum, and is explained in detail in Part III.' |
ACCEPT the change from "the
architect" to "an architect" REJECT the change from "architecture domains" to "technology domains" Rationale: The change is incorrect. "Architecture domains" is the term used in TOGAF to denote the four primary areas (Business, Data, Applications, technology) comprising the Enterprise Architecture space, which is what is being referred to here. Also see comment 53. |
| 61 | p2/p2_intro.htm/17 | hd_trestini | Minor Editorial |
Re-write for better readability. Re-write for better readability. |
Re-write: 'The practical implementation of the Enterprise Architecture Continuum will often take the form of a repository that includes reference architectures, models, as well as patterns that have been accepted for use within the enterprise, and/or actual architectural work done previously within the enterprise. The architect would seek to reuse as much as possible from the Continuum that was relevant to the project at hand. In addition to the collection of architecture source material, the repository would also contain architecture development work currently in-progress. |
REJECT. Rationale: No added value. First change changes the meaning (so that only patterns are accepted). |
| 62 | p2/p2_intro.htm/19 | hd_trestini | Minor Editorial |
Remove ',if you like'. Up to now, the document is more formal than not. The use of 'if you like', is really not appropriate here. |
Remove ',if you like'. | ACCEPT. |
| 63 | p2/p2_intro.htm/20 | hd_trestini | Minor Editorial |
Remove '-- including, but not limited to, the resultant ente It does not add anything to the sentence as the enterprise-specific architecture is the expected/assumed result. |
Remove: '-- including, but not limited to, the resultant enterprise-specific architecture'. |
REJECT. Rationale: The existing point is felt to be worth making. |
| 64 | p2/p2_intro.htm/22 | hd_trestini | Minor Editorial |
Re-write for better readability. Add to the end of previous Re-write for better readability. |
Add to end of the previous paragraph and re-write: 'In
fact, the first execution of the ADM will often be the hardest, since the architectural
assets available for re-use will be relatively few. Even at this stage of development
however, there will be architecture assets available from external sources such as TOGAF,
as well as the IT industry at large that could be leveraged in support of the effort. |
ACCEPT as amended. "Even at this stage of development, however, there will be architecture assets available from external sources such as TOGAF, as well as the IT industry at large, that could be leveraged in support of the effort." [additional commas] |
| 65 | p2/p2_intro.htm/23 | hd_trestini | Minor Editorial |
Re-write for better readability. Re-write for better readability. |
Re-write: 'The ADM is also useful to populate the
Foundation Architecture of an enterprise. Business requirements may identify the necessary
definitions and selections in the Foundation Architecture, including: a set of re-usable
common models; policy and governance definitions; or even as specific as overriding
technology selections (e.g. if mandated by law). Population of the Foundation Architecture
follows similar principles as for an Enterprise Architecture, with the difference that
requirements for a whole enterprise are restricted to the overall concerns of the
organization, and as such, are less complete than those for a specific enterprise.' |
REJECT. Rationale: Original is felt to be clearer. Change to: "'One of the main uses of the ADM is in populating.... ...architecture assets....
|
| 66 | p2/p2_intro.htm/28 | kirank | Major Editorial |
Iteration is over the whole method and also between phases. The process should be iterative over the whole method and also between phases. |
The whole method is iterative, both over the whole process and between phases of the process. | ACCEPT as amended. The ADM is iterative, over the whole process, between phases, and within phases. |
| 67 | p2/p2_intro.htm/32 | hd_trestini | Minor Editorial |
Remove sentence, and add to previous paragraph. Again for readibility purposes, this should not be a separate bullet. |
Remove as a separate bullet, and integrate with the point above. | ACCEPT. |
| 68 | p2/p2_intro.htm/33 | hd_trestini | Minor Editorial |
Add ', including' to the end of the sentence. Add ', including:' to the end of the sentence. |
Add ', including:' to the end of the sentence. | ACCEPT. |
| 69 | p2/p2_intro.htm/36 | hd_trestini | Minor Editorial |
Re-write for better readability. Re-write for better readability. |
Re-write: 'These decisions need to be made on the basis of
a practical assessment of the availability and applicability of resources, and the value
that can be realistically |
REJECT. |
| 70 | p2/p2_intro.htm/36 | m_iacob | Minor Editorial |
and instead of amd, replace accrue accrue seems to me an unusual word. |
(a) change 'resource amd competence' with 'resource and competence' (b) find a replacement for accrue |
(a) ACCEPT. (b) REJECT. Rationale: Original is felt to be OK. |
| 71 | p2/p2_intro.htm/37 | hd_trestini | Minor Editorial |
Re-write for better readability. Re-write for better readibility. |
Re-write: 'As a generic method, the ADM is intended to be
used by enterprises in a wide variety of different geographies and applied in different
vertical sectors / industry types. As such, it may be, but does not necessarily have to
be, tailored to specific needs. For example,' |
ACCEPT. |
| 72 | p2/p2_intro.htm/38 | hd_trestini | Minor Editorial |
Re-write for better readability. Re-write for better readability. |
Add space before this section, and re-write: 'it may be
used in conjunction with the set of deliverables of another framework, where these have
been deemed to be more appropriate for a specific organization (i.e. many US federal
agencies have developed individual frameworks that define the deliverables specific to
their particular departmental needs.)' |
ACCEPT as amended. "....organization. (For example, ...." instead of "....organization (i.e. ....". |
| 73 | p2/p2_intro.htm/39 | hd_trestini | Minor Editorial |
Minor readability change. Minor change. |
Re-write: 'it may be used in conjunction with the
widely-known Zachman Framework, which is an excellent classification scheme, but lacks an
openly-available, well-defined methodology.' |
REJECT. Rationale: TOGAF house style is U.S., not U.K., English. Hyphens are U.K., not U.S., style. |
| 74 | p2/p2_intro.htm/44 | hd_trestini | Minor Editorial |
Re-write for better readability. Re-write for better readability. |
Re-write: 'Throughout the ADM cycle, there needs to be frequent validation of gained results, against the original expectations for a particular phase of the process. This continuous validation against requirements, as depicted in Figure 1, assures that the architecture is meeting the needs of the business.' |
ACCEPT as amended. 'Throughout the ADM cycle, there needs to be frequent validation of results against the original expectations, both those for the whole ADM cycle, and those for the particular phase of the process.' |
| 75 | p2/p2_intro.htm/45 | c_greenslade | Major Editorial |
Name of phase H Inconsistent with text |
Name of Phase H in the diagram should be Architecture Change
Management. This comment applies to almost every occurrence of the ADM diagram. |
ACCEPT. |
| 76 | p2/p2_intro.htm/45 | chris_blake | Major Editorial |
Readablility of diagram Text in bubbles to small and overlap graphic |
make bubbles bigger and change font for readability | ACCEPT. Also see comment re. graphics generally. |
| 77 | p2/p2_intro.htm/45 | kirank | Major Editorial |
Suggested changes to figure. 1. The iterative nature of
the process should be emphasized by showing birectional arrows between the bubbles. |
(a) The iterative nature of the process should be emphasized
by showing birectional arrows between the bubbles. (b) Make bubbles clickable leading to the appropriate phase of ADM. |
(a) REJECT. Rationale: If all the arrows were bidirectional, there would be no main flow or sequence shown by the diagram (all the arrows would point both ways). The iterative nature of the process means that the diagram would be full of arrows if every valid flow were to be shown. The point of text is to explain that only the main flow of control is illustratyed. (b) ACCEPT. |
| 78 | p2/p2_intro.htm/47 | hd_trestini | Minor Editorial |
Re-write for better readability. Re-write for better readability. |
Re-write: 'The phases of the ADM cycle shown in Figure 1,
are further divided into steps, such as the ones depicted by the expansion of the
Technology Architecture phase in Figure 2.' |
ACCEPT as amended. Delete the comma after 'Figure 1'. |
| 79 | p2/p2_intro.htm/53 | hd_trestini | Minor Editorial |
Minor change. Minor change for better readability. |
Re-write: 'The ADM is a generic method for architecture
development which was designed to deal with most system and organizational requirements.
However, it will often be necessary to modify or extend the ADM, to suit specific
organizational needs. One of the tasks before applying the ADM to a specific situation is
to review its components for applicability, and then tailor them as appropriate to the
circumstances of the individual enterprise. This activity may well produce an
'enterprise-specific' ADM.' |
ACCEPT as amended. Change "was" to "is" (we are describing the present, not documenting history.) Also: "....to suit specific needs". "....before applying the ADM is to ..." |
| 80 | p2/p2_intro.htm/54 | hd_trestini | Minor Editorial |
Re-write for better readibility. Re-write for better readability. |
Re-wite: 'One reason for wanting to adapt the ADM, which it
is important to stress, is that the order of the phases in the ADM is to some extent
dependent on the maturity of the architecture discipline within the enterprise concerned.
For example, if the business case for creating an architecture in the first place is not
well recognized, then creating an Architecture Vision first, is almost always essential.
In this case, a detailed Business Architecture often needs to come next, in order to
underpin the Architecture Vision; detail the business case for remaining architecture
work; and secure the active participation of key stakeholders in that work. In other
cases, a slightly different order may be preferred. For example, a detailed inventory of
the baseline environment may be done before undertaking the Business Architecture.' |
REJECT. Rationale: The original is preferred. |
| 81 | p2/p2_intro.htm/55 | chris_blake | Major Technical |
sequencing of Architecture development cycles Packaged applications should be considered during IS Architecture rather than as part of the Technology Architecture. |
.... Business Architecture (or at least the completion of it)
may well follow completion of the Information Systems Architecture or Technology Architecture |
ACCEPT. |
| 82 | p2/p2_intro.htm/55 | hd_trestini | Minor Editorial |
Re-write for better readability. Re-write for better readability. |
Re-write: 'The order of phases may also be defined by the
business and architectural principles of an enterprise. For example, the business
principles may dictate that the enterprise be prepared to adjust its business processes to
meet the needs of a packaged solution, so that it can be |
ACCEPT. |
| 83 | p2/p2_intro.htm/56 | hd_trestini | Minor Editorial |
Re-write for better readability. Re-write for better readability. |
Re-write: 'Another reason for wanting to adapt the ADM is
when TOGAF would have to be integrated with another enterprise framework (as explained in
Part I, TOGAF in the Enterprise). For example, an enterprise may wish to use TOGAF and its
generic ADM in conjunction with the well-known Zachman Framework, or similar enterprise
architecture framework that has a defined set of deliverables specific to a particular
vertical sector: |
ACCEPT as amended. Change "....is when TOGAF would have to be integrated...." to: "is if TOGAF is to be integrated...." (simpler). Also change "similar" to "another". |
| 84 | p2/p2_intro.htm/58 | chris_blake | Minor Editorial |
Risk Management Use 'Risk Management' rather than 'risk
limitation' as the |
'Risk limitation' to 'Risk Management' | ACCEPT. |
| 85 | p2/p2_intro.htm/58 | hd_trestini | Minor Editorial |
Re-write. Re-write. |
Re-write: 'When it is necessary to link the ADM with other
enterprise processes, such as those for authorization; risk management; business planning,
requirements and budgeting; development planning; systems development and procurement,
etc.' |
ACCEPT as amended. Replace proposed text by: "The ADM is one of the many corporate processes that make up the corporate governance model. It is complementary to, and supportive of, other standard program management processes, such as those for: authorization; risk management; business planning and budgeting; development planning; systems development; and procurement." |
| 86 | p2/p2_intro.htm/59 | chris_blake | Minor Editorial |
large claim Prince II may be a a better programme methodology |
remove paragraph or tone it down | ACCEPT (See below). |
| 87 | p2/p2_intro.htm/59 | hd_trestini | Minor Editorial |
Re-write. Re-write. |
Re-write: 'When the ADM would be used as a method for something other than enterprise architecture. For example, as a general program management method.' |
ACCEPT as amended. 'The ADM is to be used as a method for something other than enterprise architecture: for example, ..." |
| 88 | p2/p2_intro.htm/60 | hd_trestini | Minor Editorial |
Add 'When' at the beginning of the sentence. Add 'When' at the beginning of the sentence. |
Add 'When' at the beginning of the sentence. | REJECT. Rationale: Unnecessary. |
| 89 | p2/p2_intro.htm/61 | hd_trestini | Minor Editorial |
Add 'When' at the beginning of the sentence. Add 'When' at the beginning of the sentence. |
Add 'When' at the beginning of the sentence. | REJECT. Rationale: Unnecessary. |
| 90 | p2/p2_intro.htm/61 | m_iacob | Major Technical |
Weak argument!! This argument seems weak to me. In fact,
if I look at how comprehensive ADM is, I am a little bit in doubt that this is the type of
development method a small enterprise would |
Explain why you think ADM would be fitted for SMEs. Give more arguments supporting this statement. | REJECT. Rationale: We are simply saying the ADM would need to be cut down, if used by an SME. |
| 91 | p2/p2_intro.htm/61 | w_stahlecker | Minor Editorial |
Attempt to respond to (m_iacob) | Append: 'Reduced complexity and smaller range of suppliers
may lead to more focused areas of choice in technology. But the analysis of business
models and drivers may have a high complexity.' |
REJECT. (See above). |
| 92 | p2/p2_intro.htm/62 | chris_blake | Minor Editorial |
META? gobledegook |
'meta-enterprise' to "collaborative business framework" | ACCEPT. |
| 93 | p2/p2_intro.htm/62 | hd_trestini | Minor Editorial |
Add 'When' at the beginning of the sentence. Add 'When' at the beginning of the sentence. |
(a) Add 'When' at the beginning of the sentence, and (b) add a blank line at the end of the paragraph to separate the next content. |
(a) REJECT. Rationale: Unnecessary. (b) ACCEPT |
| 94 | p2/p2_intro.htm/68 | kirank | Minor Editorial |
More than four key issues More key issues may be suggested and added. |
There are several key issues here: | ACCEPT. |
| 95 | p2/p2_intro.htm/69 | kirank | Major Editorial |
Insert new key issue Insert new key issue |
{b}Resources and business needs:{/b} There is a need to
optimize the architecting effort to the time and resource constraints and to suit the
business strategy. |
ACCEPT as amended. The proposed text gives some perfectly valid reasons for why it may be required to limit the scope. However, this section is not trying to explain the reasons for wanting to scope the architecture activity, merely the various dimensions in which the scope may be delimited. (Scope within the enterprise; scope within the four architecture domains (Business, Data,...etc.); scope in terms of level of detail covered; scope in terms of time horizon addressed.) Clarify by inserting the following: "There are many reasons for wanting to limit the scope of the architecture activity to be undertaken, most of which come down to the availability of people, finance, and other resources. The scope chosen for the architecture activity is normally directly dependent on available resources, and in the final analysis is usually a question of feasibility. Whatever the reasons for wanting or having to limit the scope of the architecture activity, there are four dimensions in which the scope may be defined and limited....." |
| 96 | p2/p2_intro.htm/69 | m_iacob | Major Technical |
Resources I miss one aspect here, namely the importance of
available resources (not only in terms of time horizon, but also in |
Insert a paragrah explaing the dependency between available resources and scoping. An alternative is to change the time horizon aspect into a more general Available Resources aspect. |
ACCEPT as amended. See comment 95. |
| 97 | p2/p2_intro.htm/71 | kirank | Minor Editorial |
Typing error of work traditional Typing error |
change tradiitional to traditional | ACCEPT. |
| 98 | p2/p2_intro.htm/78 | chris_blake | Minor Editorial |
Federations of architectures change paragraph clarity of description |
One important factor in this context is the increasing
tendency for large-scale architecture developments to be undertaken in the form of
'federated architectures' - independently developed, maintained, and managed architectures
that are subsequently integrated within a meta architectural framework that specifies the principles for interoperablity, migration, and conformance, thereby allowing specific business units to have architectures developed and governed as stand-alone architecture projects. |
ACCEPT as amended. "One important factor in this context is the increasing tendency for large-scale architecture developments to be undertaken in the form of 'federated architectures' - independently developed, maintained and managed architectures that are subsequiently integrated within a meta architectural framework. Such a framework specifies the principles for interoperablity, migration, and conformance. This allows specific business units to have architectures developed and governed as stand-alone architecture projects." |
| 99 | p2/p2_intro.htm/104 | chris_blake | Minor Editorial |
Paragraph change clarity |
While circumstances may sometimes dictate building an
architecture description not containing all four architecture domains, it should be
understood that such an architecture can not, by definition, be complete. The risks and trade-offs involved in not developing a complete architecture need to be articulated by the architect, and communicated to and understood by the enterprise management. |
ACCEPT as amended. "While circumstances may sometimes dictate building an architecture description not containing all four architecture domains, it should be understood that such an architecture can not, by definition, be a complete enterprise architecture. One of the risks is lack of consistency and therefore ability to integrate. Integration either needs to come later, with its own costs and risks; or the risks and trade-offs involved in not developing a complete and integrated architecture need to be articulated by the architect, and communicated to and understood by the enterprise management. |
| 100 | p2/p2_intro.htm/122 | chris_blake | Major Technical |
Rewrite section Provide a context for discussion on
approaches and |
There is a need to provide an integration framework that sits
above the individual architectures. This can be an 'enterprise framework' such as Zachman
to position the various domains and artefacts, or it may be a meta-architectural framework
(i.e. principles, models and standards) to allow interoperability, migration, and
conformance between federated architectures. The purpose of this meta-architectural
framework is to: 1) allow the architect to understand how components fit into the
framework; 2) derive the architectural models that focus on enterprise level capabilities;
3) define the conformance standards that enable the integration of components for maximum
leverage and reuse. As described above, a significant number of scoping decisions need to be taken, in terms of enterprise focus, architecture scope, level of detail, time horizons, and choice of transitional architectures, any one of which may result in a less than complete architecture description being developed. A potential way of assessing the gaps in scope or level of detail is to use an enterprise architecture framework (e.g. Zachman) to understand the coverage of the artefacts. There are varying degrees of architecture description “integratability.” At the low end, integratability means that different architecture descriptions (whether prepared by one organizational unit or many) should have a “look and feel” that is sufficiently similar to enable critical relationships between the descriptions to be identified, thereby at least indicating the need for further investigation. At the high end, integratability means that different descriptions should be capable of being combined into a single logical and physical representation. The state of the art is such that architecture integration can be accomplished only at the lower end of the integratability spectrum. Key factors to consider are the granuality and level of detail in each artefact, and the maturity of standards for the interchange of architectural descriptions. As organizations address common themes (such as service oriented architecture, and integrated information infrastructure), and universal data models and standard data structures emerge, integration toward the high end of the spectrum will be facilitated. However, there will always be the need for effective standards governance to reduce the need for manual coordination and confict resolution. |
ACCEPT as amended. Insert "At the present time" before "The state of the art....". Hopefully the state of the art will evolve. Insert "ideally" before "means" in "At the high end, integratability means....". |
| 101 | p2/p2_intro.htm/128 | chris_blake | Major Technical |
Terminology The obvious confusion around the term
'infrastructure' can |
Remove this section. | ACCEPT as amended. Move this whole section into Part IV, Resource Base. Add a footnote to the main text here to refer readers interested in infrastructure, acquisitions and mergers, consolidation, etc., to this section. Replace bottom row with "buckets" and change text to "common elements". These are elements that would be captured in the Enterprise Continuum. |
| 102 | p2/p2_intro.htm/132 | w_stahlecker | Minor Editorial |
Provide an outlook to future developments There are both
the new wording of The Open Group's vision 'Boundaryless Information Flow' and the dynamic
evolution of e-services (web-services and beyond via |
Prepend paragraph: 'In this sense the Infrastructure
Architecture is an essential definition in achieving 'boundaryless information flow'
across an enterprise's scope. With progress towards aggregation of e-services the content
of an Infrastructure will expand above today's delineation' |
ACCEPT. |
| 103 | p2/p2_intro.htm/149 | chris_blake | Minor Editorial |
Remove the partial metaphor Does not make sense |
John Zachman himself likes to point out the alternatives
available to those who can't countenance the amount of work implied in developing the all
models required in his framework. There are only three choices: trial and error starting
from new; or reverse engineering the architecture from the existing systems; all of which
are risky and/or hugely expensive. What is necessary due to the pace of change is to have
a set of readily deployable artifacts and a process for assembling them swiftly. |
REJECT. (As agreed by submitter.) |
| 104 | p2/p2_prelim.htm/4 | w_stahlecker | Minor Editorial |
Order by priority The first objective seems to be an odd
one to start with, while others are more important - IMO. I dare including the |
To ensure that everyone who will be involved in, or benefit
from this approach, is committed to the success of the architectural process. To define the architecture principles that will inform the constraints on any architecture work. To define the 'architecture footprint' for the organization - the people reponsible for performing architecture work, where they are located, and their responsibilities. To define the scope and assumptions (particularly in a federated architecture environment) To set up and monitor a process (normally including a pilot project) to confirm the fitness for purpose of the defined framework. If necessary, to define a set of criteria for evaluating architecture tools (an example set of criteria is given in Part IV), repositories and repository management processes to be used to capture, publish, and maintain architecture artifacts. To define the framework and detailed methodologies that are going to be used to develop enterprise architectures in the organization concerned. |
ACCEPT. |
| 105 | p2/p2_prelim.htm/5 | c_greenslade | Minor Editorial |
Commitment to the architectural process Needs to be done. |
To ensure that everyone who will be involved in, or benefit from this approach, is committed to the success of the architectural process. | ACCEPT. |
| 106 | p2/p2_prelim.htm/15 | w_stahlecker | Minor Editorial |
Re-order Principles are rooted in a business and its
architecture drivers and thus appear to be suitable for driving the |
move 18/19/20 before current 15/16/17 | ACCEPT. |
| 107 | p2/p2_prelim.htm/20 | m_iacob | Minor Editorial |
replace is informed with complies with 'is informed by' is a strange formulation |
Put 'Architecture work complies with business principles...' instead of 'Architecture work is informed by business principles...'. | REJECT. Rationale: See above. |
| 108 | p2/p2_prelim.htm/21 | a_bodor | Major Editorial |
and the paramountcy of this body This body needs to be the leader. |
Replace 'paramountcy with leadership. | ACCEPT as amended. Reword as follows: "The body responsible for governance will also normally be responsible for approving the architecture principles, and for resolving architecture issues. This will normally be one of the principles cited." |
| 109 | p2/p2_prelim.htm/21 | m_iacob | Minor Editorial |
replace paramountcy Paramountcy is an artificially created word. |
Replace paramountcy with supremacy, or dominance , or with something semantically equivalent. | ACCEPT. See comment 108. |
| 110 | p2/ta/ta_intro.htm/3 | hd_trestini | Critical Editorial |
Should add an introduction/description for this section. The
document is missing and introductory |
Add an introductory paragraph that describes the intent of this section. | ACCEPT. Insert: "This is the detailed description of the process to develop the Target Technology Architecture." |
| 111 | p2/ta/ta_intro.htm/15 | hd_trestini | Minor Editorial |
Minor change. Minor change. |
Re-write: 'It is possible that an organization creating or adapting a Technology Architecture, already mandates the use of a list of approved suppliers/products for that organization. Such a list would be an input to the definition of the organization-specific architectural framework, as shown in Figure 2. The architectures can then be used as procurement tools to govern future growth and the development of the organization's IT infrastructure.' |
ACCEPT as amended. Remove comma after "Architecture". |
| 112 | p2/target/app_arch.htm/18 | chris_blake | Minor Editorial |
Status of biztalk.org Currency |
Microsoft appear to be losing interest in the BizTalk Framework, as evidenced by their lack of participation in biztalk.org. | ACCEPT as amended. Delete the Biztalk bullet and carry on the second bullet text after the main text. |
| 113 | p3/trm/trm_conc.htm/7 | w_stahlecker | Minor Editorial |
Add explanation of the SIB Expand on The Open Group's capabilities |
Insert paragraph: 'The SIB represents a subset of available standards which are relevant to the broad scope of The Open Group's members. Entries are based on these members' consensus. Acecss by enterprises to the the SIB as basis for further adaptation and expansion is possible.' |
REJECT. Rationale: This is said in the main section on the SIB. |
| 114 | p4/bbs/bbs_adm.htm/54 | l_stucki | Minor Editorial |
Color choice Bright Green is hard to read and look at |
Pick a better color. | ACCEPT. Address as part of overall graphics improvement, above. |
| 115 | p4/bus_scen/bus_scen.htm/47 | j_spencer | Major Editorial |
Amplify business scenario gathering techniques Leverage
additional material in proposed Business Scenario |
Insert after this sentence: 'Multiple techniques may be used in this phase, such as basic research, qualitative analysis, quantitative analysis, surveys, requests for information, etc. As much information as possible should be gathered and pre-processed “off-line” prior to any face-to-face workshops (described below). For example, a request for information may include a request for strategic and operational plans. Such documents typically provide great insights, but the information that they contain usually requires significant preprocessing. The information may be used to generate an initial draft of the business scenario prior to the workshop, if possible. This will increase the understanding and confidence of the architect, and the value of the workshop to its participants.' |
ACCEPT as amended. No hyphen in "preprocessed". Change "basic" to "information". |
| 116 | p4/bus_scen/bus_scen.htm/48 | j_spencer | Major Editorial |
Additional purpose of Business Scenario workshop. Leverage
additional material in proposed Business Scenario |
Add at the end of this paragraph: 'Where a draft of the Business Scenario already exists - for example, as a result of preprocessing information gathered during this phase, as described above - the workshop may also be used to review the state of the Business Scenario draft.' |
ACCEPT. |
| 117 | p4/bus_scen/bus_scen.htm/50 | j_spencer | Major Editorial |
Delete reference to use of existing techniques Content is pretty self-evident. If retained, it belongs in the opening paragraph. |
Delete this paragraph here. Consider merging the text into the opening paragraph above. | ACCEPT as amended. Merge into opening paragraph. |
| 118 | p4/bus_scen/bus_scen.htm/51 | j_spencer | Major Editorial |
Add reference to real world examples Leverage additional
content in proposed Business Scenario |
At the end of the preceding subsection, add: 'When gathering information in workshops, or off-line through research or surveys, the architect can greatly strengthen the business scenario by obtaining “real world examples” - case studies to which the reader can easily relate. When citing real world examples, it is important to maintain a level of anonymity of the parties involved, to avoid blame!! |
ACCEPT as amended. "When gathering information, the architect..." |
| 119 | p4/bus_scen/bus_scen.htm/53 | j_spencer | Major Editorial |
Add reference to maintaining linkages to business processes Leverage
additional content in proposed Business Scenario |
Add at end of preceding subsection: 'In the analysis phase it is important to maintain linkages between the key elements of the business scenario. One technique that assists in maintaining such linkages is the creation of matrices that are used to relate business processes to each of: * Constituencies * Human actors * Computer actors * Issues * Objectives In this way, the business process becomes the binding focal point – which makes a great deal of sense, since in most cases it is business process improvement that is being sought.' |
ACCEPT. |
| 120 | p4/bus_scen/bus_scen.htm/55 | j_spencer | Major Editorial |
Add reference to readout meetings Leverage additional text in proposed Business Scenario publication. |
Add after next paragraph: 'Multiple Business Scenario workshops or 'readout' meetings with the sponsors and involved parties are recommended. The meetings should be set up to be open and interactive. It is recommended to have exercises built into meeting agendas, in order to test attendees' understanding and interest levels, as well as to test the architect's own assumptions and results.' |
ACCEPT. |
| 121 | p4/bus_scen/bus_scen.htm/62 | j_spencer | Minor Editorial |
Change sample content of Business Scenario Leverage additional text in proposed Business Scenario publication. |
Replace contents with following: PREFACE EXECUTIVE SUMMARY DOCUMENT ROADMAP BUSINESS SCENARIO BUSINESS SCENARIO OVERVIEW BACKGROUND OF SCENARIO PURPOSE OF SCENARIO DEFINITIIONS/DESCRIPTIONS OF TERMS USED VIEWS OF ENVIRONMENTS AND PROCESSES BUSINESS ENVIRONMENT Constituencies PROCESS DESCRIPTIONS Process “a” …etc. TECHNICAL ENVIRONMENT Technical environment “a” …etc. ACTORS AND THEIR ROLES AND RESPONSIBILITIES COMPUTER ACTORS AND ROLES RELATIONSHIP OF COMPONENTS AND PROCESSES HUMAN ACTORS AND ROLES RELATIONSHIP OF HUMANS AND PROCESSES INFORMATION FLOW ANALYSIS PRINCIPLES AND CONSTRAINTS IT Principles Constraints REQUIREMENTS BUSINESS SCENARIO ANALYSIS PROBLEM SUMMARY Issues Objectives SUMMARY APPENDIX A: BUSINESS SCENARIOS – ADDITIONAL INFORMATION APPENDIX B-n: BUSINESS SCENARIO WORKSHOP NOTES |
ACCEPT. |
| 122 | p4/bus_scen/bus_scen.htm/201 | j_spencer | Major Editorial |
Add reference to document structure Leverage additional text in proposed Business Scenario publication. |
Insert at the beginning: 'Effective Business Scenario documentation requires a balance between ensuring that the detail is accessible, and preventing it from overshadowing the results and overwhelming the reader. To this end, the Business Scenario document should have the main findings in the body of the document and the details in appendices. In the appendices:' |
ACCEPT. |
| 123 | p4/bus_scen/bus_scen.htm/210 | j_spencer | Minor Editorial |
Amplify description of main body Leverage additional text in proposed Business Scenario publication. |
Add at end: 'In the main body of the Business Scenario: * Generalize all the relevant data from the detail in the appendices.' |
ACCEPT. |
| 124 | p4/bus_scen/bus_scen.htm/247 | j_spencer | Minor Editorial |
Change 'will' to 'can' Reads better. |
Here and in each analagous position in the following, change
'will be realized' to 'can be realized'. |
ACCEPT. |
| 125 | p4/bus_scen/bus_scen.htm/321 | j_spencer | Major Editorial |
Improve summary Leverage additional text from proposed Business Scenario publication. |
Insert here: 'Business Scenarios help address one of the most common issues facing IT executives: aligning Information Technology with the business. The success of any major IT project is measured by the extent to which it is linked to business requirements, and demonstrably supports and enables the enterprise to achieve its business objectives. Business Scenarios are an important technique that may be used at various stages of defining enterprise architecture, or any other major IT project, to derive the characteristics of the architecture directly from the high-level requirements of the business. Business Scenarios are used to help identify and understand business needs, and thereby to derive the business requirements that the architecture development, and ultimately the information technology, has to address. However, it is important to remember...' |
ACCEPT. |
| 126 | p4/cases/case_intro.htm/49 | j_spencer | Major Editorial |
Replace NATO Case Study New case study updates previous one, and exemplifies concept of transitional architectures, referred to in 'Introduction to the ADM' in Part II. |
Replace the text here, and the referenced case study, with the new text and case study at [reference]. | ACCEPT. |
| 127 | p4/princ/princ.htm/44 | chris_blake | Minor Editorial |
Additional qualities of good principles Make it better |
A good set of principles will be founded in the beliefs and
values of the organisation and expressed in language that the business understands and
uses. Principles should be few in number, future oriented, and endorsed and championed by senior management. They provide a firm foundation for making architecture and planning decisions, framing policies, procedures, and standards, and supporting resolution of contradictory situations. A poor set of principles will quickly become disused, and the resultant architectures, policies, and standards will appear arbitrary or self-serving, and thus lack credibility. Essentially, principles drive behaviour. |
ACCEPT. |
| 128 | p4/princ/princ.htm/69 | w_stahlecker | Minor Editorial |
Add a principle about protection of assets held in IT With
IT being a major location of an enterprise's IP it |
Add: '8. Principle Statement: A major part of an enterprise's Intellectual Property is hosted in the IT domain. Protection of these assets must therefore be reflected in architecture, implementation and governance of IT. Rationale: While protection of IP assets is everybodies business, much of the actual protection is implemented in the IT domain. Even trust in non-IT processes can be managed by IT processes (email, mandatory notes, etc.). Implications: A Security Policy, governing human and IT actors, can substantially improve protection of IP. This is both in the sense of avoiding compromises and of reducing liabilities. While the security policy reaches beyond IT its administration will rely strongly on IT. A Security Policy also helps profile investments along the value of assets and their risk exposure. Resources can be found at the SANS Institute on such policies. |
ACCEPT as amended. Title: Protection of Intellectual Property Statement: The enterprise's IP must be protected. This protection must be reflected in the IT Architecture, Implementation, and Governance processes. Rationale: A major part of an enterprise's Intellectual Property is hosted in the IT domain. Implications: While protection of IP assets is everybody's business, much of the actual protection is implemented in the IT domain. Even trust in non-IT processes can be managed by IT processes (email, mandatory notes, etc.). A Security Policy, governing human and IT actors, will be required that can substantially improve protection of IP. This must be capable of both avoiding compromises and reducing liabilities. Resources on such policies can be found at the SANS Institute. |
| 129 | p4/tools/tools_intro.htm/1 | j_spencer | Major Editorial |
Align Tools section with TOGAF Tools Support Specification The two should be closely aligned. |
The draft TOGAF Tools Support Specification (currently under
development) will define the basis for certification for TOGAF tool support. This section
should be closely aligned with it. |
REJECT. Rationale: Unnecessary. |
| 130 | p4/zf/zf_mapping.htm/14 | c_greenslade | Minor Editorial |
Ballpark? Zachman uses the term SCOPE for the top row of
the Framework. Also Ballpark is rather American type slang, |
The Planner's or Scope Viewpoint | ACCEPT as amended. Also use the latest ZIFA graphic and terminology throughout this section. Also include references of the form: "Rm,Cn; Ro,Cp; ..." etc., which are familiar to those who use the Zachman Framework. |
| 131 | p4/zf/zf_mapping.htm/35 | c_greenslade | Minor Editorial |
General comment on the mapping Easier to follow the mapping |
Is it possible to put all the cell references into left to right, top to bottom order? | ACCEPT. Order is: scope/data, scope/function... business/data, ...etc. |
| 132 | p4/zf/zf_mapping.htm/39 | c_greenslade | Major Editorial |
Architecture principle mapping Architecture principles cover all aspects |
ZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time, Scope/Motivation |
ACCEPT. |
| 133 | p4/zf/zf_mapping.htm/42 | c_greenslade | Major Editorial |
Architecture Principle Mapping Make compatible with text. |
Modify to include extra mapping of Architecture principles. | ACCEPT. |
| 134 | p4/zf/zf_mapping.htm/54 | c_greenslade | Major Editorial |
Architecture Principle Mapping Architecture principles cover all aspects |
ZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time, Scope/Motivation | ACCEPT. |
| 135 | p4/zf/zf_mapping.htm/92 | c_greenslade | Major Editorial |
Zachman mapping Text and diagram not compatible. |
Diagram and text need to be aligned. Scope/Data is on the diagram, but not in the text. System/Function is in the text, but not in the diagram. |
ACCEPT. Under paragraph 68 (Business Principles), include: ZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time, Scope/Motivation Add System/Function coverage to the graphic. |
| 136 | p4/zf/zf_mapping.htm/104 | c_greenslade | Major Editorial |
Data Principles Mapping Data principle include aspect of location, users and timeliness |
ZF: Scope/Data, Scope/Network, Scope/People, Scope/Time | ACCEPT. |
| 137 | p4/zf/zf_mapping.htm/133 | c_greenslade | Major Editorial |
Data Principles Mapping Make compatible with text |
Modify to include extra mapping of Data principles. | ACCEPT. |
| 138 | p4/zf/zf_mapping.htm/140 | c_greenslade | Major Edit |