A Software Engineer and data professional's blog on SQL, data, databases, data architectures, data management, programming, Software Engineering, Project Management, ERP implementation and other IT related topics.
18 January 2017
⛏️Data Management: Business Rules (Definitions)
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)
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 VI: Documentation - Lessons Learned)
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)
♟️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."
"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)
30 December 2016
♟️Strategic Management: Feedback (Just the Quotes)
"Most managers are reluctant to comment on ineffective or inappropriate interpersonal behavior. But these areas are often crucial for professional task success. This hesitancy is doubly felt when there is a poor relationship between the two. [...] Too few managers have any experience in how to confront others effectively; generally they can more easily give feedback on inadequate task performance than on issues dealing with another's personal style." (David L Bradford & Allan R Cohen, "Managing for Excellence", 1984)
"Organizations need the capacity for double-loop learning. Double-loop learning occurs when managers question their underlying assumptions and reflect on whether the theory under which they were operating remains consistent with current evidence, observations, and experience. Of course, managers need feedback about whether their planned strategy is being executed according to plan-the single-loop learning process. But even more important, they need feedback about whether the planned strategy remains a viable and successful strategy - the double-loop learning process. Managers need information so that they can question whether the fundamental assumptions made when they launched the strategy are valid." (Robert S Kaplan & David P Norton, "The Balanced Scorecard", Harvard Business Review, 1996)
"Just as dynamics arise from feedback, so too all learning depends on feedback. We make decisions that alter the real world; we gather information feedback about the real world, and using the new information we revise our understanding of the world and the decisions we make to bring our perception of the state of the system closer to our goals." (John D Sterman, "Business dynamics: Systems thinking and modeling for a complex world", 2000)
"The robustness of the misperceptions of feedback and the poor performance they cause are due to two basic and related deficiencies in our mental model. First, our cognitive maps of the causal structure of systems are vastly simplified compared to the complexity of the systems themselves. Second, we are unable to infer correctly the dynamics of all but the simplest causal maps. Both are direct consequences of bounded rationality, that is, the many limitations of attention, memory, recall, information processing capability, and time that constrain human decision making." (John D Sterman, "Business Dynamics: Systems thinking and modeling for a complex world", 2000)
"When we plan to win we take direct steps to ensure that we are building the right system at the best possible cost. Every action we take goes towards that end. Instead of trying to plan everything up front, we plan just the next few steps; and then allow customer feedback to correct our trajectory. In this way, we get off the mark quickly, and then continuously correct our direction. Errors are unimportant because they will be corrected quickly." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"The other element of systems thinking is learning to influence the system with reinforcing feedback as an engine for growth or decline. [...] Without this kind of understanding, managers will hit blockages in the form of seeming limits to growth and resistance to change because the large complex system will appear impossible to manage. Systems thinking is a significant solution." (Richard L Daft, "The Leadership Experience" 4th Ed., 2008)
"Clearly, total feedback is Not a Good Thing. Too much feedback can overwhelm the response channels, leading to paralysis and inaction. Even in a system designed to accept massive feedback (such as the human brain), if the system is required to accommodate to all incoming data, equilibrium will never be reached. The point of decision will be delayed indefinitely, and no action will be taken." (John Gall, "The Systems Bible: The Beginner's Guide to Systems Large and Small"[Systematics 3rd Ed.], 2011)
"[…] the practice of continuous integration helps a development team fail-fast in integrating code under development. A corollary of failing fast is to aim for fast feedback. The practice of regularly showcasing (demoing) features under development to product owners and business stakeholders helps them verify whether it is what they asked for and decide whether it is what they really want." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)
"No methodology can guarantee success. But a good methodology can provide a feedback loop for continual improvement and learning." (Ash Maurya, "Scaling Lean: Mastering the Key Metrics for Startup Growth", 2016)
"An effective goal management system - an OKR system - links goals to a team’s broader mission. It respects targets and deadlines while adapting to circumstances. It promotes feedback and celebrates wins, large and small. Most important, it expands our limits. It moves us to strive for what might seem beyond our reach." (John Doerr, "Measure what Matters", 2018)
About Me
- Adrian
- 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.