WorldCOMP-2010 BenKBovée IKE4145 Enterprise Info Arch for Traceability 14-May
Enterprise Information Architecture for Traceability Ben K Bovée Principal, Patterndigm, Fairfax, Virginia, USAbstract - 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 SystemDevelopment Life Cycle (SDLC). The presented framework 1.1 Situationdepicts generic concerns at the intersection of natural humanthought processes and business perspectives; features The ZF has axes and contents which yield more basic anddifferentiating 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 theSince each discipline has related planning, monitoring and significance behind the “five Ws.” While a businessevaluating aspects to support efforts to effect its efficiency, development manager focuses on the business customers andsuch organization and supporting processes ,  are services and products they consume, a project manageromitted. focuses on the development processes, an operations manager focuses on their service and product delivery value chain andKeywords: Enterprise, Information, Traceability, Model- support processes, an analytical manager focuses on thedriven, Architecture, Framework. business concerns and appropriately prioritizing efficiency improvements to operations and information management and1 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, softwareinformation architecture, the Zachman Framework (ZF) . and systems as well as SDLC processes;The next section introduces the solution basis and • Omitting the Software perspective within Architecturecomponents. 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 includedsection 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, classifieddefinitions of central terms used, titles and URLs of managed, and utilized; and
• 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 ImplicationsThere are no known SDLCs which explicitly follow ornavigate the ZF as a validation of the methodology. Perhapsthe most noble attempt to analyze the Zachman Framework(), 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 Business1.4 Needs Process and Model Notation (BPMN ), or utilizing the Unified Modeling Language (UML ) profile extensionAn effective EIA framework would address the mechanism.aforementioned problems. The Bovée EIA (BEIA) addresseseach of the problems in the following Solution section.1.5 ApproachThe NIST trichotomy of Managerial, Operational and The following table lists parenthetical abbreviations in relatedTechnical (M-O-T) business perspectives is one of the figure elements and table entries. Goals are analogous to Usefundamental driving factor behind identifying the BEIA Case objectives.perspectives. In each of the following figures, all of the “five A Analysis/analytical O OperationsWs” depicted are a combination of relative to the system Arch. Architecture o Output(product) to be built, bought or augmented, or the manualprocesses (services) to be engineered. Dec Decision P Process F Functional (rqmt.) p Procedure2 Solution G Goal S SystemAn effective EIA would be supported by real-world i Input s Softwareexperience, proven and repeatable through empirical M Management/ managerial Scty Securityobservation of work patterns. The BEIA is empirically derived N Nonfunctional (rqmt.) T Technicalfrom personal consulting experience providing analytical andarchitectural services on programs and projects designingprocesses, and building, buying and integrating systems 2.2 Add Architecture of Software and Systemssupporting small, medium, large and very large businesses The following figure, similar to one in , depicts multiplewith distributed users, information and computing. apropos situations when the “What” from one perspective is the “Why”, “Where” or “How” to another; and when “How” is2.1 Add Analysis bridging Functional and the “When”, “What”, “Why” or “When” to another. Technical PerspectivesTraditional distribution of enterprise concerns among M-O-Tperspectives allocates managerial and operational perspectivesto business concerns, and system and software perspectives totechnical concerns. The perspective of analysts working tofacilitate all M-O-T concerns is central to the BEIA. BusinessAnalysis work includes enterprise analysis, requirementselicitation, requirements analysis, requirements managementand communication, and solution assessment and validation. System analysis is distributed across Requirements,Design and Construction disciplines . Architectureencompasses Design and Construction disciplines .
2.3 Appropriately Emphasize Business Rules 2.5 Align Work Products with PerspectivesThe following figure depicts an appropriate significance for The following figure depicts the SDLC deliverable artifactsBusiness Rules to an enterprise. and the traceability flow between them.2.4 Accommodate all Perspectives ConcernsThe analytical concerns bridge and supplement thecombination of augmented NIST (M-O-A-T) perspectives andthe dichotomy of Business and System foci. The following 2.6 Provide Depth to Encompass all Concernstable depicts the core findings from the approach including an The BEIA structure naturally accommodates and alignsidentification of the respective thought process utilized to additional views of enterprise information related to andidentify the information in the associated intersection with supplementing that in the preceding table and figures. Thereperspective. 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 ), and supporting notations Business System including NIST Integrated Computer Aided Manufacturing (ICAM) Definition for Function Modeling (IDEF0; ), the Motivat- Why Why US Department of Defense Architecture Framework (DODAF Orientat- Where(P) How(M,O) How(A) How(T) ), BPMN (), and UML (). 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 (), 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 toImplementat- How(O) How(S,s) evolve by expanding to adopt ideas from other notations or removing redundant idea diagrams and representations.
3.2 Future Work 4.2 Appendix B: BiographySome 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 UMLnotations, and others currently are not supported by any ([9)] and Semantics of Business Vocabulary and Businessnotation. No single notation supports depiction of all concepts Rules (SBVR ) standards (see  and  respectively).currently graph-able. Since the UML supports the largest setof concepts, it has the most advantageous marginal Mr. Bovée has worked on very large system integrationaugmentation to support diagramming EIA in a holistic and (VLSI) programs and projects, specializing in designs oftruly 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 livessupplements this paper. A more concise summary of these with his wife and daughter, in Virginia. Ben has a Bachelor ofpublications could make them more tractable and usable. Science in Applied Mathematics, hobbies of blacksmithing and gardening, and is pursuing dual Master of Science degreesThe identified framework is considerably more complex than in Operations Research and Statistics.Zachman, but all of the BEIA contents have beenautonomously determined to be necessary and sufficient. 4.3 Appendix C: ReferencesIndependent trials and research efforts evaluating theapproach and conclusions would support or refuse the In the following entries, publications by authors with multiplefindings. entries are differentiated by preceding bracketed text, and those with a URL Internet address (see the next section), the title is hyper-linked.4 AppendixesThis final section presents key terminology, references of  [IEEE 12207] IEEE Computer Society Standardsworks from contributing and cited authors, and abbreviations Coordinating Committee. IEEE/EIA/ISO/IEC 12207.0used in preceding sections. Standard for Information Technology – Software life cycle processes, New York NY, March 1998.4.1 Appendix A: Glossary  Project Management Institute. A Guide to the ProjectThe following define key terms. Cross-referenced terms are Management Body of Knowledge (PMBOK), ed. 3, Newtownitalicized. Square PA, 2004. Term Definition  [IBM Zachman] John Zachman. “A framework forArchitecture Organizational structure of a system.  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].  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.   David Hay. Requirements Analysis: From BusinessEnterprise 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 orTheoretical enclose fitted and joined parts.   Damker Media Group. A Guide to the Business AnalysisInformation Data, context and sharing providing clear and Book of Knowledge (BABOK) ver. 2.0, International Institute valuable meaning and value.  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  [IEEE SWEBOK] IEEE Computer Society Professional formally imposed documents.  Practices Committee. Guide to the Software EngineeringSystem A collection of components organized to accomplish Body of Knowledge (SWEBOK), New York NY, 2004. one or more specific functions. Traceability The degree to which a relationship can be established  [IBM RUP] Ivar Jacobsen, Grady Booch, James between two or more [system requirements] ... Rumbaugh. Rational Unified Process (RUP), IBM Rational [validating] its [existence].  Software Corporation, 1987.
 [OMG BPMN] Object Management Group. BusinessProcess Model and Notation (BPMN) ver. 1.2, 3 January  www.unipi.gr/akad_tmhm/biom_dioik_tech/files/pmbok.2009. pdf (not latest version) [OMG UML] Object Management Group. Unified  www.zachmaninternational.com/images/stories/ibmsj 2603e.pdfModeling Language Superstructure (UML) ver. 2.2, 2February 2009.  www.amazon.com/Requirements-Analysis-Business-Views -Architecture/dp/0130282286/ref=sr_1_3?ie=UTF8&s=books [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.  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) Office of Management and Budget. Federal EnterpriseArchitecture Consolidated Reference Model (FEA CRM) ver.  www.computer.org/portal/web/swebok2.3, October 2007.  www.rhjconsulting.com/rationalunifiedprocess/artifact/ National Institutes of Standards and Technology. ovu_arts.htm (incomplete)Federal Information Processing Standard 183: IntegrationDefinition for Function Modeling (IDEF0), 21 December  www.omg.org/spec/BPMN/1.2/PDF/1993.  www.omg.org/spec/UML/2.2/Superstructure/PDF/ Department of Defense Deputy CIO. Department ofDefense Architecture Framework (DODAF) ver. 2.0.  http://www.whitehouse.gov/omb/assets/fea_docs/FEA _CRM_v23_Final_Oct_2007_Revised.pdf [IEEE 610] IEEE Computer Society StandardsCoordinating Committee, IEEE Standard 610.12: Glossary of  www.itl.nist.gov/fipspubs/withdraw.htm (obsoleteSoftware Engineering Terminology , New York NY, 11 standard)September 2002.  cio-nii.defense.gov/sites/dodaf20/products/DoDAF_2-0_ Websters Dictionary. web.pdf Suzanne Acar. US Federal Enterprise Architecture Data  www.idi.ntnu.no/grupper/su/publ/ese/ieee-se-glossary-Reference Model (DRM), 20 September 2006. 610. 12-1990.pdf [OMG SBVR] Object Management Group. Semantics  http://dictionary.reference.com/of Business Vocabulary and Business Rules (SBVR) ver. 1.0,January 2008.  www.whitehouse.gov/omb/assets/egov_docs/DRM_2_0_ Final.pdf, www.dbq.or.kr/conference/2006/pdf/Harmony1_02 [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 RFIResponse,” Object Management Group, November 1999.  www.omg.org/spec/SBVR/1.0/PDF/ [OMG Bovée 2004] Ben Bovée. “Proposed BusinessRule Semantics, Notations and Management Practices (Meta- 4.5 Appendix E: AbbreviationsRules): 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 the4.4 Appendix D: Reference URLs Glossary, cross-referenced entries are italicized.The following (starting with, “http://”) are on-line, free (fordownload), complete and current unless otherwise noted as of Abbrev. Representspublication. References without a URL are commercial, BEIA Bovée EIAlicensed ,or archived by standards commitee. BR Business Rule www.saiglobal.com/PDFTemp/Previews/OSH/iso/updates CIO Chief Information Officer, DOD2008/wk13/ISO-IEC_12207-2008.PDF, http://www.ieee.org/ CRM Consolidated Reference Model, FEApublications_standards/index.html#IEEE_Standards (for sale)
Abbrev. RepresentsDOD Department of Defense, USDODAF DOD Architecture FrameworkEIA Enterprise Information ArchitectureFEA Federal Enterprise Architecture, OMBFIPS Federal Information Processing Standard, NISTFive Ws Who, What, Where, When, Why and HowICAM Integrated Computer Aided ManufacturingIDEF ICAM Definition, FIPSIDEF0 IDEF for Function ModelingM-O-A-T managerial, operational, analytical, technical (perspectives)M-O-T managerial, operational, technical (perspectives), NISTNIST National Institutes of Standards & Technology, USOMB Office of Management and Budget, USPerform. PerformanceRFI Request for InformationRFP Request for ProposalRqmt. RequirementSBVR Semantics of Business Vocabulary and Business RulesSDLC System Development Life CycleS-P-I-N Situation, Problems, Implications, Needs (analysis)Spec. SpecificationUML Unified Modeling LanguageURL Universal Reference LocatorUS United States of AmericaVLSI very large system integrationZF Zachman Framework