19 January 2017

🚧Project Management: Product Lifecycle (Definitions)

"The period of time, consisting of phases, that begins when a product is conceived and ends when the product is no longer available for use. Since an organization may be producing multiple products for multiple customers, one description of a product life cycle may not be adequate. Therefore, the organization may define a set of approved product life-cycle models. These models are typically found in published literature and are likely to be tailored for use in an organization. A product life cycle could consist of the following phases: (1) concept/vision, (2) feasibility, (3) design/development, (4) production, and (5) phase out." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"The period of time that begins when a product is conceived and ends when the product is no longer available for use. This cycle typically includes phases for concept definition (verifies feasibility), full-scale development (builds and optionally installs the initial version of the system), production (manufactures copies of the first article), transition (transfers the responsibility for product upkeep to another organization), operation and sustainment (repairs and enhances the product), and retirement (removes the product from service). Full-scale development may be divided into subphases to facilitate planning and management such as requirements analysis, design, implementation, integration and test, installation and checkout." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"A term to describe a product, from its conception to its discontinuance and ultimate market withdrawal." (Steven Haines, "The Product Manager's Desk Reference", 2008)

"a model of the sales and profits of a product category from its introduction until its decline and disappearance from the market; focuses on the appropriate strategies at each stage." (Gina C O'Connor & V K Narayanan, "Encyclopedia of Technology and Innovation Management", 2010)

"A collection of generally sequential, non-overlapping product phases whose name and number are determined by the manufacturing and control needs of the organization. The last product life cycle phase for a product is generally the product's retirement. Generally, a project life cycle is contained within one or more product life cycles." (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies®", 2011)

"The series of phases that represent the evolution of a product, from concept through delivery, growth, maturity, and to retirement." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

18 January 2017

⛏️Data Management: Business Rules (Definitions)

"A statement expressing a policy or condition that governs business actions and establishes data integrity guidelines." (Larry P English, "Improving Data Warehouse and Business Information Quality", 1999)

"An organizational standard operating procedure that requires that certain policies be followed to ensure that a business is run correctly. Business rules ensure that the database maintains its accuracy with business policies."  (Microsoft Corporation, "Microsoft SQL Server 7.0 System Administration Training Kit", 1999)

"[…] a business rule is a compact statement about an aspect of a business. The rule can be expressed in terms that can be directly related to the business, using simple, unambiguous language that's accessible to all interested parties: business owner, business analyst, technical architect, and so on." (Tony Morgan, "Business Rules and Information Systems", 2002) 

"the set of conditions that govern a business event so that it occurs in a way that is acceptable to the business." (Barbara von Halle, 2002)

"The logical rules that are used to run a business." (Anthony Sequeira & Brian Alderman, "The SQL Server 2000 Book", 2003)

"A set of methods or guidelines associated with a company’s data and business processing that reflect its methods of conducting business operations." (Jill Dyché & Evan Levy, "Customer Data Integration" , 2006)

"A statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business." (Alex Berson & Lawrence Dubov, "Master Data Management and Customer Data Integration for a Global Enterprise", 2007)

"Business-specific rule that constrains the data." (Rod Stephens, "Beginning Database Design Solutions", 2008)

"The defined operations and constraints that help organizations create a data environment that promotes efficient operations and decision making. An example of a business rule for a hospital would be that no male patient can be marked pregnant. Organizations typically have thousands of business rules, but not all facets of the same organizations follow all of them, and, in some cases, the rules can conflict." (Tony Fisher, "The Data Asset", 2009)

"Either a set of conditions, a directive, or an 'element of guidance'. A constraint on a business’s behavior. There is not yet an industry standard definition of business rule although authors seem to be converging." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"A directive, intended to govern, guide or influence business behavior, in support of a business policy that has been formulated in response to an opportunity, threat, strength or weakness." (The Business Rules Group, "The Business Motivation Model: Business Governance in a Volatile World", 2005)

"An element of guidance that introduces an obligation or necessity, [and] that is under business jurisdiction" (Business Rules Team, 'Semantics of Business Vocabulary and Business Rules", 2005)

"The logical rules that are used to run a business" (Microsoft)

16 January 2017

⛏️Data Management: Data Flow (Definitions)

"The sequence in which data transfer, use, and transformation are performed during the execution of a computer program."  (IEEE," IEEE Standard Glossary of Software Engineering Terminology", 1990)

"A component of a SQL Server Integration Services package that controls the flow of data within the package." (Marilyn Miller-White et al, "MCITP Administrator: Microsoft® SQL Server™ 2005 Optimization and Maintenance 70-444", 2007)

"Activities of a business process may exchange data during the execution of the process. The data flow graph of the process connects activities that exchange data and - in some notations - may also represent which input/output parameters of the activities are involved." (Cesare Pautasso, "Compiling Business Process Models into Executable Code", 2009)

"Data dependency and data movement between process steps to ensure that required data is available to a process step at execution time." (Christoph Bussler, "B2B and EAI with Business Process Management", 2009)

[logical data flow:] "A data flow diagram that describes the flow of information in an enterprise without regard to any mechanisms that might be required to support that flow." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

[physical data flow:] "A data flow diagram that identifies and represents data flows and processes in terms of the mechanisms currently used to carry them out." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"The fact that data, in the form of a virtual entity class, can be sent from a party, position, external entity, or system process to a party, position, external entity, or system process." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"An abstract representation of the sequence and possible changes of the state of data objects, where the state of an object is any of: creation, usage, or destruction [Beizer]." (International Qualifications Board for Business Analysis, "Standard glossary of terms used in Software Engineering", 2011)

"Data flow refers to the movement of data from one purpose to another; also the movement of data through a set of systems, or through a set of transformations within one system; it is a nontechnical description of how data is processed. See also Data Chain." (Laura Sebastian-Coleman, "Measuring Data Quality for Ongoing Improvement ", 2012)

"The movement of data through a group of connected elements that extract, transform, and load data." (Microsoft, "SQL Server 2012 Glossary", 2012)

"A path that carries packets of information of known composition; a roadway for data. Every data flow’s composition is recorded in the data dictionary." (James Robertson et al, "Complete Systems Analysis: The Workbook, the Textbook, the Answers", 2013)

"the path, in information systems or otherwise, through which data move during the active phase of a study." (Meredith Zozus, "The Data Book: Collection and Management of Research Data", 2017)

"The lifecycle movement and storage of data assets along business process networks, including creation and collection from external sources, movement within and between internal business units, and departure through disposal, archiving, or as products or other outputs." (Kevin J Sweeney, "Re-Imagining Data Governance", 2018)

"A graphical model that defines activities that extract data from flat files or relational tables, transform the data, and load it into a data warehouse, data mart, or staging table." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

"An abstract representation of the sequence and possible changes of the state of data objects, where the state of an object is any of: creation, usage, or destruction." (Software Quality Assurance)

⛏️Data Management: Data Quality Management [DQM] (Definitions)

[Total Data Quality Management:] "An approach that manages data proactively as the outcome of a process, a valuable asset rather than the traditional view of data as an incidental by-product." (Karolyn Kerr, "Improving Data Quality in Health Care", 2009)

"The application of total quality management concepts and practices to improve data and information quality, including setting data quality policies and guidelines, data quality measurement (including data quality auditing and certification), data quality analysis, data cleansing and correction, data quality process improvement, and data quality education." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"Data Quality Management (DQM) is about employing processes, methods, and technologies to ensure the quality of the data meets specific business requirements." (Mark Allen & Dalton Cervo, "Strategy, Scope, and Approach" [in "Multi-Domain Master Data Management"], 2015)

"DQM is the management of company data in a manner aware of quality. It is a sub-function of data management and analyzes, improves and assures the quality of data in the company. DQM includes all activities, procedures and systems to achieve the data quality required by the business strategy. Among other things, DQM transfers approaches for the management of quality for physical goods to immaterial goods like data." (Boris Otto & Hubert Österle, "Corporate Data Quality", 2015)

"Data quality management (DQM) is a set of practices aimed at improving and maintaining the quality of data across a company’s business units." (altexsoft) [source]

"Data quality management is a set of practices that aim at maintaining a high quality of information. DQM goes all the way from the acquisition of data and the implementation of advanced data processes, to an effective distribution of data. It also requires a managerial oversight of the information you have." (Data Pine) [source]

"Data quality management is a setup process, which is aimed at achieving and maintaining high data quality. Its main stages involve the definition of data quality thresholds and rules, data quality assessment, data quality issues resolution, data monitoring and control." (ScienceSoft) [source]

"Data quality management is the act of ensuring suitable data quality." (Xplenty) [source]

"Data quality management provides a context-specific process for improving the fitness of data that’s used for analysis and decision making. The goal is to create insights into the health of that data using various processes and technologies on increasingly bigger and more complex data sets." (SAS) [source]

"Data quality management (DQM) refers to a business principle that requires a combination of the right people, processes and technologies all with the common goal of improving the measures of data quality that matter most to an enterprise organization." (BMC) [source]

"Put most simply, data quality management is the process of reviewing and updating your customer data to minimize inaccuracies and eliminate redundancies, such as duplicate customer records and duplicate mailings to the same address." (EDQ) [source]

12 January 2017

⛏️Data Management: Reference Data (Definitions)

"Reference data is focused on defining and distributing collections of common values to support accurate and efficient processing of operational and analytical activities." (Martin Oberhofer et al, "Enterprise Master Data Management", 2008)

"Sets of values or classification schemas referred to by systems, applications, data stores, processes, and reports, as well as by transactional and master records. Examples include lists of valid values, code lists, status codes, flags, product types, charts of accounts, product hierarchy." (Danette McGilvray, "Executing Data Quality Projects", 2008)

"Data that describe the infrastructure of an enterprise. These comprise the 'type' entity classes that provide lists of values for other attributes." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"Data characterized by shared read operations and infrequent changes. Examples of reference data include flight schedules and product catalogs. Windows Server AppFabric offers the local cache feature for storing this type of data." (Microsoft, "SQL Server 2012 Glossary", 2012)

"Corporate data that has been defined externally and is uniformly changed across company boundaries, such as country codes, currency codes and geo-data." (Boris Otto & Hubert Österle, "Corporate Data Quality", 2015)

"Reference data is commonly used to link and give additional details to the data. It is the data used to classify, organize, or categorize other data. Reference data can also contain value hierarchies, for example, the relationships between product and geographic hierarchies. It is escorted by the discipline Reference Data Management, which makes sure the reference data is consistent and that different versions are managed and distributed properly." (Piethein Strengholt, "Data Management at Scale", 2020)

⛏️Data Management: Data Lifecycle (Definitions)

"The data life cycle is the set of processes a dataset goes through from its origin through its use(s) to its retirement. Data that moves through multiple systems and multiple uses has a complex life cycle." (Laura Sebastian-Coleman, "Measuring Data Quality for Ongoing Improvement ", 2012)

"The recognition that as data ages, that data takes on different characteristics" (Daniel Linstedt & W H Inmon, "Data Architecture: A Primer for the Data Scientist", 2014)

"The development of a record in the company’s IT systems from its creation until its deletion. This process may also be designated as “CRUD”, an acronym for the Create, Read/Retrieve, Update and Delete database operations." (Boris Otto & Hubert Österle, "Corporate Data Quality", 2015)

"The series of stages that data moves though from initiation, to creation, to destruction. Example: the data life cycle of customer data has four distinct phases and lasts approximately eight years." (Gregory Lampshire, "The Data and Analytics Playbook", 2016)

10 January 2017

⛏️Data Management: Metadata (Definitions)

"Data about data. That is, information about the properties of data, such as the type of data in a column (numeric, text, and so on) or the length of a column, information about the structure of data, or information that specifies the design of objects such as cubes or dimensions. Metadata is an important aspect of SQL Server, Data Transformation Services, and OLAP Services." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"'Data about data' - for example, all information in the data dictionary." (Bill Pribyl & Steven Feuerstein, "Learning Oracle PL/SQL", 2001)

"Any data maintained to support the operations or use of a data warehouse, similar to an encyclopedia for the data warehouse. Nearly all data staging and access tools require some private meta data in the form of specifications or status. There are few coherent standards for meta data viewed in a broader sense. Distinguished from the primary data in the dimension and fact tables." (Ralph Kimball & Margy Ross, "The Data Warehouse Toolkit 2nd Ed ", 2002)

"Data (or information) about data. In the CLR, metadata is used to describe assemblies and types. It is stored with them in the executable files, and is used by compilers, tools, and the runtime system to provide a wide range of services. Metadata is essential for runtime type information and dynamic method invocation. Many architectures/systems use metadata - for example, type libraries in COM provide metadata." (Damien Watkins et al, "Programming in the .NET Environment", 2002)

"Generally described as data about data. It is the data, beyond the data, describing the context in which the data resides." (William A Giovinazzo, "Internet-Enabled Business Intelligence", 2002)

"Information inside an assembly that describes its types. Metadata is required by .NET compilers for binding, required by the CLR for many of its services, and used by object browsers and IntelliSense to provide a rich programming experience. Metadata is the .NET version of COM type information (as found in a type library), but much more expressive." (Adam Nathan, ".NET and COM: The Complete Interoperability Guide", 2002)

"Information about the properties of data, such as the type of data in a column (numeric, text, and so on) or the length of a column." (Anthony Sequeira & Brian Alderman, "The SQL Server 2000 Book", 2003)

"(1) data about data; (2) the description of the structure, content, keys, indexes, and so forth, of data." (William H Inmon, "Building the Data Warehouse", 2005)

"Information about the properties of data, such as the type of data in a column (numeric, text, and so on) or the length of a column. It can also be information about the structure of data or information that specifies the design of objects, such as cubes or dimensions." (Thomas Moore, "EXAM CRAM™ 2: Designing and Implementing Databases with SQL Server 2000 Enterprise Edition", 2005)

"Literally, data about data. Metadata includes data associated with either an information system or an information object for description, administration, legal requirements, technical functionality, use, and preservation. Business metadata includes business names and unambiguous definitions of the data including examples and business rules for the data. Technical metadata is information about column width, data types, and other technical information that would be useful to a programmer or database administrator (DBA)." (Sharon Allen & Evan Terry, "Beginning Relational Data Modeling 2nd Ed.", 2005)

"Data which provides context or otherwise describes information in order to make it more valuable (e.g., more easily retrievable or maintainable); data about data." (Martin J Eppler, "Managing Information Quality" 2nd Ed., 2006)

"Information about how data is stored and structured as well as what the data means." (Reed Jacobsen & Stacia Misner, "Microsoft SQL Server 2005 Analysis Services Step by Step", 2006)

"Information about the properties of data, such as the type of data in a column (numeric, text, and so on) or the length of a column. Metadata can also be information about the structure of data or information that specifies the design of objects, such as cubes or dimensions." (Thomas Moore, "MCTS 70-431: Implementing and Maintaining Microsoft SQL Server 2005", 2006)

"Metadata usually refers to definitions and business rules that have been agreed on and stored in a centralized repository so that the business users - even those across departments and systems - use common terminology for key business terms. Metadata can include information about data’s currency, ownership, source system, derivation (e.g., profit = revenues minus costs), or usage rules. " (Jill Dyché & Evan Levy, "Customer Data Integration: Reaching a Single Version of the Truth", 2006)

"The tables and the fields defining the structure of the data; the data about the data." (Gavin Powell, "Beginning Database Design", 2006)

"(1) Data about data; (2) the description of the structure, content, keys, and indexes of data." (William H Inmon & Anthony Nesavich, "Tapping into Unstructured Data", 2007)

"Data about data is meta data. In other words, metadata is the data about the structure of the data in a database." (S. Sumathi & S. Esakkirajan, "Fundamentals of Relational Database Management Systems", 2007)

"All the information that defines and describes the structures, operations, and contents of the DW/BI system. We identify three types of metadata in the DW/BI system: technical, business, and process." (Ralph Kimball, "The Data Warehouse Lifecycle Toolkit", 2008) 

"Data about data that label, describe, or characterize other data, and make it easier to retrieve, interpret, or use information. Major types include technical, business, and audit trail metadata. (See the definitions for the individual types.)" (Danette McGilvray, "Executing Data Quality Projects", 2008)

"Data about the database such as table names, column names, column data types, column lengths, keys, and indexes. Some relational databases allow you to query tables that contain the database's metadata." (Rod Stephens, "Beginning Database Design Solutions", 2008)

"In general terms, we will use the term metadata for descriptive information that is useful for people or systems to understand something. Common examples include a database catalog or an XML schema, both of which describe the structure of data." (Martin Oberhofer et al, "Enterprise Master Data Management", 2008)

"Data about the organization’s data, found in every data source throughout the enterprise. Metadata describes the information in these data resources. Metadata can be technical, describing the physical characteristics of the data, or it can be business-oriented, describing the way the data represents the needs of the business." (Tony Fisher, "The Data Asset", 2009)

"May be regarded as a subset of data, and are data about data. Metadata summarise data content, context, structure, inter-relationships, and provenance (information on history and origins). They add relevance and purpose to data, and enable the identification of similar data in different data collections." (Mark Olive, "SHARE: A European Healthgrid Roadmap", 2009)

"The definitions, mappings, and other characteristics used to describe how to find, access, and use the company’s data and software components." (Judith Hurwitz et al, "Service Oriented Architecture For Dummies" 2nd Ed., 2009)

"The information describing the properties, such as the type of data in a column (numeric, text, and so on), the length of a column, the structure of database objects, such as tables, measures, dimensions, and cubes, and so on." (Jim Joseph, "Microsoft SQL Server 2008 Reporting Services Unleashed", 2009)

"Data about data and data processes. Metadata is important because it aids in clarifying and finding the actual data." (David Lyle & John G Schmidt, "Lean Integration", 2010)

"Data about data and data processes. Metadata is important because it aids in clarifying and finding the actual data." (David Lyle & John G Schmidt, "Lean Integration: An Integration Factory Approach to Business Agility", 2010)

"Data about data, that is, data concerning data characteristics and relationships." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management" 9th Ed., 2011)

"Literally, ‘data about data’; data that defines and describes the characteristics of other data, used to improve both business and technical understanding of data and data-related processes." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"Way of describing data so that it can be used by a wide variety of applications." (Linda Volonino & Efraim Turban, "Information Technology for Management 8th Ed", 2011)

"Data about the data; a description or definition of the rows, columns, and/or links in a data set." (Gary Miner et al, "Practical Text Mining and Statistical Analysis for Non-structured Text Data Applications", 2012) 

"Information about the properties or structure of data that is not part of the values the data contains." (SQL Server 2012 Glossary, "Microsoft", 2012)

"Metadata is usually defined as 'data about data', but it would be better defined as explicit knowledge, documented to enable a common understanding of an organization’s data, including what the data is intended to represent (definition of terms and business rules), how it effects this representation (conventions of representation, data definition, system design, system processes), the limits of that representation (what it does not represent), what happens to it as it moves through processes and systems (provenance, lineage, information chain and information life cycle), how data is used and can be used, and how it should not be used." (Laura Sebastian-Coleman, "Measuring Data Quality for Ongoing Improvement ", 2012)

"The simplest definition of metadata is 'data about data'. To be a bit more precise, metadata describes data, providing information such as type, length, textual description, and other characteristics." (Craig S Mullins, "Database Administration: The Complete Guide to DBA Practices and Procedures 2nd Ed", 2012)

"Information stored within an assembly concerning the classes defined in that assembly (such as names and types of fields, method signatures, dependence on other classes, and so on)." (Mark Rhodes-Ousley, "Information Security: The Complete Reference, Second Edition" 2nd Ed., 2013)

"The definitions, mappings, and other characteristics used to describe how to find, access, and use the company’s data and software components." (Marcia Kaufman et al, "Big Data For Dummies", 2013)

"This term can mean a number of things depending on the context in which it is used. It can denote how a set of information is structured, such as the ISBN values assigned to books, the format of the UPC barcodes, and the Library of Congress classifications used in catalog books. It can also be a keyword assigned to a set of data to make it more easily searched for. For example, the list of keywords at the beginning of this book or the definition for hashtag used in online text message exchanges." (Kenneth A Shaw, "Integrated Management of Processes and Information", 2013)

"Data about data, or detailed information describing context, content, and structure of records and their management through time." (Robert F Smallwood, "Information Governance: Concepts, Strategies, and Best Practices", 2014)

"Descriptive data about data that is stored and managed in a database, in order to facilitate access to captured and archived data for further use." (Jim Davis & Aiman Zeid, "Business Transformation: A Roadmap for Maximizing Organizational Insights", 2014)

"The classic definition of metadata is 'data about the data'." (Daniel Linstedt & W H Inmon, "Data Architecture: A Primer for the Data Scientist", 2014)

"The definitions, mappings, and other characteristics used to describe how to find, access, and use the company’s data and software components." (Judith S Hurwitz, "Cognitive Computing and Big Data Analytics", 2015)

"Data about data, such as definitions, lists of values and access rights." (Boris Otto & Hubert Österle, "Corporate Data Quality", 2015)

"Data holding the description of other data. Meta means 'an underlying description'. Misnomer Term that suggests a wrong meaning or inappropriate name." (Hamid R Arabnia et al, "Application of Big Data for National Security", 2015)

"Artifacts of events and objects and contextual information that helps us understand the structure and meaning of data or facts. Example: the definitions of our data elements are metadata we store in the business glossary." (Gregory Lampshire, "The Data and Analytics Playbook", 2016)

"Metadata is often defined as 'data about data', a definition that is nearly as ubiquitous as it is unhelpful. A more content-full definition of metadata is that it is structured description for information resources of any kind." (Robert J Glushko, "The Discipline of Organizing: Professional Edition" 4th Ed., 2016)

"Data associated with other data that describes some important characteristics of the data to which it is bound. For example, the file length and file type associated with a file are metadata." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

"Data that describes the characteristics of data; descriptive data." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

"Metadata describes the data itself. The term metadata is often used in relation to digital media, but in today’s world it plays a vital role in the overall data strategy and architectural design. Obviously metadata is companioned with the discipline metadata data management." (Piethein Strengholt, "Data Management at Scale", 2020)

"A repository whose data associates the tables and columns of a data warehouse with user-defined attributes and facts to enable the mapping of the business view, terms, and needs to the underlying database structure. Metadata can reside on the same server as the data warehouse or on a different database server. It can even be held in a different RDBMS." (Microstrategy)

"A set of data that gives information about other data." (Insight Software)

"descriptive data about data that is stored and managed in a database, in order to facilitate access to captured and archived data for further use." (SAS)

"Information about the properties or structure of data that is not part of the values the data contains." (Microsoft)

"Information describing the characteristics of data including, for example, structural metadata describing data structures (e.g., data format, syntax, and semantics) and descriptive metadata describing data contents (e.g., information security labels)." (NIST SP 800-53)

"Metadata describes other data within a database and is responsible for organization while a business or organization sifts through data sets." (Solutions Review)

"Metadata is data that summarizes information about other data." (Logi Analytics)

"Metadata is information that describes various facets of an information asset to improve its usability throughout its life cycle. It is metadata that turns information into an asset. Generally speaking, the more valuable the information asset, the more critical it is to manage the metadata about it, because it is the metadata definition that provides the understanding that unlocks the value of data." (Gartner)

"Refers to 'data about data', such as: means of creation of the data, purpose of the data, time and date of creation, author of the data, location of the data, and standards used when created." (Board International)


03 January 2017

⛏️Data Management: Transactional Data (Definitions)

"Data about the day-to-day dynamic activities of a company, such as invoices." (Gavin Powell, "Beginning Database Design", 2006)

"Data that describe an internal or external event or transaction that takes place as an organization conducts its business. Examples include sales orders, invoices, purchase orders, shipping documents, passport applications, credit card payments, and insurance claims. Transactional data are typically grouped into transactional records, which include associated master and reference data." (Danette McGilvray, "Executing Data Quality Projects", 2008)

"The set of records of individual business activities or events." (Janice M Roehl-Anderson, "IT Best Practices for Financial Managers", 2010)

"Data related to sales, deliveries, invoices, trouble tickets, claims, and other monetary and non-monetary interactions." (Microsoft, "SQL Server 2012 Glossary", 2012)

"A type of data that gathers information about contracts, deliveries, invoices, payments and so forth and exhibits a high frequency of change. Transaction data provide a key to the activities of the core business objects." (Boris Otto & Hubert Österle, "Corporate Data Quality", 2015)

"Information stored from a time-based instance, like a bank deposit or phone call." (Jason Williamson, "Getting a Big Data Job For Dummies", 2015)

"Master data and reference data with associated time dimension." (Hamid R Arabnia et al, "Application of Big Data for National Security", 2015)


🚧Project Management: Baseline (Definitions)

 "The original approved plan for work such as a project. Usually used with a modifier, e.g., cost baseline, schedule baseline, performance measurement baseline." (Margaret Y Chu, "Blissful Data ", 2004)

"An approved plan for a project, plus or minus approved changes. It is compared to actual performance to determine if performance is within acceptable variance thresholds. Generally refers to the current baseline, but may refer to the original or some other baseline. Usually used with a modifier (e.g., cost performance baseline, schedule baseline, performance measurement baseline, technical baseline)." (Project Management Institute, "Practice Standard for Project Estimating", 2010)

"The approved version of a work product that can be changed only through formal change control procedures and is used as a basis for comparison." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"The original approved plan for a project, including approved changes. It usually includes baseline budget and baseline schedule. It is used as a benchmark for comparison with actual performance. See Project Control." (Peter Oakander et al, "CPM Scheduling for Construction: Best Practices and Guidelines", 2014)

02 January 2017

#️⃣Software Engineering: Programming (Part VII: Documentation - Lessons Learned)

Software Engineering
Software Engineering Series

Introduction


“Documentation is a love letter that you write to your future self.”
Damian Conway

    For programmers as well for other professionals who write code, documentation might seem a waste of time, an effort few are willing to make. On the other side documenting important facts can save time sometimes and provide a useful base for building own and others’ knowledge. I found sometimes on the hard way what I needed to document. With the hope that others will benefit from my experience, here are my lessons learned:

 

Lesson #1: Document your worked tasks


“The more transparent the writing, the more visible the poetry.”
Gabriel Garcia Marquez


   Personally I like to keep a list with what I worked on a daily basis – typically nothing more than 3-5 words description about the task I worked on, who requested it, and eventually the corresponding project, CR or ticket. I’m doing it because it makes easier to track my work over time, especially when I have to retrieve some piece of information that is somewhere else in detail documented.

   Within the same list one can track also the effective time worked on a task, though I find it sometimes difficult, especially when one works on several tasks simultaneously. In theory this can be used to estimate further similar work. One can use also a categorization distinguishing for example between the various types of work: design, development, maintenance, testing, etc. This approach offers finer granularity, especially in estimations, though more work is needed in tracking the time accurately. Therefore track the information that worth tracking, as long there is value in it.

   Documenting tasks offers not only easier retrieval and base for accurate estimations, but also visibility into my work, for me as well, if necessary, for others. In addition it can be a useful sensemaking tool (into my work) over time.

Lesson #2: Document your code


“Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live.”
Damian Conway

    There are split opinions over the need to document the code. There are people who advise against it, and probably one of most frequent reasons is rooted in Agile methodology. I have to stress that Agile values “working software over comprehensive documentation”, fact that doesn’t imply the total absence of documentation. There are also other reasons frequently advanced, like “there’s no need to document something that’s already self-explanatory “(like good code should be), “no time for it”, etc. Probably in each statement there is some grain of truth, especially when considering the fact that in software engineering there are so many requirements for documentation (see e.g. ISO/IEC 26513:2009).

   Without diving too deep in the subject, document what worth documenting, however this need to be regarded from a broader perspective, as might be other people who need to review, modify and manage your code.

    Documenting code doesn’t resume only to the code being part of a “deliverables”, but also to intermediary code written for testing or other activities. Personally I find it useful to save within the same fill all the scripts developed within same day. When some piece of code has a “definitive” character then I save it individually for reuse or faster retrieval, typically with a meaningful name that facilitates file’s retrieval. With the code it helps maybe to provide also some metadata like: a short description and purpose (who and when requested it).

   Code versioning can be used as a tool in facilitating the process, though not everything worth versioning.

 

Lesson #3: Document all issues as well the steps used for troubleshooting and fixing


“It’s not an adventure until something goes wrong.”
Yvon Chouinard

   Independently of the types of errors occurring while developing or troubleshooting code, one of the common characteristics is that the errors can have a recurring character. Therefore I found it useful to document all the errors I got in terms of screenshots, ways to fix them (including workarounds) and, sometimes also the steps followed in order to troubleshoot the problem.

   Considering that the issues are rooted in programming fallacies or undocumented issues, there is almost always something to learn from own as well from others’ errors. In fact, that was the reasons why I started the “SQL Troubles” blog – as a way to document some of the issues I met, to provide others some help, and why not, to get some feedback.

 

Lesson #4: Document software installations and changes in configurations


   At least for me this lesson is rooted in the fact that years back quite often release candidate as well final software was not that easy to install, having to deal with various installation errors rooted in OS or components incompatibilities, invalid/not set permissions, or unexpected presumptions made by the vendor (e.g. default settings). Over the years installation became smoother, though such issues are still occurring. Documenting the installation in terms of screenshots with the setup settings allows repeating the steps later. It can also provide a base for further troubleshooting when the configuration within the software changed or as evidence when something goes wrong.


   Talking about changes occurring in the environment, not often I found myself troubleshooting something that stopped working, following to discover that something changed in the environment. It’s useful to document the changes occurring in an environment, importance stressed also in “Configuration Management” section of ITIL® (Information Technology Infrastructure Library).

 

Lesson #5: Document your processes


“Verba volant, scripta manent.” Latin proverb
"Spoken words fly away, written words remain."

    In process-oriented organizations one has the expectation that the processes are documented. One can find that it’s not always the case, some organization relying on the common or individual knowledge about the various processes. Or it might happen that the processes aren’t always documented to the level of detail needed. What one can do is to document the processes from his perspective, to the level of detail needed.

 

Lesson #6: Document your presumptions


“Presumption first blinds a man, then sets him a running.”
Benjamin Franklin

   Probably this is more a Project Management related topic, though I find it useful also when coding: define upfront your presumptions/expectations – where should libraries lie, the type and format of content, files’ structure, output, and so on. Even if a piece of software is expected to be a black-box with input and outputs, at least the input, output and expectations about the environment need to be specified upfront.

 

Lesson #7: Document your learning sources


“Intelligence is not the ability to store information, but to know where to find it.”
Albert Einstein

    Computer specialists are heavily dependent on internet to keep up with the advances in the field, best practices, methodologies, techniques, myths, and other knowledge. Even if one learns something, over time the degree of retention varies, and it can decrease significantly if it wasn’t used for a long time. Nowadays with a quick search on internet one can find (almost) everything, though the content available varies in quality and coverage, and it might be difficult to find the same piece of information. Therefore, independently of the type of source used for learning, I found it useful to document also the information sources.

 

Lesson #8: Document the known as well the unknown

 

“A genius without a roadmap will get lost in any country but an average person
with a roadmap will find their way to any destination.”
Brian Tracy

   Over the years I found it useful to map and structure the learned content for further review, sometimes considering only key information about the subject like definitions, applicability, limitations, or best practices, while other times I provided also a level of depth that allow me and others to memorize and understand the topic. As part of the process I attempted to keep the  copyright attributions, just in case I need to refer to the source later. Together with what I learned I considered also the subjects that I still have to learn and review for further understanding. This provides a good way to map what I known as well what isn’t know. One can use for this a rich text editor or knowledge mapping tools like mind mapping or concept mapping.


Conclusion


    Documentation doesn’t resume only to pieces of code or software but also to knowledge one acquires, its sources, what it takes to troubleshoot the various types of issues, and the work performed on a daily basis. Documenting all these areas of focus should be done based on the principle: “document everything that worth documenting”.



⛏️Data Management: Information (Definitions)

"Information is data that increases the knowledge of the person who consumes it. Information is distinguished from data in that data may or may not be meaningful whereas information is always meaningful. For example, the numeric portion of an address is data, but it is not information." (Microsoft Corporation, "Microsoft SQL Server 7.0 Data Warehouse Training Kit", 2000)

"Usable, processed data, typically output from a computer program." (Greg Perry, "Sams Teach Yourself Beginning Programming in 24 Hours" 2nd Ed., 2001)

"Data that has been processed in such a way that it can increase the knowledge of the person who receives it." (Sharon Allen & Evan Terry, "Beginning Relational Data Modeling" 2nd Ed., 2005)

"data that human beings assimilate and evaluate to solve a problem or make a decision." (William H Inmon, "Building the Data Warehouse", 2005)

"Information is data with context. It can be externally validated and is independent of applications." (Tom Petrocelli, "Data Protection and Information Lifecycle Management", 2005)

"Information can be defined as all inputs that people process to gain understanding." (Martin J Eppler, "Managing Information Quality" 2nd Ed., 2006)

"Sets of data presented in a context. Information about a business and its environment." (Steve Williams & Nancy Williams, "The Profit Impact of Business Intelligence", 2007)

"1.Generally, understanding concerning any objects such as facts, events, things, processes, or ideas, including concepts that, within a certain context and timeframe, have a particular meaning." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"Data that have been organized so they have meaning and value to the recipient." (Linda Volonino & Efraim Turban, "Information Technology for Management" 8th Ed, 2011)

"Refers to all or part of a raw data item, which, on examination, turns out to be of interest. Such interest can be justified by means of explicit criteria. Also denotes an observation conducted in the field." (Humbert Lesca & Nicolas Lesca, "Weak Signals for Strategic Intelligence: Anticipation Tool for Managers", 2011)

"The result of processing raw data to reveal its meaning. Information consists of transformed data and facilitates decision making." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management 9th Ed", 2011)

"Data with additional context in the form of metadata, including definition and relationships between data and possibly other information. Data in context with metadata makes information." (Craig S Mullins, "Database Administration", 2012)

"In the context of this book, a collection of descriptors derived from observation, measurement, calculation, inference, or imagination in a form that can be shared with or communicated to others, or both. The format can be tangible or intangible or some combination of both." (Kenneth A Shaw, "Integrated Management of Processes and Information", 2013)

"An organised and formatted collection of data" (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"Any communication on or representation of facts or data in all forms (textual, graphical, audiovisual, digital)." (Gilbert Raymond & Philippe Desfray, "Modeling Enterprise Architecture with TOGAF", 2014)

"Data that has been organized or processed in a useful manner" (Nell Dale & John Lewis, "Computer Science Illuminated" 6th Ed., 2015)

"One view understands information to be content- and purpose- specific knowledge, which is exchanged during human communication. Another takes the view of a purely informational processing perspective, according to which data is the building blocks for information. Accordingly, data is processed into information." (Boris Otto & Hubert Österle, "Corporate Data Quality", 2015)

"Data that has been processed to create meaning. Information is intended to expand the knowledge of the person who receives it. Information is the output of decision support systems and information systems." (Ciara Heavin & Daniel J Power, "Decision Support, Analytics, and Business Intelligence 3rd Ed.", 2017)

"Organized or structured data, processed for a specific purpose to make it meaningful, valuable, and useful in specific contexts." (Project Management Institute, "A Guide to the Project Management Body of Knowledge (PMBOK® Guide)", 2017)

"A structured collection of data presented in a form that people can understand and process. Information is converted into knowledge when it is contextualised with the rest of a person’s knowledge and world model." (Open Data Handbook)

31 December 2016

♟️Strategic Management: The Art of War (Just the Quotes)

Disclaimer: The following quotes were consider only in respect to people's understanding about strategy and tactics over time, as best exemplification for understanding the difference between the two concepts.

"What is of supreme importance in war is to attack the enemy's strategy." (Sun Tzu, "The Art of War", 5th century BC)

"Thus those skilled in war subdue the enemy's army without battle. [...] They conquer by strategy." (Sun Tzu, The Art of War, 5th century BC)

"The peak efficiency of knowledge and strategy is to make conflict unnecessary."(Sun Tzu, The Art of War, 5th century BC)

"In warfare, there are no constant conditions. He who can modify his tactics in relation to his opponent will succeed and win." (Sun Tzu, The Art of War, 5th century BC)

"All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved." (Sun Tzu, The Art of War, 5th century BC)

"When conventional tactics are altered unexpectedly according to the situation, they take on the element of surprise and increase in strategic value." (Sun Bin, Art of War, cca 4th century BC)

"Everything can collapse. Houses, bodies, and enemies collapse when their rhythm becomes deranged. [...] In large-scale strategy, when the enemy starts to collapse you must pursue him without letting the chance go. If you fail to take advantage of your enemies' collapse, they may recover." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"In strategy it is important to see distant things as if they were close and to take a distanced view of close things. It is important in strategy to know the enemy's sword and not to be distracted by insignificant movements of his sword. You must study this. The gaze is the same for single combat and for large-scale combat." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"In all forms of strategy, it is necessary to maintain the combat stance in everyday life and to make your everyday stance your combat stance. You must research this well." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"In contests of strategy it is bad to be led about by the enemy. You must always be able to lead the enemy about." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"In strategy your spiritual bearing must not be any different from normal. Both in fighting and in everyday life you should be determined though calm. Meet the situation without tenseness yet not recklessly, your spirit settled yet unbiased. Even when your spirit is calm do not let your body relax, and when your body is relaxed do not let your spirit slacken." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"In large-scale strategy, it is beneficial to strike at the corners of the enemy's force, If the corners are overthrown, the spirit of the whole body will be overthrown." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"Many things can cause a loss of balance. One cause is danger, another is hardship, and another is surprise. You must research this.
In large-scale strategy it is important to cause loss of balance. Attack without warning where the enemy is not expecting it, and while his spirit is undecided follow up your advantage and, having the lead, defeat him." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"Speed is not part of the true Way of strategy. Speed implies that things seem fast or slow, according to whether or not they are in rhythm. Whatever the Way, the master of strategy does not appear fast." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"Strategy is different from other things in that if you mistake the Way even a little you will become bewildered and fall into bad ways." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"There is timing in everything. Timing in strategy cannot be mastered without a great deal of practice." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"The important thing in strategy is to suppress the enemy's useful actions but allow his useless actions." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"The principles of strategy are written down here in terms of single combat, but you must think broadly so that you attain an understanding for ten-thousand-a-side battles." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"The wisdom of strategy is different from other things. On the battlefield, even when you are hard-pressed, you should ceaselessly research the principles of strategy so that you can develop a steady spirit." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"There is timing in the whole life of the warrior, in his thriving and declining, in his harmony and discord. Similarly, there is timing in the Way of the merchant, in the rise and fall of capital. All things entail rising and falling timing. You must be able to discern this. In strategy there are various timing considerations. From the outset you must know the applicable timing and the inapplicable timing, and from among the large and small things and the fast and slow timings find the relevant timing, first seeing the distance timing and the background timing. This is the main thing in strategy. It is especially important to know the background timing, otherwise your strategy will become uncertain." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"To attain the Way of strategy as a warrior you must study fully other martial arts and not deviate even a little from the Way of the warrior. With your spirit settled, accumulate practice day by day, and hour by hour. Polish the twofold spirit heart and mind, and sharpen the twofold gaze perception and sight. When your spirit is not in the least clouded, when the clouds of bewilderment clear away, there is the true void." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"'To move the shade' is used when you cannot see the enemy's spirit.
In large-scale strategy, when you cannot see the enemy's position, indicate that you are about to attack strongly, to discover his resources. It is easy then to defeat hin with a different method once you see his resources." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"When you have attained the way of strategy there will be nothing that you cannot understand. You will see the way in everything." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"With your spirit open and unconstricted, look at things from a high point of view. You must cultivate your wisdom and spirit. Polish your wisdom: learn public justice, distinguish between good and evil, study the Ways of different arts one by one. When you cannot be deceived by men you will have realised the wisdom of strategy." (Miyamoto Musashi, "Go Rin No Sho" ["The Book of Five Rings"], 1645)

"According to our classification, then, tactics teaches the use of armed forces in the engagement; strategy, the use of engagements for the object of the war." (Carl von Clausewitz, "On War", 1832)

"But when one comes to the effect of the engagement, where material successes turn into motives for further action, the intellect alone is decisive. In brief, tactics will present far fewer difficulties to the theorist than will strategy." (Carl von Clausewitz, "On War", 1832)

"In a tactical situation one is able to see at least half the problem with the naked eye, whereas in strategy everything has to be guessed at and presumed." (Carl von Clausewitz, "On War", 1832)

"Many readers no doubt will consider it superfluous to make such a careful distinction between two things so closely related as tactics and strategy, because they do not directly affect the conduct of operations. Admittedly only the rankest pedant would expect theoretical distinctions to show direct results on the battlefield." (Carl von Clausewitz, "On War", 1832)

"Tactics and strategy are two activities that permeate one another in time and space but are nevertheless essentially different. Their inherent laws and mutual relationship cannot be understood without a total comprehension of both." (Carl von Clausewitz, "On War", 1832)

"The art of war in the narrower sense must now in its turn be broken down into tactics and strategy. The first is concerned with the form of the individual engagement, the second with its use. Both affect the conduct of marches, camps, and billets only through the engagement; they become tactical or strategic questions insofar as they concern either the engagement’s form or its significance. (Carl von Clausewitz, "On War", 1832)

"The conduct of war, then, consists in the planning and conduct of fighting. If fighting consisted of a single act, no further subdivision would be needed. However, it consists of a greater or lesser number of single acts, each complete in itself, which [...] are called ‘engagements’ and which form new entities. This gives rise to the completely different activity of planning and executing these engagements themselves, and of coordinating each of them with the others in order to further the object of the war. One has been called tactics, and the other strategy." (Carl von Clausewitz, "On War", 1832)

"The distinction between tactics and strategy is now almost universal, and everyone knows fairly well where each particular factor belongs without clearly understanding why. Whenever such categories are blindly used, there must be a deep-seated reason for it. We have tried to discover the distinction, and have to say that it was just this common usage that led to it. We reject, on the other hand, the artificial definitions of certain writers, since they find no reflection in general usage." (Carl von Clausewitz, "On War", 1832)

"The theory of major operations (strategy, as it is called) presents extraordinary difficulties, and it is fair to say that very few people have clear ideas about its details - that is, ideas which logically derive from basic necessities." (Carl von Clausewitz, "On War", 1832)

"We have divided the conduct of war into the two fields of tactics and strategy. The theory of the latter, as we have already stated, will unquestionably encounter the greater problems since the former is virtually limited to material factors, whereas for strategic theory, dealing as it does with ends which bear directly on the restoration of peace, the range of possibilities is unlimited. As these ends will have to be considered primarily by the commander-in-chief, the problems mainly arise in those fields that lie within his competence. In the field of strategy, therefore, even more than in tactics, theory will be content with the simple consideration of material and psychological factors, especially where it embraces the highest of achievements." (Carl von Clausewitz, "On War", 1832)

"Such cases also occur in strategy, since strategy is directly linked to tactical action. In strategy too decisions must often be based on direct observation, on uncertain reports arriving hour by hour and day by day, and finally on the actual outcome of battles. It is thus an essential condition of strategic leadership that forces should be held in reserve according to the degree of strategic uncertainty." (Carl von Clausewitz, "On War", 1832)

"Thus, while a tactical reserve is a means not only of meeting any unforeseen manoeuvre by the enemy but also of reversing the unpredictable outcome of combat when this becomes necessary, strategy must renounce this means, at least so far as the overall decision is concerned. Setbacks in one area can, as a rule, be offset only by achieving gains elsewhere, and in a few cases by transferring troops from one area to another. Never must it occur to a strategist to deal with such a setback by holding forces in reserve." (Carl von Clausewitz, "On War", 1832)

"As regards tactics, the principal thing to be attended to is the choice of the most suitable order of battle for the object in view. When we come to consider the action of masses on the field, the means to be used may be an opportune charge of cavalry, a strong battery put in position and unmasked at the proper moment, a column of infantry making a headlong charge, or a deployed division coolly and steadily pouring upon the enemy a fire, or they may consist of tactical maneuvers intended to threaten the enemy’s flanks or rear, or any other maneuver calculated to diminish the confidence of the adversary. Each of these things may, in a particular case, be the cause of victory. To define the cases in which each should be preferred is simply impossible." (Antoine-Henri Jomini, "The Art of War", 1838)

"Every strategic line of defense should always possess a tactical point upon which to rally for defense should the enemy cross the strategic front. (Antoine-Henri Jomini, "The Art of War", 1838)

"Grand tactics is the art of making good combinations preliminary to battles, as well as during their progress. The guiding principle in tactical combinations, as in those of strategy, is to bring the mass of the force in hand against a part of the opposing army, and upon that point the possession of which promises the most important results. (Antoine-Henri Jomini, "The Art of War", 1838)

"Strategy, or the art of properly directing masses upon the theater of war, either for defense or for invasion. […] Strategy is the art of making war upon the map, and comprehends the whole theater of operations. Grand Tactics is the art of posting troops upon the battle-field according to the accidents of the ground, of bringing them into action, and the art of fighting upon the ground, in contradistinction to planning upon a map. Its operations may extend over a field of ten or twelve miles in extent. Logistics comprises the means and arrangements which work out the plans of strategy and tactics. Strategy decides where to act; logistics brings the troops to this point; grand tactics decides the manner of execution and the employment of the troops." (Antoine-Henri Jomini, "The Art of War", 1838)

"Strategy embraces the following points, viz.:– 
1. The selection of the theater of war, and the discussion of the different combinations of which it admits.
2. The determination of the decisive points in these combinations, and the most favorable direction for operations.
3. The selection and establishment of the fixed base and of the zone of operations.
4. The selection of the objective point, whether offensive or defensive.
5. The strategic fronts, lines of defense, and fronts of operations.
6. The choice of lines of operations leading to the objective point or strategic front.
7. For a given operation, the best strategic line, and the different maneuvers necessary to embrace all possible cases.
8. The eventual bases of operations and the strategic reserves.
9. The marches of armies, considered as maneuvers.
10. The relation between the position of depots and the marches of the army.
11. Fortresses regarded as strategical means, as a refuge for an army, as an obstacle to its progress: the sieges to be made and to be covered.
12. Points for intrenched camps, tétes de pont, &c.
13. The diversions to be made, and the large detachments necessary.
The maneuvering of an army upon the battle-field, and the different formations of troops for attack, constitute Grand Tactics. Logistics is the art of moving armies. It comprises the order and details of marches and camps, and of quartering and supplying troops; in a word, it is the execution of strategical and tactical enterprises." (Antoine-Henri Jomini, "The Art of War", 1838)

"[…] the art of war consists of six distinct parts:– 
1. Statesmanship in its relation to war.
2. Strategy, or the art of properly directing masses upon the theater of×war, either for defense or for invasion.
3. Grand Tactics.
4. Logistics, or the art of moving armies.
5. Engineering,–the attack and defense of fortifications.
6. Minor Tactics." (Antoine-Henri Jomini, "The Art of War", 1838)

"The science of strategy consists, in the first place, in knowing how to choose well a theater of war and to estimate correctly that of the enemy. To do this, a general must accustom himself to decide as to the importance of decisive points […]." (Antoine-Henri Jomini, "The Art of War", 1838)

"The study of the principles of strategy can produce no valuable practical results if we do nothing more than keep them in remembrance, never trying to apply them, with map in hand, to hypothetical wars, or to the brilliant operations of great captains. By such exercises may be procured a rapid and certain strategic coup-d’oeil,–the most valuable characteristic of a good general, without which he can never put in practice the finest theories in the world." (Antoine-Henri Jomini, "The Art of War", 1838)

"Strategy is the most important department of the art of war, and strategical skill is the highest and rarest function of military genius. (George S Hillard, "Life and Campaigns of George B. McClellan, Major-general U. S. Army", 1864)

"The tactical result of an engagement forms the base for new strategic decisions because victory or defeat in a battle changes the situation to such a degree that no human acumen is able to see beyond the first battle." (Helmuth von Moltke, "Über Strategie" ["On Strategy"], 1871)

"The world is a multiplicity, a harvest-field, a battle-ground; and thence arises through human contact ways of numbering, or mathematics, ways of tillage, or agriculture, ways of fighting, or military tactics and strategy, and these are incorporated in individuals as habits of life." (George Edward Woodberry, "The Torch, and Other Lectures and Addresses", 1920)

"Nine-tenths of tactics are certain, and taught in books: but the irrational tenth is like the kingfisher flashing across the pool, and that is the test of generals. It can only be ensured by instinct, sharpened by thought practicing the stroke so often that at the crisis it is as natural as a reflex." (Thomas E Lawrence, "The Evolution of A Revolt", 1920)

"In a physical contest on the field of battle it is allowable to use tactics and strategy, to retreat as well as advance, to have recourse to a ruse as well as open attack; but in matters of principle there can be no tactics, there is one straight forward course to follow and that course must be found and followed without swerving to the end." (Terence MacSwiney, "Principles of Freedom", 1921)

"The field of consciousness is tiny. It accepts only one problem at a time. Get into a fist fight, put your mind on the strategy of the fight, and you will not feel the other fellow's punches." (Antoine de Saint-Exupéry, "Flight to Arras", 1942)

"Keep the pressure on, with different tactics and actions, and utilize all events of the period for your purpose." (Saul Alinsky, "Thirteen Tactics for Realistic Radicals: from Rules for Radicals", 1971)

"As in war, strategic success depends on tactical effectiveness, and no degree of planning can lessen management's tactical imperatives. The first responsibility of the executive, anyway, is to the here and now. If he makes a shambles of the present, there may be no future; and the real purpose of planning - the one whose neglect is common, but poisonous - is to safeguard and sustain the company in subsequent short-run periods." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"It is necessary to develop a strategy that utilizes all the physical conditions and elements that are directly at hand. The best strategy relies upon an unlimited set of responses." (Morihei Ueshiba, "The Art of Peace", 1991)

"Grand strategy is the art of looking beyond the present battle and calculating ahead. Focus on your ultimate goal and plot to reach it." (Robert Greene, "The 33 Strategies of War", 2006)

♟️Strategic Management: Enterprise Architecture (Just the Quotes)

"[Enterprise Architecture is] the set of descriptive representations (i. e., models) that are relevant for describing an Enterprise such that it can be produced to management's requirements (quality) and maintained over the period of its useful life. (John Zachman, 1987)

"To keep the business from disintegrating, the concept of information systems architecture is becoming less of an option and more of a necessity." (John Zachman, "A Framework for Information Systems Architecture", 1987)

"Architecture is defined as a clear representation of a conceptual framework of components and their relationships at a point in time […] a discussion of architecture must take into account different levels of architecture. These levels can be illustrated by a pyramid, with the business unit at the top and the delivery system at the base. An enterprise is composed of one or more Business Units that are responsible for a specific business area. The five levels of architecture are Business Unit, Information, Information System, Data and Delivery System. The levels are separate yet interrelated. [...] The idea if an enterprise architecture reflects an awareness that the levels are logically connected and that a depiction at one level assumes or dictates that architectures at the higher level." (W Bradford Rigdon, "Architectures and Standards", 1989)

"A key ingredient to an enterprise architecture is the ability to link multiple and disparate systems into a coherent whole." (Karyl Scott, "Enterprise computing: Internetwork routing enhancements planned for NetWare", InfoWorld‎ Vol 14 (28), 1992)

"Although the concept of an enterprise architecture (EA) has not been well defined and agreed upon, EAs are being developed to support information system development and enterprise reengineering. Most EAs differ in content and nature, and most are incomplete because they represent only data and process aspects of the enterprise. […] An EA is a conceptual framework that describes how an enterprise is constructed by defining its primary components and the relationships among these components." (M A Roos, "Enterprise architecture: definition, content, and utility", Enabling Technologies: Infrastructure for Collaborative Enterprises, 1994)

"An enterprise architecture can be thought of as a 'blueprint' or 'picture' which assists in the design of an enterprise. The enterprise architecture must define three things. First, what are the activities that an enterprise performs? Second, how should these activities be performed? And finally, how should the enterprise be constructed? Consequently, the architecture being developed will identify the essential processes performed by a virtual company, how the virtual company and the agile enterprises involved in the virtual company will perform these processes, and include a methodology for the rapid reconfiguration of the virtual enterprise." (William Barnett et al, "An architecture for the virtual enterprise", Systems, Man, and Cybernetics, 1994)

"An enterprise architecture is an abstract summary of some organizational component's design. The organizational strategy is the basis for deciding where the organization wants to be in three to five years. When matched to the organizational strategy, the architectures provide the foundation for deciding priorities for implementing the strategy." (Sue A Conger, "The new software engineering", 1994)

"It is within the purview of each context to define its own rules and techniques for deciding how the object-oriented mechanisms and principles are to be managed. And while the manager of a large information system might wish to impose some rules based on philosophical grounds, from the perspective of enterprise architecture, there is no reason to make decisions at this level. Each context should define its own objectivity." (Rob Mattison & Michael J Sipolt, "The object-oriented enterprise: making corporate information systems work", 1994)

"An enterprise architecture is a snapshot of how an enterprise operates while performing its business processes. The recognition of the need for integration at all levels of an organisation points to a multi-dimensional framework that links both the business processes and the data requirements." (John Murphy & Brian Stone [Eds.], 1995)

"The presence of an enterprise reference architecture aids an enterprise in its ability to understand its structure and processes. Similar to a computer architecture, the enterprise architecture is comprised of several views. The enterprise architecture should provide activity, organizational, business rule (information), resource, and process views of an organization." (Joseph Sarkis et al, "The management of technology within an enterprise engineering framework", Computers & Industrial Engineering, 1995)

"There is no such thing as a standard enterprise architecture. Enterprise design is as unique as a human fingerprint, because enterprise differ in how they function. Adopting an enterprise architecture is therefore one of the most urgent tasks for top executive management. Fundamentally, and information framework is a political doctrine for specifying as to who will have what information to make timely decisions." (Paul A Strassmann, "The politics of information management: policy guidelines", 1995)

"Architecture is that set of design artifacts, or descriptive representations, that are relevant for describing an object, such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change)." (John A Zachman, "Enterprise architecture: The issue of the century", Database Programming and Design Vol. 10 (3), 1997)

"Issues of quality, timeliness and change are the conditions that are forcing us to face up to the issues of enterprise architecture. The precedent of all the older disciplines known today establishes the concept of architecture as central to the ability to produce quality and timely results and to manage change in complex products. Architecture is the cornerstone for containing enterprise frustration and leveraging technology innovations to fulfill the expectations of a viable and dynamic Information Age enterprise." (John Zachman, "Enterprise Architecture: The Issue of The Century", 1997)

"The documentation of the Enterprise Architecture should include a discussion of principles and goals. For example, the agency's overall management environment, including the balance between centralization and decentralization and the pace of change within the agency, should be clearly understood when developing the Enterprise Architecture. Within that environment, principles and goals set direction on such issues as the promotion of interoperability, open systems, public access, end-user satisfaction, and security." (Franklin D Raines, 1997)

"The Enterprise Architecture is the explicit description of the current and desired relationships among business and management process and information technology. It describes the 'target' situation which the agency wishes to create and maintain by managing its IT portfolio." (Franklin D Raines, 1997)

"An information system architecture typically encompasses an overview of the entire information system - including the software, hardware, and information architectures (the structure of the data that systems will use). In this sense, the information system architecture is a meta-architecture. An enterprise architecture is also a meta-architecture in that it comprises many information systems and their relationships (technical infrastructure). However, because it can also contain other views of an enterprise - including work, function, and information - it is at the highest level in the architecture pyramid. It is important to begin any architecture development effort with a clear definition of what you mean by 'architecture'." (Frank J Armour et al, "A big-picture look at enterprise architectures", IT professional Vol 1 (1), 1999)

"Enterprise architecture is a family of related architecture components. This include information architecture, organization and business process architecture, and information technology architecture. Each consists of architectural representations, definitions of architecture entities, their relationships, and specification of function and purpose. Enterprise architecture guides the construction and development of business organizations and business processes, and the construction and development of supporting information systems." (Gordon B Davis, "The Blackwell encyclopedic dictionary of management information systems"‎, 1999)

"Enterprise architecture is a holistic representation of all the components of the enterprise and the use of graphics and schemes are used to emphasize all parts of the enterprise, and how they are interrelated. [...] Enterprise architectures are used to deal with intra-organizational processes, interorganizational cooperation and coordination, and their shared use of information and information technologies. Business developments, such as outsourcing, partnership, alliances and Electronic Data Interchange, extend the need for architecture across company boundaries." (Gordon B Davis," The Blackwell encyclopedic dictionary of management information systems"‎, 1999)

"An Enterprise Architecture is a dynamic and powerful tool that helps organisations understand their own structure and the way they work. It provides a ‘map’ of the enterprise and a ‘route planner’ for business and technology change. A well-constructed Enterprise Architecture provides a foundation for the ‘Agile’ business." (Bob Jarvis, "Enterprise Architecture: Understanding the Bigger Picture - A Best Practice Guide for Decision Makers in IT", 2003)

"Enterprise Architecture is the discipline whose purpose is to align more effectively the strategies of enterprises together with their processes and their resources (business and IT). Enterprise architecture is complex because it involves different types of practitioners with different goals and practices. Enterprise Architecture can be seen as an art; it is largely based on experience but does not have strong theoretical foundations. As a consequence, it is difficult to teach, to apply, and to support with computer-aided tools." (Alain Wegmann, "On the systemic enterprise architecture methodology", 2003)

"Normally an EA takes the form of a comprehensive set of cohesive models that describe the structure and functions of an enterprise. An important use is in systematic IT planning and architecting, and in enhanced decision-making. The EA can be regarded as the ‘master architecture’ that contains all the subarchitectures for an enterprise. The individual models in an EA are arranged in a logical manner that provides an ever-increasing level of detail about the enterprise: its objectives and goals; its processes and organisation; its systems and data; the technology used and any other relevant spheres of interest." (Bob Jarvis, "Enterprise Architecture: Understanding the Bigger Picture - A Best Practice Guide for Decision Makers in IT", 2003)

"The software architecture of a system or a family of systems has one of the most significant impacts on the quality of an organization's enterprise architecture. While the design of software systems concentrates on satisfying the functional requirements for a system, the design of the software architecture for systems concentrates on the nonfunctional or quality requirements for systems. These quality requirements are concerns at the enterprise level. The better an organization specifies and characterizes the software architecture for its systems, the better it can characterize and manage its enterprise architecture. By explicitly defining the systems software architectures, an organization will be better able to reflect the priorities and trade-offs that are important to the organization in the software that it builds." (James McGovern, "A Practical Guide to Enterprise Architecture", 2004)

"An enterprise architecture is a blueprint for organizational change defined in models [using words, graphics, and other depictions] that describe (in both business and technology terms) how the entity operates today and how it intends to operate in the future; it also includes a plan for transitioning to this future state." (US Government Accountability Office, "Enterprise Architecture: Leadership Remains Key to Establishing and Leveraging Architectures for Organizational Transformation", GAO-06-831, 2006)

"Businesses are themselves a form of design. The design of a business encompasses its strategy, organizational structure, management processes, culture, and a host of other factors. Business designs evolve over time through a process of differentiation, selection, and amplification, with the market as the ultimate arbiter of fitness [...] the three-way coevolution of physical technologies, social technologies, and business designs [...] accounts for the patterns of change and growth we see in the economy." (Eric D Beinhocker, "The Origin of Wealth. Evolution, complexity, and the radical remaking of economics", 2006)

"Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of a company's operation model. […] The key to effective enterprise architecture is to identify the processes, data, technology, and customer interfaces that take the operating model from vision to reality." (Jeanne W Ross et al, "Enterprise architecture as strategy: creating a foundation for business", 2006)

"Enterprise-architecture is the integration of everything the enterprise is and does. Even the term ‘architecture’ is perhaps a little misleading. It’s on a much larger scale, the scale of the whole rather than of single subsystems: more akin to city-planning than to the architecture of a single building. In something this large, there are no simple states of ‘as-is’ versus ‘to-be’, because its world is dynamic, not static. And it has to find some way to manage the messy confusion of what is, rather than the ideal that we might like it to be." (Tom Graves, "Real Enterprise-Architecture : Beyond IT to the whole enterprise", 2007)

"Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company's operating model. The operating model is the desired state of business process integration and business process standardization for delivering goods and services to customers." (Peter Weill, "Innovating with Information Systems Presentation", 2007)

"Enterprise Architecture is conceptually defined as the normative restriction of design freedom. Practically, it is a coherent and consistent set of principles that guide the design, engineering, and implementation of an enterprise. Any strategic initiative of an enterprise can only be made operational through transforming it into principles that guide the design, engineering, and implementation of the new enterprise. Only by applying this notion of Enterprise Architecture can consistency be achieved between the high-level policies (mission, strategies) and the operational business rules of an enterprise." (Jan Dietz & Jan Hoogervorst, "Advances in enterprise engineering", 2008)

"Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution. The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment. Enterprise architects compose holistic solutions that address the business challenges of the enterprise and support the governance needed to implement them." (Anne Lapkin et al, "Gartner Clarifies the Definition of the Term 'Enterprise Architecture", 2008)

"The goal of enterprise architecture is to create a unified IT environment (standardized hardware and software systems) across the firm or all of the firm's business units, with tight symbiotic links to the business side of the organization (which typically is 90% of the firm […] at least by way of budget). More specifically, the goals are to promote alignment, standardization, reuse of existing IT assets, and the sharing of common methods for project management and software development across the organization." (Daniel Minoli, "Enterprise architecture A to Z: frameworks, business process modeling", 2008)

"Enterprise architecture [is] a coherent whole of principles, methods, and models that are used in the design and realisation of an enterprise's organisational structure, business processes, information systems, and infrastructure. […] The most important characteristic of an enterprise architecture is that it provides a holistic view of the enterprise. […] To achieve this quality in enterprise architecture, bringing together information from formerly unrelated domains necessitates an approach that is understood by all those involved from those different domains." (Marc Lankhorst, "Enterprise Architecture at Work: Modelling, Communication and Analysis", 2009)

"Enterprise engineering is rooted in both the organizational sciences and the information system sciences. In our current understanding, three concepts are paramount to the theoretical and practical pursuit of enterprise engineering: enterprise ontology, enterprise architecture, and enterprise governance." (Erik Proper, "Advances in Enterprise Engineering II", 2009)

"Enterprise architecture (EA) is the definition and representation of a high-level view of an enterprise‘s business processes and IT systems, their interrelationships, and the extent to which these processes and systems are shared by different parts of the enterprise. EA aims to define a suitable operating platform to support an organisation‘s future goals and the roadmap for moving towards this vision." (Toomas Tamm et al, "How Does Enterprise Architecture Add Value to Organisations?", Communications of the Association for Information Systems Vol. 28 (10), 2011)

"Enterprise Architecture presently appears to be a grossly misunderstood concept among management. It is NOT an Information Technology issue. It is an ENTERPRISE issue. It is likely perceived to be an Information Technology issue as opposed to a Management issue for two reasons: (1) Awareness of it tends to surface in the Enterprise through the Information Systems community. (2) Information Technology people seem to have the skills to do Enterprise Architecture if any Enterprise Architecture is being or is to be done." (John A Zachman, 2011)

"The enterprise architecture delineates the data according to the inherent structure within the organization rather than by organizational function or use. In this manner it makes the data dependent on business objects but independent of business processes." (Charles D Tupper, "Data Architecture: From Zen to Reality", 2011)

"Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. EA is used to steer decision making toward the evolution of the future state architecture." (Gartner)

"Enterprise Architecture is not a method, principle or doctrine – It is a way of thinking enabled by patterns, frameworks, standards etc. essentially seeking to align both the technology ecosystem and landscape with the business trajectory driven by both the internal and external forces." (Daljit R Banger)

Related Posts Plugin for WordPress, Blogger...

About Me

My photo
Koeln, NRW, Germany
IT Professional with more than 24 years experience in IT in the area of full life-cycle of Web/Desktop/Database Applications Development, Software Engineering, Consultancy, Data Management, Data Quality, Data Migrations, Reporting, ERP implementations & support, Team/Project/IT Management, etc.