App Design Primer: A Short Story


, , , , , , , ,

Business Scenario:

A prospect has asked that we build them a web app for ordering their available items even if they don’t have any currently available inventory.

Their business model allows them to take and confirm orders whether they have the items in inventory or if they need to find and order them from an outside but known supplier. Of course, if they don’t have the requested item on their inventory master file, then they will accept the order but will notify their client that the item is not normally available (a pending Order), and then they will search to find the requested item for their client from a new source.

The budget for this application build has been set by our Estimators at a fixed bid of $XX,000.00 plus expenses up to 15% of the Fixed Bid. These expenses may include travel to appropriate location(s) and any expenses related to those trips.

Once the client reviews and accepts our Statement of Work (SOW) including the associated estimated expenses, we can begin our contracted efforts to build this solution for them.

Project Approach:

Our approach will be to apply these phases of Development and Delivery:

  1. Business Owner identification and meetings
    • Collect ID, Contact Info, Functional expertise (SME’s), and a measure of each individual Business Participants’ Influence on the interim and final results of our development
    • Start prototype discussions iteratively elaborating on necessary and ancillary features
      1. Apply diagramming techniques to present / capture conceptual and logical capabilities of the envisioned solution
    • Discuss essential data requirements for topics like:
      1. Customer Credentials including Credit Worthiness
      1. Orderable Item Inventory: Cost / Price, Shipping costs, Delivery Successes (and failures); Quality Metric(s)
      1. Shipper Reliability: Timing, Location, Special Instructions, Losses
      1. Order History: “Items Ordered With…”, Quantity / Frequency per Customer / Item combination(s); Payment Timing; Return Pattern(s)
  2. Project Budget Planning and Tracking
    • Time, Money Initial / Current Schedule
      1. Including Best Estimate Remaining Time, Money
    • Collect Time, Money Spent from Project Team Members
      1. Business Owners, Participants
      1. Consulting Resources (our internal technical team)
      1. Outside / Third Party expenses
    • Time, Money spent per interval
    • Time, Money planned per interval
    • Scope Changes:
      1. Discovered
      1. Estimated / Impact Analysis
      1. Review and Approval / Rejection
      1. Updated Time, Money plan
      1. New Remaining Time, Money totals
    • Status Reports by interval
      1. Progress against plan: Time, Money, Deliverables
      1. Project remaining: Time, Money, Deliverables
  3. Story Boarding with Business Owners
    • Features by Business Priority
      1. Identify potential (in diagram and narrative formats):
        • Events
          1. User initiated Events
          1. Data State initiated Events
          1. Clock / Timing Events
        • Processes
        • Data Requirements
        • State(s) as result of acceptable Data collection
        • Process responses to new State(s)
    • Features by Data Dependencies
      1. Invalid dependencies result in Transaction recycling to source for clean up or removal
    • Features by Functional Necessities
      1. Processes expected when Data is Accepted as fully Valid
    • Validate Story Boarding Models to assure Orthogonality
      1. Build, Inspect, Certify a Traceability Matrix
        • All components of each diagram / model can be matched with all other model components
          1. Event :: Process
          1. Process :: Data
          1. Data :: State
          1. State :: Event
    • Features based on most recent Delivery / Prototype / User Feedback
      1. Identify Re-Factoring necessities
      1. Identify Change discoveries for Story Board features
        • Implemented or still scheduled
        • Re-Factoring will apply on either Released capabilities and/or remaining Models / Features
  4. Project / Prototype Development Schedule
    • By Iterations / SPRINTS:
      1. Scope of Event, Data, State, Process: Features per agreement with Business Owners and Technical Developers
        • Infrastructure,
        • Architecture,
        • Data Management,
        • Bandwidth Capacity, targeted user base
        • Investigate Re-Factoring necessities when needed
      1. SPRINT Schedule to build, test, release to targeted audience:
        • In Scope Events expected to trigger Process(es)
        • Processes to capture Event Data
          • Data Validation in stages
            1. Item Content
            1. Field to Field Relationships
            1. Field to File / Table Relationships
        • Validated Data to set a State for future processes
        • State settings to initiate an Event for Next Step Processing
      1. BUILD, Prototype, Test, Release to targeted audience
      1. Repeat for next Intended SPRINT
  5. When Business Owners are satisfied that sufficient features have been delivered …
    OR …
    When the Labor estimated for the current Fixed Price bid has been exhausted
    THEN …
    • The Project can be marked as Completed (for now)

Project Timeline:

Many timelines of recent projects, especially those that apply a hybrid of Software Engineering and Agile thinking are a “study in parallels”.

It is typical that the Budgeting and Tracking of a project will run concurrently to the execution of a project.

A P D Short Story Timeline

However, the iteration between Identifying new Business Owners, documenting their Story Boarded feature requests using Software Engineering techniques (Event, Process, Data, State Models) and SPRINTs to each release of the product are a repetitive loop on projects like this one.

The factors that usually end a project of this nature are either that the estimated Labor costs have been consumed, the Business Users become satisfied with the latest iteration of the app, or some critical resource on the project (Business, Technical, or Management) is required elsewhere so the project will be, at least, temporarily wrapped up.

The Principle(s) of Orthogonality:

Orthogonality is based on the notion that two or more formulae or models can describe one and the same solution even though the syntax and perspective of these formulae may be very different.

The Orthogonal Drive

Either a User or a new State can submit or instigate an event. A calendar function or process is also very helpful in initiating new Events.

An Event Model presents the known / acknowledged Events that an application will respond to using Processes to collect the relevant data at the time of each Event.

A Process Model will document the sequence and logic of a series of steps that will deliver the functions of an application. Each Process will insert or update any Data and set the State of the updated Data row. The User can then be informed of the Updates.

A Data Model will represent the data being managed by an application through its Processes as they are performed by an application. This Data can be used to create Reports for the appropriate Users.

A State Model monintors the condition of each unique row of data once each Process has completed its application of the appropriate logical response to its Events. Select States will Notify their Users and can also Trigger a new Event.

The process of verifying an application by orthogonally inspecting its models requires that each component of each of the models be checked off against the other occurrences in the other models until no model components are left to check off. When this situation occurs, the models are said to be Orthogonally balanced, and the solution described is consistent, persistent, and complete.

The Proof of Orthogonality:

The Orthogonal Model suggests that a logically complete and accurate solution is described in certain graphic models when the following principles are true:

  • Each data attribute included in a Data Model has an associated Process which Collects, Edits, Validates, and Saves each occurrence of these data
  • Each business event related to our application will initiate a Process that anticipates all associated data attributes and collects them in a timely and thorough manner
  • Each row of data will have a State setting that is recognized by a Process which can initiate a new Business Event for continued Processing
  • Each Process component will be associated with a known Event or State – Event combination and these Processes will perform functions that are included in the scope of the current SPRINT


  • Each data attribute has a:
    • Event which signals the availability of a new instance of this data field
    • Process with the logic to collect, edit, and validate the new data’s value and existence
    • State setting showing that this new occurrence is now available in its data row
    • Data row capable of retaining each value
  • Each business event has a:
    • Process with logic to respond to the Event, collect its data and interact with the Event instigator (human, automation)
    • Data that is expected to become available at each new Event
    • State setting showing that another instance of this Event has been recognized
  • Each process has a:
    • Event or State that will trigger the execution of this process
    • Data that is expected to be processed by the logic contained there in
    • Updated / Derived data that results from the application of the processes logic
    • Data row ready to contain the newly updated contents
  • Each state has a:
    • Process with logic to set the appropriate State
    • Event ready to respond when each particular State is set
    • Data to capture the time and date of the setting of the State

There are questions that can be answered when inspecting logical and conceptual models using the Orthogonal Principles. These questions relate to how an application can provide additional value to its users in real time.

If we focus on the relationship between a Data Model and its other models, then some of these questions may be answered:

  1. To the Process Model:
    • Will the storing of a data field suggest that another Process be invoked now that this data field is saved?
    • What are the necessary relationships to other data entities as each new data field are collected, edited, and saved?
    • Will the saving of a new row of data trigger the need to initiate another down-stream Process?
    • Once an entire row is saved where all its content has been validated, what “State” should the row be set to? And what will that State require in terms of initiating a new Process?
  2. To the Event Model:
    • When a new row is updated such that its contents are all Validated, what State should be set for this row and what Event should this State update trigger?
  3. To the State Model:
    • See above questions about how and when to set certain State valued for each saved row of data

If questions like these are answered as part of the Story Boarding process, then we can expect that the SPRINT development efforts will deliver segments that are more “feature-rich” than without these answers.

It’s NOT Finished, but this Short Story is over for now:

Please let me know what you think about these writings using my email address(es): or .

You can also subscribe to future materials as I develop them for my other books at my blogs:


Thank you, Bill Gutches

“Follow the Agile Manifesto in parallel with effective Software Engineering ala the Orthogonal Model.”

Elevator Speech V2022


, , , , ,

My name is Bill Gutches and I have been in the Information Technology arena for my entire career.

Recently I have been doing Digital Marketing for individuals and small businesses by improving their Web Presence with Web Sites and Blogs, Search Engine Optimization (SEO), Analytics and Marketing Programs. I also assist with Job and/or Income Search by suggesting revisions to LinkedIn and other Social Media Profiles and Resume changes.

One of my other Passions is writing. I have published one book so far: IT’s Lost Art of Software Engineering and am working on two more books for now. And to stay “in shape” for writing books I also write several blogs ( and my web site:

In another capacity, I work for Tashman Tech Group as a Policy writer, Income and Expense Collection / Reporting for the company Dashboard and Tax Reporting. And, I have also built three Mobile Apps that can run on IoS, Android phones and most tables to collect and transmit data to a centralized database for analysis and reporting purposes.

Before I “retired”  I was an Information Technology Consultant running Projects of all kinds; my teams have built websites, mobile apps, and business portals. I was also repeatedly involved in setting up various PMO’s: Portfolio Management Offices, Program Management Offices, and Project Management Offices.

If you are interested in talking to me about some of your small businesses needs, please reach out to me.

PS: I am now working on my third small business and even though it is not incorporated yet, I am still providing my services as an individual contributor / sole proprietor. 

My name is Bill Gutches and I can be reached at 610-662-5658; or .

thanx, bgbg

The Corvette

The Corvette.
A man named Tom Nicholson posted on his Facebook account the sports car that he had just bought and how a man approached and told him that the money used to buy this car could’ve fed thousands of less fortunate people. His response to this man made him famous on the internet.
READ his story as stated on Facebook below.
A guy looked at my Corvette the other day and said, “I wonder how many people could have been fed for the money that sports car cost?”
I replied “I’m not sure”:
·       it fed a lot of families in Bowling Green, Kentucky who built it,
·       it fed the people who make the tires,
·       it fed the people who made the components that went into it,
·       it fed the people in the copper mine who mined the copper for the wires,
·       it fed people in Caterpillar who make the trucks that haul the copper ore.
·       It fed the trucking people who hauled it from the plant to the dealer
·       and fed the people working at the dealership and their families.
“BUT,… I have to admit, I guess I really don’t know how many people it fed.”
This is the difference between capitalism and socialism/communism (the welfare mentality).
When we buy something, we put money in people’s pockets and give them dignity for their skills.
Whenever government “gives” people something for nothing, they rob them of their dignity, self-worth and their desire for self-improvement, subjecting them to the slavery and tyranny of governmental dependency.
Capitalism is freely exchanging your money for something you value.  Socialism is having the government take your money [taxes] against your will and give it to someone else for doing nothing.
I Think this is well written and well thought out.  If you agree please send it to your friends.  If you disagree send it to your friends anyway, and have a nice day.

K P I Requirements


, , , , , , , , , , , , ,

Key Performance Indicators (KPI’s) are measurements and projections that can help a management team make decisions about the Strategic and Tactical Plans for the future of an organization.

Many business requirements describe operational necessities of an application or a business App or Function but how should we expect a Requirement for a K P I automated function be stated?

In the following list, I would like to prompt / instigate some higher order thinking about Requirements that we can document to be included in our new application development efforts so that the app can support or anticipate how the active executive or decision making management of an organization can use the operational data to consider new decisions:

  • What is a predictive inventory forecasting tool?
    • What could it be used for?
  • What could dynamic Purchase Order generation do for our organization?
    • What would we base the automated PO Generation on?
  • Could we predict the need for additional staff in specialized areas of our product or service delivery organizations?
    • Based on what criteria?
  • What information would be useful to re-design manufactured products to increase useful life, reduce maintenance costs, and provide more value to our Customers?

What questions would YOU like to ask of your operational data that could help you make critical business model decisions in the foreseeable future?

Time for THE BOOK


, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

A few weeks ago (May 2018), I started a “Go Fund Me” site to gather some money so that I can publish “The Book” that represents many of the ideas from this blog.

The Title of the book will be: “IT’s Lost Art of Software Engineering” and will contain much of what has been posted in this blog for the last few years.  If you are interested, please use the link below to review my Go Fund Me site and, possibly, make a donation for me.

Please keep in mind that anyone who donates $10.00 USD or more will get a FREE and SIGNED copy of the book (I will need a mailing address after the donation) once it is available in hard copy.

Your support would mean a lot to me. Thank you so much!  bgbg

27 Aug 2018: The Go Fund Me effort is dragging on very slowly and, if it doesn’t pick up its pace relatively soon, I will probably decide to return the few donations I have received and shut down this effort. Now CLOSED. Offered to return contributions.

However, there is still time so if you want to make a donation (and get a FREE SIGNED copy of the book) please go to my Fund Me page ( and make a $10 or more donation quickly.

Thanx you in advance, bgbg

Data’s After Life


, , , , , , , , , , , ,

When we are born, a birth certificate is usually created with our Name, Date, Weight, Length, Parents names, location, etc..  It is also at this point that our Health Record begins tracking injections, infections, operations, procedures, prescriptions, reactions…

When / If we join or are entered into some religious group, records are kept of the group name, location, and other pertinent information.  This “membership” will also keep track of events specific to the organization: Bat Mitzvah, Baptism, Weddings, Death notices.

As we proceed through our education, data is collected about where we attended, what courses we took, what grades we achieved and what disciplinary actions might have been taken / necessary.  And there are records for the costs and debts we incur.  Those Student Loan records will follow us forever, whenever, however we try to lose them.

And, again, during our education, we take / make notes on paper or electronically and we retain some of these notes for studying in preparation to take exams where we get Grades and notices from our Instructors about how to improve or maintain our level of achievement

Once we graduate from schools or leave before we might have graduated, we join other communities: The Military, Religious Orders, Jobs, Companies of one kind of another.  These events are when the real interesting data events start to unfurl.

Employment records keep track of Titles, Achievements, Income, Employments Benefits and Costs, Taxes (Paid or Owed), Hiring, Firing, Performance Assessments, Remediation Steps taken or suggested, …

Self employment must keep track of Expense, Income, Tax Payments, Deductions and regulatory tax filing whether we are employed or self employed.

While employed (self or otherwise) we create info in files or on paper reflecting the content and intent of our positions.  Some of these records are stored on our employers’ media since they are “works for hire” and others are retained in files (paper or electronic) in our own locations: file cabinets, folders, baskets, trash bins or hard drives / cloud drives.

Some of us write books, recipes, instructions, blogs, articles, clippings, critiques, editorials.  These materials are retained, published, sold, held for posterity, hoarded.

There are hard drives and manila folders all over the world that contain treasures and trash containing the data of our lives.  There is value and potential wasted time in the content of these files.  But, who uses these values?  What happens to all that learning, discovery, insight, … if no one has access to all this data?

What will happen to your data when you no longer have access to it?

What is the After Life of our Data?  Who could benefit from our information?  Who will benefit from yours once you have no more need of it?

With Great Data, comes Great Opportunity


, , , , , , , , , , , , , ,

There once was a line in a movie: “With Great Power Comes Great Responsibility.”

My take on that is that the more Data we receive, the more Opportunity we get to use that data.

Big Data, the Internet of Things, Business Intelligence and the current evolution in newer, faster, fresher data puts responsibility and opportunity squarely in our laps or IDE’s (Interactive Development Environments) if you will.

What, if anything, are we doing to prepare for these opportunities and responsibilities?

I would really like to hear your thoughts on how we prepare.

The Path To Inkc Profile


, , , , , , , ,

  • How many ways would you be willing to collect income:
    • Full Time Employment with Salary and Benefits?
    • Part Time Employment paid by the Hour or Piece of Work?
    • Signed Master Service Agreement(s) for predefined services, rate and duration?
    • Signed Purchase Order(s) for your product offering(s)?
    • Incorporation of your own new company and the creation of new jobs for yourself and others?
    • Royalty / Investment Income?
  • Do you still think that you only need ONE Source of Income to survive in our current world?

I don’t expect that many people could manage all of these incomes sources (or others), but wouldn’t it be nice if you could maintain two or more of these?  And, IF one of your new income sources were to “dry up” for a time, wouldn’t it be nice that you could have the others to keep you going?

If the answers to these questions intrigue you, reach out to me for an initial free review: William (Bill) Gutches at 610.662.5658 or  or my new business email: .

My Social Media Web Presence techniques and Business Planning experiences coupled with your passion for your products and/or services have the potential to get you in a position where two or more of these income sources can be sustained.  Please let me know if you are interested in talking to me about these possibilities.

William (Bill) Gutches ► Social Media ☑ Web and Blog Content ☑ Income Search Coach ☑Business Planning Coach ☑ Contact Info: ☛  ☛  610.662.5658

Testing Centric Life Cycle


, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Could there be such a thing as a Testing Centric Life Cycle?

What would it have to look like to be Testing Centric?  Wouldn’t we have to ask questions of each Deliverable to prove that it somehow supports what we believe our end goal to be?  How would we construct these questions to ask of our Life Cycle Deliverables so that the answers would be good indications of our reasons to proceed?

Imagine if we were to create a Statement of Work (SOW) for a project intended to build a new business application for an organization.  If we wanted to TEST this SOW, what questions would we ask of it that could help us understand that its content was supportive of our end goals?

It might be possible for us to start asking questions about the Scope described in this Statement of Work:

  1. Does the scope indicate where our input data will be coming from?
  2. Does the scope explain how our product / application will affect the data?
  3. Does it show how the affected data will provide additional value over our inputs?
  4. Can we tell from the scope statement what external events and/or operators our application will have to respond to?
  5. Can we predict how we will have to maintain the data collected, modified, reported, used to accomplish the intended functions of our product / application?
  6. Is our design and scope Orthogonal?  (Not a trick question; read other portions of this blog!)

If we accept the notion that each Deliverable in the path of our project plan must answer questions that relate to its completeness and its alignment with previous deliverables, then the Test Centric Life Cycle Model can be strongly directed by the premise behind Orthogonality:

  • All modeling components MUST be reflected in all Other Modeling perspectives so that when each component and its related model components are removed, nothing remains in any of the models
  • Model perspectives should address, at least, the following disciplines or viewpoints:
    • Event Diagram
    • Process Diagram
    • Data Model Diagram
    • State Transition Diagram

Do you think, dear reader, that this thread of discussion should continue or be dropped?

Please Respond / Comment on this post OR Reply to me at

Thanx, bgbg

Orthogonal Dependencies


, , , , , , , , , , , , , , , , , , , , , , , , ,

  • When an Event occurs that your application must respond to
    • a Process is performed
      • Each Process takes the data from its Event and Stores it in a Data Store
        • Where its State is established
  • There are Data States that require your application responds to
    • By Performing a Process
      • Which collects the related Data and makes changes
        • Where the State of the Data records are changed
  • And there are Business Transactions that require your application to
    • Perform a Process
      • That gather relevant Data and makes updates to these Data
        • Where the State of the Data Records are changed

Build a set of models that leave no Event, State, Data, or Transaction without response and you have built a Complete Solution.