Archive for the ‘concept map’ Category

Proposal to Deficit SuperCommitte on Reducing Federal Executive Branch’s Costs

Sunday, September 18th, 2011
I just posted, at http://deficitreduction.senate.gov/public/index.cfm/contact, the following proposal on reducing the cost of the Federal Executive Branch’s operations

I have worked for the Federal Government for 35 year, 10 years as an Army Officer, 10 Years in Civil Service, and 15 years as a government management consultant.  I have worked as a manager or analyst in all of these roles.


From my experience, I submit that the authority (by law) and ability (by regulation) to quickly and simply reduce the cost of the US Federal Executive Branch’s (FEB) annual operations and development of new capabilities by more than 50% annually, while increasing the quality and timeliness of its performance, is already present in the FEB.

* Note that “resolving complexity and diversity in science and society into a system of controlled order” is the definition of “management” from the 1963 “Encyclopedia of Management” (Heyel, Editor).  Or more simply – “management is the activity of continuously resolving natural disorder into intended order”.

* Also note that a useful definition for “enterprise” is: “an endeavor, such as an organization, and the collection of its value-chain participants or stakeholders”.  These value-chain participants are typically customers, suppliers, authorities, subordinates, outsources/partners, and the public.  So an enterprise is an endeavor within its broader context or situation.

* Another term relevant to this suggestion is the term “architecture”, which is: “the parts of a subject, the parts’ relationships to each other, and the attributes of the parts and relationships”  The parts are the “nouns” about a subject, the relationships are “verbs” about the subject’s parts, and the attributes are adjectives for nouns and adverbs for verbs.

* So, an “enterprise architecture” is “the parts, part relationships, and part and relationship attributes about an endeavor and its value-chain participants or stakeholders.”

* An “enterprise architecture” is the primary mechanism of “enterprise management”, because it identifies and keeps track of all of the current and intended parts of an enterprise, their relationships/configuration, and their attributes/details.

But the primary resource of the US Nation as an enterprise, under the responsibility of the US FEB and an enterprise, is not being effectively, efficiently, or responsively “managed”.  That primary resource is “Information”, and the FEB has specific responsibilities for Federal Information Resource Management (IRM) under the 1980 and 1995 Paperwork Reduction Acts (PRA).

The FEB also has responsibilities for using that information resource to improve the effectiveness, efficiency, security, productivity, capability, and performance of the FEB and the Nation (e.g., Internal Controls, Government Performance and Results Acts, Government Paperwork Elimination Act, Clinger-Cohen Act).

But if the information resource is not collected, organized, shared, maintained, or managed, then the benefits of the huge investments in creating that information (e.g. research, development, collection, analysis) are wasted – there is no true “management” of any endeavor within its broader enterprise without management of the full enterprise’s information.  Without IRM, there is no enterprise management – there is “enterprise muddle”.

Within the FEB, there is no collected inventory of the ever-present and evolving “disordered” information, nor is there an adaptive intended “ordered” collection of information, nor is there a comprehensive, cohesive, coherent, and consistent method of “resolving” information disorder into information order.  So the US FEB costs two to three times more per year to develop its capabilities and operate them than it should, for what it produces as goods, services, information products, benefits, entitlements, and other outputs and outcomes.

A primary mechanism to reduce the annual cost of the FEB and improve its quality and responsiveness, is to immediately and strongly enforce the IRM instructions in OMB Circulars A-123 (Federal Managers’ Responsibility for Internal Controls) and OMB Circulars A-130 (Management of Federal Information Resources).  Neither of these Circulars is broadly applied nor enforced in the FEB, from the White House downward, nor out to those organizations outside the FEB who receive Federal funding.

Responsible parties within the White House EOP have not established the necessary guidance and assessment criteria for effective and efficient IRM. Thus, there is no path by which the FEB may become a most effective and efficient organization (MEEO).  The primary operational component of the IRM mechanism is now called the Federal Enterprise Architecture (FEA), evolving since 1998 from the US CIO Council and then, since 2002, the OMB FEA Program Management Office.  Unfortunately, the original FEA guidance, and the newly evolving guidance, do not provide a mechanism for IRM for FEB missions, only for tying IT investment management to the FEB missions.  To be specific, the FEB is providing guidance on how to buy and control information technology, not on how to manage the FEB and thus Nation’s public-domain Information Resources.

To achieve MEEO for the FEB, through strong FEB IRM that benefits the Government and the Nation, the FEB needs to include the following IRM parts in integrated updates to its Circular A-123, Circular A-130, and OMB FEA Guidance:

1. Within six months, build and deploy a FEB-wide standard process for IRM by applying terminology management techniques in the sequence below.  FEB management depends on FEB IRM, and FEB IRM depends on FEB terminology management.

* Continuously discover and identify all FEB organization and FEB-relevant information content stores (structured, semi-structured, and unstructured).  This would be performed with appropriate security and privacy constraints increasingly supported by the FEA mechanism, which can increasingly provide role-based access control (RBAC), and attribute-based access control (ABAC) knowledge to enable key to lock control over who, with a RBAC/ABAC key, can see and do what with resources having a RBAC/ABAC lock.

* Continuously index all content stores

* Extract out the terms of each content item (e.g., the data in a form’s fields, a form’s design, a document, the properties of the document, a diagram, the properties of the diagram, a database row, the database’s design, an email, the properties of the email)

* Identify each term as a noun, verb, adjective or adverb within the content’s structure (e.g., a noun within a sentence phrase)

* Build a “Term Inventory” in a single distributed/virtual repository for the FEB enterprise, uniquely identifying each term with a “universally-unique ID” (UUID) (a standard IT method)

* Identify within a single FEB distributed/virtual repository, the direct associations between terms (e.g., noun-verb-noun, subject-predicate_verb_predicate-object, table-column-row, class-attribute-instance)

* Build a FEB “Term Dictionary” for the Feb enterprise, enabling capture of all definitions used for a term, and their sources.

* Build a FEB “Concept Inventory” by linking models of “direct associations” within content (e.g.,within a phrase or clause) out to the broader-context (e.g., a sentence, paragraph,section, document, folder, library)

** Define, at all levels of endeavor, all FEB “concepts of operations” or CONOPS models (e.g., using simple concept mapping tools)

** Define subsequent endeavor “process models” (using process modeling standards, tools, and a single distributedFEB process model repository)

** Define subsequent “product models” within the process models and process repository

** Define subsequent “product metadata models” within the process repository (i.e., product descriptive information) as standard conceptual data models – CDM, logical data models – LDM, physical data models – PDM, and during later database and software design, physical database schema – DBSchema.

** Define subsequent “process metadata models” within the process repository (i.e., as CDM, LDM, and PDM of process, and later, the DBSchema of databases and software)

** Define subsequent “knowledge models” (as ‘ontologies” or “architecture metamodels” within a single “distributed” FEB knowledge/architecture/ontology repository

** Implement “knowledge-bases” from ontologies, or the equivalent “architectures” from architecture metamodels

** Define subsequent “value-chains” (and thus the collective “value-lattice”) of the endeavor (as “axiologies”)

** Implement “value-chain processes” as the broader “enterprise” of the endeavor.

* Build a FEB “Taxonomy” of terms categorized into broader to narrower meaning (i.e., a class hierarchy having attribute inheritance), as a “controlled vocabulary” for the FEB endeavor and broader FEB enterprise

* Build a FEB “Thesaurus” of terms, displayed using the Taxonomy, showing synonyms (e.g., equivalent, acronym, alias, misspellings, variant spellings) and variants, as the mechanism for jargon and language translation across elements of the FEB enterprise, and identifying preferred FEB terms for vocabulary standardization.

2. Within one year of defining the above IRM process, implement it across all operating activities funded by the FEB.

3. Annually validate compliance with Circular A-123, Circular A-130, and OMB FEA/IRM before issuing each Agency’s budget.

The emphasis on having a single FEB repository in the process above, and its physical and virtual distribution, is because the current approach of letting each FEB activity operate with autonomy in its management of its portion of Federal and National information resources, has led to the current crisis in government costs, effectiveness, and responsiveness, and has directly contributed to the government’s past, current, and imminent economic, social, and defense challenges.

 

Executive Branch Needs to Follow Its Own Rules To Reduce Costs

Wednesday, September 14th, 2011

I’ve worked as a manager, analyst, and consultant in and for the US Federal Government for 35 years – 10 years in the military, 10 years as Civil Service, and 15 years as a contractor.

The cost of US government annual operations and capability development (e.g., software, system) can be quickly reduced by over 50% per year, while improving its products (e.g., goods, services, benefits, entitlements), product delivery, and operational performance, responsiveness, accountability, and appropriate transparency, if all activities of the Federal Executive Branch (FEB), including the OMB Director, are required to fully comply with the Paperwork Reduction Act (PRA) and OMB Circulars A-123 (Internal Controls – IC), and A-130 (Federal Information Resource Management-IRM). PRA legislates IRM, IRM is key to FEB improvement, and IRM depends on documented and transparent internal processes and controls.
See PRA, A-123, A-130
A-123 IC requires that all FEB managers, at all FEB levels, model their processes, and validate their control over their processes, products, and performance measures .  A-130 IRM depends on processes, products, and measurements being in place and governed, to enable organizing and sharing FEB information and knowledge, which is public-domain, appropriate to privacy and security criteria.
Dramatic and rapid FEB improvements, by fully implementing PRA, A-123 (IC), and A-130 (IRM), and then consistently and broadly checking agency compliance, can be accomplished fully within the President’s authority, for the entire FEB. Congress need do nothing, although increased GAO vigor in assessing A-123 and A-130 compliance will help drive their implementations.
These improvements can be achieved by having OMB do for all FEB operations what they did for IT Investments – simply don’t issue a FEB activity’s budget, at any level, for any item, until the manager of the activity validates to their supervisory chain that they have: modeled their operations, products, metrics ,and data with the BPMN V2 process-modeling standard with any needed extensions, and shared that model’s diagrams and data with their CIO.
 

Part 4: Universal Management Solution

Tuesday, April 15th, 2008

Continuing my blog thread on Universal Management Solution, here are some more of the definitions I use.

ARCHITECTURE PRIMITIVES: An enterprise can include:

SUBJECTS: There would thus need to be reference/lookup taxonomies for each of the following enterprise “subject classes” (Location, Organization, Organization Unit, Function, Process, Resource, Requirement).

  • one or more Organizations (consider supply-chain participating organizations within the enterprise and beyond the enterprise-environment) [WHO is responsible?],
  • one or more organization units (OU) within the organizations (consider staff, program, and project offices, informal teams, positions, roles) [WHO performs?],
  • one or more Functions (the name of a “work” endeavor) [WHAT is done? WHY is it done? WHAT is the misson?, WHAT are the authority boundaries? WHAT are the performance targets? WHAT is the budget?],
  • one or more Locations (physical, virtual, or conceptual) [WHERE is it done?],
  • one or more Resources (Tangibles as matter, energy, space, and time. Intangibles as intelligence. There are limits on tangible resources. There are no limits on intangible resources.) [WHAT makes up the budget?]
  • one or more Processes (i.e., work-Functions performed in some sequence at one or more Locations, by one or more Organization Units, creating one or more resource-outputs, consuming one or more input-resources, constrained by one or more control-resources, and enabled by one or more mechanism-resources, for one or more Organizations, in reaching the success measures in relation to the outputs’ results, of one or more Endeavors.) [WHAT is performed by WHO, WHEN, with WHAT resources, to produce WHAT resources?]
  • one or more Requirements for specified process results (measured customer satisfaction with process outputs) [WHAT is required as outcome to satisfy the WHY, from WHAT results, based on WHAT products?].

RELATIONSHIPS: To describe a Requirement, the relationships between these classes, their subclasses, or their instances would have one or more of the following types of Relationships: Equivalence, Categorization, Containment, Sequence, Version, Variance, and Descriptive, all arrayed as a single Relationship taxonomy.

RELATION VALUE-ROLE: For a Sequence relationship, each node in the triple flow from predecessor to successor would have a value-chain role: Customer, Performer, Supplier, Authority, Outsource, Subordinate, Public. Many of the technologies being developed and deployed for “customer-relationship management” purposes can also be used for “all relationship management”, also called Extended Relationship Management (XRM).

REQUIREMENT LIFE CYCLE ROLE: For each requirement, as a collection of relationships, the requirement would be identified as in a life cycle state of: Conceptual, Requested, Authorized, Procurement/ Development, Deployment, Operation/ Maintenance, Disposition.

UNIFIED MANAGEMENT FOR UNIFIED VALUE: By aggregating the enterprise architectures (world views) of complex and diverse multiple endeavors, into a single managed repository sharing a common controlled vocabulary, and by then mapping these different EA’s to the General Endeavor Management (GEM) world view ontology,, the complexity and diversity details in these various world views can be resolved into a simpler and orderly unified view, a unified management ontology, thus enabling subsequent federated world-views of the unified whole endeavor. This then enables holistic “value-chain” management, called Axiology, for the full endeavor operating within its environment.

More material on this GEM approach is published at http://www.one-world-is.org/, and is released into the public domain.

I am available for discussion, orientation, training, development, and implementation support for this approach through the early-stage non-profit educational corporation (EIN 20-8041935) at the URL above.

I am seeking donations (seed capital and start-up funding as cash, stock assignments, equity equivalents, etc.), grants, and supporting-angels, to enable me to further document and deploy this GEM capability for ubiquitous use. I am available on a limited basis for fee-for-service contracts (training, development, implementation, operation).

End of Thread: Universal Management Solution

 

Part 3: Universal Management Solution

Monday, April 14th, 2008

Continuing my blog thread on Universal Management Solution, here are some more of the definitions I use.

SEMANTICS (CONTROLLED VOCABULARY): Endeavors depend on Words. Words are spoken and recorded representations of our perceptions . Records are in analog and digital form, as content. Digital records can be in structured, semi-structured, and unstructured form. Words are contained in the spoken, written-analog, and written digital content of the endeavor. Spoken words are collectable and manageable using audio mining technologies. Written-analog words are collectable and manageable using hand-writing recognition technologies. Written digital words are collectable and manageable using a variety of data management indexing technologies. Even images and non-verbal sounds can be collected and managed with descriptive word attributes.
Words representing named Things are nouns. Words representing Relations are verbs. A Word List, as a data table, can be built to contain and manage these words.

Word combinations, called Terms, are variants to words. A Term table can be built to contain and manage Terms (root-word entry via lookup from Word List, modifier-word(s) entry via lookup from Word List).

Terms Table and Words List can be combined into a Vocabulary Table.

Vocabulary items, as Words or Terms, can have one or more definitions, aliases, and acronyms. A master-detail data base can be build to contain and manage Vocabulary Items (master level) and zero or more definitions, aliases, and acronyms (detail level).

Categories of Vocabulary Items, as a hierarchical “attribute-inheritance” structure of broader and narrower vocabulary item meanings, form a taxonomy. The two main taxonomies of an enterprise are Subject (i.e., noun) Taxonomy and Relation (i.e., verb) Taxonomy. A categorization data base (in SQL, ISAM, or XML or any other database technology that provides “self-join” or “inheritance” features) can be built to contain and manage taxonomies. Self-join relational structures enabled fixed-attribute taxonomies, while class (e.g. XML) inheritance structures provide adjustable (i.e., add, override, hide) attribute taxonomies.

Noun-verb-noun assertions, called concepts, also called triples (as in metadata, RDF, RDFS, OWL), are the building blocks of all architecture.

The “preferred” definition for a given vocabulary item by an endeavor, or collection of endeavors, and alternate vocabulary items having the same or similar meaning, form a “thesaurus” for a given bounded endeavor. Using a thesaurus, those persons, groups, communities, or organizations within the endeavor can “translate” a local-endeavor vocabulary item to the preferred larger-endeavor vocabulary item, and vice versa.

The linked collection of concepts/triples (i.e., noun-verb-noun assertions) modeled by an endeavor form the endeavor’s “concept map”.

A concept map showing the attributes of the nouns/things and verb/relations forms what is also called an entity-relationship-attribute or object-role model, and sometimes imprecisely referred to as a data model.

An endeavor’s attributed concept map, showing rules constraining the relationships, is called an “ontology”. An ontology represents the “world view”, the vantage point, of an endeavor, and thus the blended perceptions of its participating individual persons, groups, communities, and organizations in their “world”.

See Part 4

 

Part 2: Universal Management Solution

Sunday, April 13th, 2008

Continuing my blog thread on Universal Management Solution, here are some of the definitions I use.

MANAGEMENT: Management definitions are hard to find. Those I’ve found tend to be focused on management of a specific thing (e.g., financial, project, HR, asset, IT, business).

A general-use, basic, definition of management is: Management is the resolution of complexity and diversity into orderly patterns of control. This was derived from a simpler phrase contained in the Foreword of the 1963 Encyclopedia of Management, Edited by Carl Heyel, Reinhold Publishers (page xix). My more comprehensive definition of management is: Management is the dynamic resolution of the evolving complexity and diversity in science, society, and perception into an adaptive system of controlled order. Most simply, management is turning disorder into order. What is now called enterprise architecture has always been part of every endeavor’s management.

Management entails knowing where you are, deciding on your destination, deciding how you’ll get to your destination, and proceeding to your destination despite obstacles. In IT terms, this is the same as knowing your As-Is state, To-Be state, and transition plan, and implementing the plan and updating your status as you proceed to your To-Be state.
To elaborate on the previous statement -management is knowing where your are (i.e., knowing your current complexity and diversity), deciding on your destination (i.e., specifying your controlled orderly state), deciding how you’ll get to your destination (planning the resolution), and proceeding to your destination despite obstacles (adjusting the current state, destination, success measures, path, and pace).

ENTERPRISE: Your endeavor, i.e., enterprise, is the managed-pursuit of your intended “orderly state”.

In its most basic form, an enterprise is a “bounded purposeful endeavor” (a “To-Be” state) that can be treated as a single production “function” (i.e., work performer) (consider input/control/output/mechanism – ICOM models). The enterprise boundary defines what the enterprise can control and secure – what is inside the boundary is the enterprise – what is outside the boundary is the enterprise’s environment.

Individual persons pursue many endeavors. Groups of individual persons typically pursue endeavors specified by consensus. Organizations of groups and individual persons pursue a collection of endeavors specified by owners/voters, boards/legislatures, and staff (i.e., executives, managers, supervisors, and workers). Communities are large groups, which may be subordinate-to or supported-by an Organization. Multiple Organizations can operate as a single larger Organization through agreements, partnerships, and treaties.

A coherent organization aligns the collection of internal endeavors of its included organizations, groups and individuals into a cohesive effort achieve the purpose of the higher levels of its authority (specified as the organization’s management mission/vision, goals, success measures established by owners, then boards, then executives, and then managers). Internal endeavors, performed by organizational elements that are not aligned with the larger endeavor’s defined and disseminated management success measures, are not optimal for the organization, but suboptimal for the misaligned worker, supervisor, manager, or executive.

ARCHITECTURE: An architecture is a human’s representation of the uniquely named things in a perceived structure, how they uniquely relate to each other, the attributes of the things and relationships, and the unique values in these thing and relations attributes. An architecture is not the structure, but is our rough approximation (i.e., model) of the structure (i.e., The map is not the terrain). All structures are infinitely complex (see Chaos Theory and Fractals). An architecture provides our representation of the order we perceive within a dynamic structure (or system).

See Part 3

 

Part 1: Universal Management Solution

Saturday, April 12th, 2008

Here it is – A Universal Management Solution To Every Management Need!!

Threaded through my next several blog entries I will describe what I call “General Endeavor Management” (GEM) (TM) solution to solve every endeavor management requirement.

NEED STATEMENT: Everyone, everywhere, throughout time, has the need, typically not well-specified, to share and cooperate, to some degree. Other names for this “share and cooperate” need are: integration, interoperability, federation, unification, merger, value-chain, supply-chain, dependency, economy, and ecology.

While I have seen many good references, posts, and articles on the sub-architectures within an Enterprise Architecture (EA), and how the subarchitectures relate to each other, I’d like to ask you to consider a more fundamental, “primitive” (in John Zachman’s terms), foundation from which these sub-architectures would be built.

The “primitive” items below are representative of the “intelligence, time, space, energy, and matter” characteristics of our physical universe. The primitives are: Subjects, Relations, Value-Roles, and Life Cycle Roles, all described below.

By starting with these primitives, you can build much simpler, less expensive, more maintainable, and more flexible enterprise architectures, and add significant useful/operational/executable capabilities to what is typically considered to be EA.
GEM is an enterprise management extension of what most people in the EA industry consider to be EA. GEM provides the means to expand the EA into use as the adaptive operational knowledge-base of all enterprise management, resulting in an enteprise management architecture (TM) or Architecture of the Enterprise (AE) (TM).

What is provided in this and subsequent blogs is not just a way to “do” EA, although I have applied it as an EA methodology, metamodel, and implementation process before. What is provided is a way to build an EMA that can enable whole-enterprise management, whether involving one person, five, five thousand, … or seven billion.

First, what is the purpose of an enterprise architecture and what are the boundaries of the enterprise? If you don’t start with the broadest boundary you can envision, you’ll have to “expand” your architecture, and any capabilities built to comply with it, to encompass new things not considered at the beginning. This requires the subsequent “integration” of these new things into your previous architecture, and possible replacement of things – integration and replacement are expensive efforts, and unneeded if you start with a broad enough boundary for your enterprise and its contained/controlled systems.

Many describe that they need to come up with an architecture “roadmap”. Some of the aspects of an EA are As-Is state, To-Be state, and transition plan. Th current status of your “enterprise” gives you the “As-Is” architecture, describing current and historical fact. Deciding, preferably in consensus, where those participating in the enterprise want to go is a “To-Be” architecture of the enterprise, describing preferred and alternate projections of changes from the current state. The “transition” (also known as migration, change management, or portfolio/program/project management) strategy to change the As-Is enterprise into the To-Be enterprise is the third aspect.

A “roadmap” is a project plan with “success milestones” in its basic form (also known as success measures, performance metrics, and objectives), often represented as a variant of a Gantt chart. So, use a project management tool to define (starting with deliverables such as the completion of the sub-architectures and their linking into the full EA), plan (the work-tasks, dependencies, labor available, labor assignments, work hours per individual assigned resource and for the full task, and the estimated durations of the tasks given the resource availability and task dependencies), track (individual users update their task status), analyze, report, assess, and adjust your “roadmap”.

See Part 2

 

Management – Basic, formal, and extended definitions.

Sunday, February 24th, 2008

Management is putting the rational thought process into action.

This fits nicely with the definition of the “Rational Thought Process” identified by Dr. Norman Vincent Peale many years ago. His definition of the rational thought process was: knowing where you are, knowing where you want to go, and knowing how to get there.

A more detailed definition for management is:

Management is discovering where you currently are, deciding where you want to go, planning how to get where you want to be, and adjusting your current awareness, intended destination, and pace and path of getting to your intended destination as you proceed.

I offer a more somewhat more authoritative definition of management as a paraphrasing from the 1963 Encyclopedia of Management, (Reinhold Publishing, New York, Carl Heyel, Editor):

Management “….is the resolution of complexity and diversity in science and society into a system of controlled order”.

At 16 years of age, I discovered the above clause about management, but no formal definition of it, in the Reinhold Encyclopedia, while researching what I wanted to study in college. I used my research to create, in 1967, what I called my “wheel of knowledge” in preparing for that college-major decision. I later called it a “spiral of knowledge” to reflect its properties of continuous refinement. See my models related to this at http://www.one-world-is.com/rer/owis/gem-core/GEM_Core-Collection.htm, slides 29-32.

To further elaborate on my above definition:

  • The “complexity” term relates to the many parts that affect, and are effected by, a given bounded, “situation needing to be managed” (hereafter, “situation”).
  • The “diversity” term relates to the many different varieties of parts that affect, or are affected by a given bounded situation.
  • The “bounded situation”, in terms of management, is called an “endeavor” – a purpose-driven effort.
  • The “resolution” term relates to the need to reduce the complex and diverse things and relationships of a situation into simpler forms, typically by identifying, describing, categorizing, and organizing those things. This includes the steps of:
  • (1) identification of the specific things in an endeavor;
  • (2) characterization of the specific things;
  • (3) categorization of the specific things into “types of things” by abstracting common-characteristic attributes;
  • (4) modeling of the types of things, their relationships, and the type and relation attributes;
  • (5) simulating the endeavor;
  • (6) operating the endeavor;
  • (7) gathering intelligence about the endeavor and its external environment; and
  • (8) refining the endeavor by repeating this cycle.
  • The “system of controlled order” term relates to the always-future intended state that is continuously sought by resolving the always-current “As-Is” complexity and diversity of an endeavor.
  • The “order” term relates to the endeavor’s model, its representation in a structured form.
  • The “controlled” term relates to the endeavor’s continuous refinement in the current and future life cycles.
  • The “system” term relates to the continuous bounded efforts within the management process.

So the extended definition for management that I use is:

Management is the continuous resolution of the dynamic complexity, diversity, and chaos in and around the science, society, and perceptions of an endeavor into an evolving system of adaptive controlled order.

See slides 42-66 at the above URL for slides related to my “management” view.

 

Roy Roebuck’s First Blog

Friday, February 22nd, 2008

This is my first blog.

I’ve been using computers for decades, PC’s since 1982, the Internet since before it existed (i.e., I used it as MilNet and ARPANet before it was commercialized).

I have used Wikis and Semantic Wikis for their team-authoring functionality, but just never felt I had anything to “journal” in a blog. I have now been convinced otherwise by friends, family, and associates, so here we are.

I will post my thoughts, ideas, suggestions, observations, etc., regarding my endeavors to provide information to the world on ways to improve “management”, based on my 30+ years as a manager, management analyst, organizational designer, enterprise architect, and terminologist.

Broadly, I will offer my thoughts on the universe’s architecture (i.e., its parts, their relationships, and their attributes), i.e., its ontology (i.e., its architecture + the behaviors in whole and in part), and its axiology (i.e., its value in total and in part), all within its broader context (whatever that might be).

Have your best day!

Roy Roebuck