Factors to Consider When Choosing Accounts Payable Services Providers.pptx
WorldCOMP-2010 BenKBovée IKE4145 Enterprise Info Arch for Traceability 14-May
1. Enterprise Information Architecture for Traceability
Ben K Bovée
Principal, Patterndigm, Fairfax, Virginia, US
Abstract - The value of any Enterprise Information documents referenced, and abbreviations for lengthy terms–
Architecture (EIA) is assessable in terms of its utilization to especially those repeated.
enable change management throughout the System
Development Life Cycle (SDLC). The presented framework 1.1 Situation
depicts generic concerns at the intersection of natural human
thought processes and business perspectives; features The ZF has axes and contents which yield more basic and
differentiating it from other EIA frameworks are: exploratory research findings than applied and confirmatory
research results facilitating business and system development
• Enabling comprehensive traceability for any organization and management. The ZF perspective axis identifies five roles
endeavor to effect change management; (planner, owner, architect, designer and builder) which is an
incomplete set of roles of ambiguously related to real-world
• Leveraging natural human thought processes patterns in roles. Each of the aforementioned roles is associated with a
any SDLC; ZF row. Each of the “five Ws” is associated with a ZF
column.
• Basing business perspectives on National Institutes of
Standards and Technology (NIST) perspectives; The ZF, while a noble attempt to holistically characterize
enterprise information, is an over-simplification and falls short
• Augmenting NIST perspectives with in the ability to comprehensively and consistently effect
analytical/architectural perspective; and information traceability supporting all enterprise perspectives.
• “Five Ws” concerns are at intersections of
1.2 Problem
aforementioned subjects and perspectives (instead of
The ZF assumes the “five Ws” are consistent for all enterprise
assuming concerns are identical from different perspectives, but they are not. The “How” from one
perspectives). perspective can be the “What,” “When” or “Where” for
another perspective. The focus of a concern identifies the
Since each discipline has related planning, monitoring and significance behind the “five Ws.” While a business
evaluating aspects to support efforts to effect its efficiency, development manager focuses on the business customers and
such organization and supporting processes [1], [2] are services and products they consume, a project manager
omitted. focuses on the development processes, an operations manager
focuses on their service and product delivery value chain and
Keywords: Enterprise, Information, Traceability, Model- support processes, an analytical manager focuses on the
driven, Architecture, Framework. business concerns and appropriately prioritizing efficiency
improvements to operations and information management and
1 Introduction automation, and an architectural manager focuses on the
design and implementation of automation systems.
This section introduces analysis of the situation, problems,
implications, needs (S-P-I-N) and approach to solving the The ZF falls short by:
needs for a new generation of the most widely used enterprise • Omitting the Analysis perspective of business, software
information architecture, the Zachman Framework (ZF) [3]. and systems as well as SDLC processes;
The next section introduces the solution basis and • Omitting the Software perspective within Architecture
components. The subsequent section presents findings from– including software objects;
and potential future work based on–the conclusions. The final • Assuming the “five Ws” are the same for each included
section has terms, figures, documents and abbreviations perspective;
referenced. • Disproportionately emphasizing the significance of
business rules (BR);
The following is in appendixes: A key for figure symbols, • Ambiguously identies how BRs are identified, classified
definitions of central terms used, titles and URLs of managed, and utilized; and
2. • Excluding a general characterization of complete SDLC The following figure depicts some of the artifacts and related
processes for effecting its utilization. concerns from Managerial, Operational and Analytical
perspectives of the enterprise.
1.3 Implications
There are no known SDLCs which explicitly follow or
navigate the ZF as a validation of the methodology. Perhaps
the most noble attempt to analyze the Zachman Framework
([4]), is not able to explain:
• Columns one or two (all) rows other than discussing data
and manual process modeling;
• Column three rows one, four or five;
• Column four rows one, four or five;
• Column five rows four or five; and
• Column six rows one, four or five. The following figure depicts the notation used in figures. The
icons are intuitive and similar to, aligned with Business
1.4 Needs Process and Model Notation (BPMN [8]), or utilizing the
Unified Modeling Language (UML [9]) profile extension
An effective EIA framework would address the mechanism.
aforementioned problems. The Bovée EIA (BEIA) addresses
each of the problems in the following Solution section.
1.5 Approach
The NIST trichotomy of Managerial, Operational and The following table lists parenthetical abbreviations in related
Technical (M-O-T) business perspectives is one of the figure elements and table entries. Goals are analogous to Use
fundamental driving factor behind identifying the BEIA Case objectives.
perspectives. In each of the following figures, all of the “five A Analysis/analytical O Operations
Ws” depicted are a combination of relative to the system
Arch. Architecture o Output
(product) to be built, bought or augmented, or the manual
processes (services) to be engineered. Dec Decision P Process
F Functional (rqmt.) p Procedure
2 Solution G Goal S System
An effective EIA would be supported by real-world i Input s Software
experience, proven and repeatable through empirical M Management/ managerial Scty Security
observation of work patterns. The BEIA is empirically derived
N Nonfunctional (rqmt.) T Technical
from personal consulting experience providing analytical and
architectural services on programs and projects designing
processes, and building, buying and integrating systems 2.2 Add Architecture of Software and Systems
supporting small, medium, large and very large businesses
The following figure, similar to one in [10], depicts multiple
with distributed users, information and computing.
apropos situations when the “What” from one perspective is
the “Why”, “Where” or “How” to another; and when “How” is
2.1 Add Analysis bridging Functional and the “When”, “What”, “Why” or “When” to another.
Technical Perspectives
Traditional distribution of enterprise concerns among M-O-T
perspectives allocates managerial and operational perspectives
to business concerns, and system and software perspectives to
technical concerns. The perspective of analysts working to
facilitate all M-O-T concerns is central to the BEIA. Business
Analysis work includes enterprise analysis, requirements
elicitation, requirements analysis, requirements management
and communication, and solution assessment and validation
[5]. System analysis is distributed across Requirements,
Design and Construction disciplines [6]. Architecture
encompasses Design and Construction disciplines [7].
3. 2.3 Appropriately Emphasize Business Rules 2.5 Align Work Products with Perspectives
The following figure depicts an appropriate significance for The following figure depicts the SDLC deliverable artifacts
Business Rules to an enterprise. and the traceability flow between them.
2.4 Accommodate all Perspectives' Concerns
The analytical concerns bridge and supplement the
combination of augmented NIST (M-O-A-T) perspectives and
the dichotomy of Business and System foci. The following 2.6 Provide Depth to Encompass all Concerns
table depicts the core findings from the approach including an
The BEIA structure naturally accommodates and aligns
identification of the respective thought process utilized to
additional views of enterprise information related to and
identify the information in the associated intersection with
supplementing that in the preceding table and figures. There
perspective.
is insufficient space here to depict the entire structure.
Supplementary views include example aliases to the “-ion”
Concern Perspective and Focus
process names, concept type names and examples, concept
Tech. sub-type names and examples, alignment with the US Federal
Process Mgt. Ops.
(“-ion”) Analysis Arch/Dev. Enterprise Architecture (FEA [11]), and supporting notations
Business System
including NIST Integrated Computer Aided Manufacturing
(ICAM) Definition for Function Modeling (IDEF0; [12]), the
Motivat- Why Why
US Department of Defense Architecture Framework (DODAF
Orientat- Where(P) How(M,O) How(A) How(T) [13]), BPMN ([8]), and UML ([9]).
Vis- What Why What(M,S) Why When(M)
Delegat- Who(O,T) Who(O), Who, When(O) 3 Conclusion
When(i) When(i)
Contextualizat- Where Where(S,s) What(M) Where(S) Who(Scty)
The BEIA provides a taxonomic framework accommodating
all enterprise concerns at the intersections of intuitive
Allocat- When(N) When(o) Where(s) Where
perspectives and natural thought processes and patterns. The
Decis- How (BR) What(P) When(M,O) Why(BR) BEIA naturally aligns with a generic SLDC ([1]), enabling
Qualificat- Justification, Initiation, Completion information stored within it to be leveraged for practical
purposes. The range of practical system-related purposes for
Evaluat- Acceptance
BEIA are not limited to development (e.g., select portions may
Classificat- What(O) What (G) What(N) be included to enable acquisition request for proposal (RFP)
Specificat- How(F,N,S) What(F,i) What(S,s) solitation or response).
Attribut- (Meta-data)
Prioritizat- When (F) Whene(o) When When When(T) 3.1 Findings
Generalizat- Where(s) Who What(M) Through the association of multiple diagram types (some
Quantificat- (Goal) (Data) (Solution) (Metrics) (Perform.) within the same framework or notation), is the identification of
ideas discovered during thought processes either without any
Solut- How(P) How(S,s) What(O)
or with multiple supporting graphical notations. These gaps
Realizat- How(p) How(s) What(S) and overlaps identify opportunities for modeling standards to
Implementat- How(O) How(S,s) evolve by expanding to adopt ideas from other notations or
removing redundant idea diagrams and representations.
4. 3.2 Future Work 4.2 Appendix B: Biography
Some enterprise information concepts may be depicted by one Mr. Bovée has been providing consulting services since 1993.
graphical notation, others may be depicted by multiple He is an early adopter of, and published contributor to UML
notations, and others currently are not supported by any ([9)] and Semantics of Business Vocabulary and Business
notation. No single notation supports depiction of all concepts Rules (SBVR [17]) standards (see [18] and [19] respectively).
currently graph-able. Since the UML supports the largest set
of concepts, it has the most advantageous marginal Mr. Bovée has worked on very large system integration
augmentation to support diagramming EIA in a holistic and (VLSI) programs and projects, specializing in designs of
truly unified fashion. complex processes and systems with distributed users and
computing.
Much effort was expended to keep the analysis of the EIA S-
P-I-N, the solution approach, and findings concise. A poster Mr. Bovée incorporated his own business in 2002, and lives
supplements this paper. A more concise summary of these with his wife and daughter, in Virginia. Ben has a Bachelor of
publications could make them more tractable and usable. Science in Applied Mathematics, hobbies of blacksmithing
and gardening, and is pursuing dual Master of Science degrees
The identified framework is considerably more complex than in Operations Research and Statistics.
Zachman, but all of the BEIA contents have been
autonomously determined to be necessary and sufficient. 4.3 Appendix C: References
Independent trials and research efforts evaluating the
approach and conclusions would support or refuse the In the following entries, publications by authors with multiple
findings. entries are differentiated by preceding bracketed text, and
those with a URL Internet address (see the next section), the
title is hyper-linked.
4 Appendixes
This final section presents key terminology, references of [1] [IEEE 12207] IEEE Computer Society Standards
works from contributing and cited authors, and abbreviations Coordinating Committee. IEEE/EIA/ISO/IEC 12207.0
used in preceding sections. Standard for Information Technology – Software life cycle
processes, New York NY, March 1998.
4.1 Appendix A: Glossary
[2] Project Management Institute. A Guide to the Project
The following define key terms. Cross-referenced terms are Management Body of Knowledge (PMBOK), ed. 3, Newtown
italicized. Square PA, 2004.
Term Definition [3] [IBM Zachman] John Zachman. “A framework for
Architecture Organizational structure of a system. [14] information systems architecture,” IBM Systems Journal, vol.
Component Part of a [human or automated] system ... [which] may 26, no. 3, pp. 276-292, International Business Machines
be divided in to [sub parts]. [14]
Corporation, New York NY, 1987.
Data A representation of facts, concepts or instructions in a
manner suitable for communication, interpretation or
processing by human or automatic means. [14] [4] David Hay. Requirements Analysis: From Business
Enterprise Organization with sufficiently large and complex Views to Architecture, Pearson Education, Upper Saddle River
structure to require architectural controls. NJ, David Hay, 2003.
Framework, Frame or skeletal structure designed to support or
Theoretical enclose fitted and joined parts. [15] [5] Damker Media Group. A Guide to the Business Analysis
Information Data, context and sharing providing clear and Book of Knowledge (BABOK) ver. 2.0, International Institute
valuable meaning and value. [16] of Business Analysis, Marietta GA, 2009.
Requirement A documented representation of a condition or
capability needed by a user component to […] achieve
an objective, satisfy a contract, standard, or other [6] [IEEE SWEBOK] IEEE Computer Society Professional
formally imposed documents. [14] Practices Committee. Guide to the Software Engineering
System A collection of components organized to accomplish Body of Knowledge (SWEBOK), New York NY, 2004.
one or more specific functions. [14]
Traceability The degree to which a relationship can be established [7] [IBM RUP] Ivar Jacobsen, Grady Booch, James
between two or more [system requirements] ... Rumbaugh. Rational Unified Process (RUP), IBM Rational
[validating] its [existence]. [14] Software Corporation, 1987.
5. [8] [OMG BPMN] Object Management Group. Business
Process Model and Notation (BPMN) ver. 1.2, 3 January [2] www.unipi.gr/akad_tmhm/biom_dioik_tech/files/pmbok.
2009. pdf (not latest version)
[9] [OMG UML] Object Management Group. Unified [3] www.zachmaninternational.com/images/stories/ibmsj 2603e.pdf
Modeling Language Superstructure (UML) ver. 2.2, 2
February 2009. [4] www.amazon.com/Requirements-Analysis-Business-Views
-Architecture/dp/0130282286/ref=sr_1_3?ie=UTF8&s=books
[10] [IBM MRMUC] Ivar Jacobsen et al.. “Mastering &qid=1273344828&sr=1-3 (for sale)
Requirements Management with Use Cases,” IBM University,
IBM Rational Software Corporation, 2006. [5] books.google.com/books?id=CFHw8jSEWwkC&lpg=PP1
&dq=A%20guide%20to%20business%20analysis%20body% 20of
%20knowledge&pg=PP1#v=onepage&q&f=true (read-only)
[11] Office of Management and Budget. Federal Enterprise
Architecture Consolidated Reference Model (FEA CRM) ver.
[6] www.computer.org/portal/web/swebok
2.3, October 2007.
[7] www.rhjconsulting.com/rationalunifiedprocess/artifact/
[12] National Institutes of Standards and Technology.
ovu_arts.htm (incomplete)
Federal Information Processing Standard 183: Integration
Definition for Function Modeling (IDEF0), 21 December
[8] www.omg.org/spec/BPMN/1.2/PDF/
1993.
[9] www.omg.org/spec/UML/2.2/Superstructure/PDF/
[13] Department of Defense Deputy CIO. Department of
Defense Architecture Framework (DODAF) ver. 2.0.
[11] http://www.whitehouse.gov/omb/assets/fea_docs/FEA
_CRM_v23_Final_Oct_2007_Revised.pdf
[14] [IEEE 610] IEEE Computer Society Standards
Coordinating Committee, IEEE Standard 610.12: Glossary of
[12] www.itl.nist.gov/fipspubs/withdraw.htm (obsolete
Software Engineering Terminology , New York NY, 11
standard)
September 2002.
[13] cio-nii.defense.gov/sites/dodaf20/products/DoDAF_2-0_
[15] Webster's Dictionary.
web.pdf
[16] Suzanne Acar. US Federal Enterprise Architecture Data
[14] www.idi.ntnu.no/grupper/su/publ/ese/ieee-se-glossary-
Reference Model (DRM), 20 September 2006.
610. 12-1990.pdf
[17] [OMG SBVR] Object Management Group. Semantics [15] http://dictionary.reference.com/
of Business Vocabulary and Business Rules (SBVR) ver. 1.0,
January 2008. [16] www.whitehouse.gov/omb/assets/egov_docs/DRM_2_0_
Final.pdf, www.dbq.or.kr/conference/2006/pdf/Harmony1_02
[18] [OMG Bovée 1999] Ben Bovée. “Potential New and _SuzanneAcar.pdf (the latter is a high-quality summary)
Modified UML Associations and Definitions: UML 1.4 RFI
Response,” Object Management Group, November 1999. [17] www.omg.org/spec/SBVR/1.0/PDF/
[19] [OMG Bovée 2004] Ben Bovée. “Proposed Business
Rule Semantics, Notations and Management Practices (Meta- 4.5 Appendix E: Abbreviations
Rules): SBVR 1.0 RFI Response,” Object Management The following contains preceding abbrev.'s (abbreviations)
Group, 10 October 2004. and respective terms other than businesses/organizations and
items only mentioned in the References section. Like the
4.4 Appendix D: Reference URLs Glossary, cross-referenced entries are italicized.
The following (starting with, “http://”) are on-line, free (for
download), complete and current unless otherwise noted as of Abbrev. Represents
publication. References without a URL are commercial, BEIA Bovée EIA
licensed ,or archived by standards commitee. BR Business Rule
[1] www.saiglobal.com/PDFTemp/Previews/OSH/iso/updates CIO Chief Information Officer, DOD
2008/wk13/ISO-IEC_12207-2008.PDF, http://www.ieee.org/ CRM Consolidated Reference Model, FEA
publications_standards/index.html#IEEE_Standards (for sale)
6. Abbrev. Represents
DOD Department of Defense, US
DODAF DOD Architecture Framework
EIA Enterprise Information Architecture
FEA Federal Enterprise Architecture, OMB
FIPS Federal Information Processing Standard, NIST
Five Ws Who, What, Where, When, Why and How
ICAM Integrated Computer Aided Manufacturing
IDEF ICAM Definition, FIPS
IDEF0 IDEF for Function Modeling
M-O-A-T managerial, operational, analytical, technical
(perspectives)
M-O-T managerial, operational, technical (perspectives), NIST
NIST National Institutes of Standards & Technology, US
OMB Office of Management and Budget, US
Perform. Performance
RFI Request for Information
RFP Request for Proposal
Rqmt. Requirement
SBVR Semantics of Business Vocabulary and Business Rules
SDLC System Development Life Cycle
S-P-I-N Situation, Problems, Implications, Needs (analysis)
Spec. Specification
UML Unified Modeling Language
URL Universal Reference Locator
US United States of America
VLSI very large system integration
ZF Zachman Framework