Let’s CLOUD the Issue..

I just read an article about the word “CLOUD” being more of a verb than a noun so I thought I would add my two cents to this discussion and Cloud the issue some more.

This article was written by someone in a networking group that I have attended in the past and I will, hopefully, get to talk to the author again before too many people get my opinion about whether CLOUD is a verb or a noun.

However, to be clear: I disagree that this word “CLOUD” is more verb than noun and here’s why:

  • If CLOUD is a verb then what observable action takes place when someone ‘clouds something’?
  • If CLOUD is a place where data is stored by owners so that it can be retrieved later to multiple devices then it’s a place and that makes CLOUD a noun.
  • If moving to the CLOUD is a complicated process for an organization regardless of the size of that organization, then the process of moving data to a CLOUD is a verb but the location where that data resides is a place (again) and therefore is a Noun (again).

The other discussions in the article are very valuable and clearly prepared to advise other IT professionals on how to approach the issue of Cloud usage for an organization.  He provides a list of ‘fundamental truths of corporate cloud strategy’ that are worth applying to anyone who is involved in moving an organization into CLOUD usage with very solid reasons to make this change.

However, the premise of this article that CLOUD is a verb is the one point that I cannot agree with.

Because of this opinion I feel obliged to provide a link to this article and so that you can review the author’s credentials and make up your own mind about this; however, considering how far we have yet to go in creating a mature understanding of this CLOUD capability, I think this debate will continue for a long time to come.

The link, then, is:

http://bit.ly/vJBvNk

Thanx for reading!

Structure Programming – Advice from IT.Toolbox

The only point I disagree with in this article is about replicating code for readability!

DO NOT REPLICATE code ’cause it also replicates Maintenance Costs!

Other than that – Bravo to the author: Craig Borysovitch!

http://it.toolbox.com/blogs/enterprise-solutions/systems-development-structured-programming-guidelines-48980

 
bgbg

The First 90 Days

When I have been asked what I would do in the first 90 days of a new project as the Project Manager, my responses have typically included some or all of the following as a “Self-Orientation Start Up Plan”:

1) Gather the latest project documentation available from the following sources:
a) Portfolio Management files for priority, expected Return On Investment,         relative co-dependence on other proposed and active projects
b) Program Management files for direct dependence on other planned or active projects to determine just how much dependence there is on deliverables and work products from other projects
c) Process Management files for guidelines and standards for how projects are expected to be run for this client / customer
d) Project Management Files to determine if there have ever been similar projects run within this organization and for similar purposes
i) Collect available information on the Project’s / Program’s Scope, Objectives, Goals, Known Requirements and Risks from all perspectives
ii) Collect currently active Project Plans, Issues, Risks, Change Logs and Action Items for active related projects
iii) Collect current and recent Status information on all related projects that are under Execution during or before these first 90 days

2) Review the interrelationships between all available documentation AND
Identify the GAPS in this list where they are not available, not practiced by the client organization, or simply overlooked for this particular effort where others have complied more fully to the incumbent expectations
a) Prepare a list of what is missing, incomplete, or inconsistent in the existing documentation
b) Identify an initial set of Risks, Issues, and needed Action Items that should be acted upon before the final approval for this requested project is given to the Project Team
c) And Determine the recommended work required to complete these items OR get agreement that they will not be needed for this particular project (from the Sponsors, Funding Source, and the Steering Committee, at least)

3) Present and discuss what I consider the current ‘status’ and expected outcomes of the proposed project / program with the entire team of Business Sponsors, Targeted User Management, Steering Committee, Funding Sources, potential Team Participants, possible Third Party Vendors (and their current contracts) as a preliminary Kick Off Meeting

4) Come to an agreement on refreshed materials that satisfy the following Subject Titles:
a) Project Charter
b) Project Scope and Objectives
c) Project Requirements (High Level)
d) Project Budget and Schedule
e) Project Quality Review Schedule
f) Project Dependence on:
i) Third Party Vendors
ii) Other Projects and Programs
iii) Continued agreement on Priority and Delivered Value
g) Project Assigned Resources
h) Project Advisory Personnel
i) Project Steering Committee Members

At times, this information can be gathered in less than 90 days and THAT is a very positive sign of the health and potential success of the project that is being request. The longer it takes to find, understand and correlate these materials, the less likely this project is understood and therefore there will need more Risk Identification and Mitigation efforts to identify things we can learn about that might interfere with the desired successful results.

Orthogonal Views…

A current definition provides us this:

or·thog·o·nal   [awr-thog-uh-nl]
adjective

1.  Mathematics .
a. Also, orthographic. pertaining to or involving right angles or perpendiculars: an                 orthogonal projection.
b. (of a system of real functions) defined so that the integral of the product of any                   two different functions is zero.
c. (of a system of complex functions) defined so that the integral of the product of a               function times the complex conjugate of any other function equals zero.
d. (of two vectors) having an inner product equal to zero.
e. (of a linear transformation) defined so that the length of a vector under the                           transformation equals the length of the original vector.
f. (of a square matrix) defined so that its product with its transpose results in the                    identity matrix.
2. Crystallography . referable to a rectangular set of axes.

 

For Software Engineering, I like to apply this term to describe how two or more  conceptual models in different perspectives will net to Zero when components of an envisioned solution are checked off or aligned with one another.

WHAT does THAT mean?

There are four essential models that can be used to describe a business solution before it is actually specified, tested, or built:

  1. Process
  2. Data
  3. Event
  4. State Transition

When conducting the project phase of Analysis where Business Requirements are intended to be fully fleshed out, these models are used to capture the ideas and expectations that the users, sponsors, management, and technical contributors disclose to the analysts.

By reviewing and comparing each of these models to the others, we can create a list that has each component in each model aligned and “Checked Off” with components in the other models.  For example: A Process and an Event item should be found to describe the same business event from their modeling perspectives.  An Event should be aligned with the appropriate data components to determine that the event can, in fact, begin with a certain condition of the data and end with another.  The evolution in a row of data in a Data Entity should align with a State Transition that reflects and depends on this data transformation.

When each of these models is used appropriately and checked off against the others, every one of modeling components should be referred to and ‘checked off’ (none remaining unchecked)!

Hence, the “Orthogonal” and mathematical proof that a set of conceptual modeling drawings and their associated supportive documentation should net to “Zero” and prove that there is only ONE (and the same) solution being described by each of these models.

Ever Present Project Management Risks

Every project has Risks associated with the delivery of the Business Solution. These need to be discovered as part of the Project Submission process and continue to be anticipated and discovered during the ultimate execution and delivery of the requested business solution.

However, I also believe there are Project Management Risks that are inherent in the process of managing projects from the time they are proposed in a Portfolio or Strategic Planning phase through and including the delivery of the business solution that will be driven by the Project Management efforts.

My favorite list of these Project Management-specific Risks are:

1. Forward progress on an existing plan is at risk unless the team stays focused on the project’s scope and objectives and continues to work on the planned activities

2. Acceptance of Project Deliverables may be delayed by the Project Sponsors if they don’t understand the value, meaning, and importance of its content

3. Available Funding for the project may be recalled when other projects appear to be at a higher priority in the short term

4. Resources working on the project may be re-assigned to other projects if these other projects are deemed to have a higher need because of their timing, poor planning and / or management

Mitigation of these risks can be started as part of the Project Identification / Submission and Portfolio Management activities of each project before each is authorized for funding, resources, and a schedule; however, since these are ‘ever present’ risks, the measurement and risk assessment of these potential hazards must also continue throughout the execution of each project.

A very important early step in Risk Mitigation is Notification to all known participants and stakeholders that we will be identifying these items as Open Risks for the duration of the project. This communication is critical to set the expectations for the Sponsors, Users, Management, Technical and other specialized members of the project team, that we will be treating these items seriously throughout our project’s execution. These ‘ever present’ Risks should be added to the Business related Risks that can also be identified before Execution begins.

In parallel with this Notification of these and other more project-specific Risks, the team should be made aware of the tools and techniques that will be used to measure the impact of these Risks to the overall outcome of our project.

These tools can begin with several of the following approaches and activities:

1. Status Reports written in such a way that each detailed item in the report tells the audience what is expected to happen NEXT (see Risk #1 and #2) once each of the Status Items is included in the report:

a. EG. – The Communication Plan is complete and has been Accepted by the Project Participants and Approved by the Steering Committee.

i. This statement, although correct, leaves the reader thinking that there is nothing else to do now that the Communication Plan is finished. This is, clearly NOT what we want to leave them with.

b. Alternatively – Now that the Communication Plan is complete and Approved, the Project Management Team will begin calling the planned review meetings to measure the effectiveness of the Communication Plan objectives. During these meetings, the Sponsors, Steering Committee, and Participants will have a chance to suggest improvements or changes to the Plan based on our then-current experience.

i. This statement continues to report that the Comm Plan has been Created and Accepted, but it also outlines what must now be done throughout the project since this plan is ready for use / execution.

2. In order to successfully deliver scheduled Project Deliverables (see Risk #3), a Quality Assurance schedule must be established to review these deliverables as they are being developed to assure several things are true:

a. The Deliverable remains “In Scope” and aligned with the Project’s Charter and Goals

b. The Deliverable has not left out or added a new item as compared to earlier deliverables (Project Charter, Scope, Communication Plans, Technical Designs, etc.)

c. The Accepting and Approving audiences for each deliverable are aware of its content, intent, and value before each of these deliverables is ready to be presented to them as “Complete”

3. Regular reporting of the anticipated outcome of the entire project should be provided to the Sponsors, Steering Committee, and Participants so that they are constantly reminded of what they will be getting when the project is successfully completed. This will keep the anticipated value of the project’s results at ‘top of mind’ so that when other projects appear to be in jeopardy (See Risk #4), the decision makers will have the most current information about why our project should remain intact and on plan even if others are not able to maintain their momentum to their projected values.

a. Project scheduling tools and cost tracking capabilities will help to show how much progress has been made on each project against the plan along with predictions of the latest “Estimate To Complete” costs and time so that each project can be compared on, at least, this ROI or CBA level to support any decisions that might be considered for re-prioritizing or re-aligning resources from one project to others.

I assume that many of you have other ‘ever present’ risks attributable to the process and performance of Project Management itself and I would like to hear about them from you.  Please either provide a comment to this blog or send me an email with your thoughts at ‘whendoyoustoplooking@gmail.com’.

Thanx, bgbg

Remember Codd and Date?

These were two technology authors who were quoted on the subject of Relational Integrity and a Normalized Data Model.  Their ideas of reducing redundancy in the physical data schema and protecting the mandatory relationships between entities took a whole lot of attention about how to create, define, and manage data so that it was safe and intact for application usage.

They had rules and a syntax for defining data and a normalization process for creating a Data Definition Language (DDL) and Data Manipulation Language (DML) for all data necessary to support the functions of applications.

Use this link for a more detailed discussion on Normalization: http://en.wikipedia.org/wiki/Database_normalization#Free_the_database_of_modification_anomalies

Then, Object Orientation came along and added Methods, Self Contained Data, Anthropomorphism and some other terminology that, although valuable and additive to the definition of solutions, took our eyes off the ball of data modeling principles that are STILL fundamental to a reliable and cohesive solution to business and organizational needs.

Why have we let this happen?

The first computer bug – TODAY’s the day

Check this out about the first actual computer bug ever recorded:

http://www.computerhistory.org/tdih/September/9/

bgbg

Input – Process – Output

What exactly should a computer program do?  How will you know if the program you have written or requested to be written for you does what you need it to do?

It’s really a whole lot simpler than you might think.

If you, as a business user, can define what information is available to accomplish the automated task at hand (the purpose of the program).  And, you can define, in detail, the processes that are to be done using this available information (the calculations, manipulations, sorting, totaling, etc.).  And define the output results that this program should be expected to provide to you as the user, then you have defined the entirety of your requested program.

A program should only ever take INPUT, PROCESS it according to a business user’s specifications, and create OUTPUT requested by that user.  If a program tries to do anything else other than Process Input to create defined Output, then it is doing more than and probably unexpected things that no one asked the programmer to create.  This would be a BAD outcome.

The Software Engineering science of defining these specifications in these terms has been referred to as a IPO Diagram with three columns.  Can you guess what these columns might be?

IPO Table Sample v1 bg 20110812

IPO Table Sample v1 bg 20110812

If you try this at an appropriate level of detail, you should be able to get a clear understanding of how this can work for you in your business need; HOWEVER, remember that the amount of details you put into this effort will be reflected in the completeness and accuracy of the results.

Syntax of an ERD – Entity Relationship Diagram

Syntax Rules for an Entity Relationship Diagram:

  • An Entity appears as a Rectangular shape with a Name that is represented in the Singular for the subject of the data contained in this Entity.
  • A Relationship Line can be created between any two or more (or’s and and’s) Entities.
  • A Relationship MUST be valid and readable in both directions:
    a) An instance of {the first entity} MAY or MUST have {minimum to maximum} occurrences of {the other entity}.
    b) An instance of {the other entity} MAY or MUST have {minimum to maximum} occurrences of {the first entity}.
  • When the Relationship is Not Mandatory, the MAY will be used and the minimum will be ZERO.
  • When the Relationship is Mandatory, the MUST will be used and the minimum will be ONE.
  • When the Relationship is Singular, the maximum will be ONE; otherwise, the Maximum will be MANY.
  • The Cardinality {minimum to maximum} of these Relationships are sometimes shown on  these diagrams as numbers (0,1), (0, many), or a set of predetermined symbols.

An Entity Relationship Diagram Sample:

Use this link: https://docs.google.com/drawings/d/1keA4BzVCJXcUoNWDw7-0pIrQ7AsB5CgavjWR7P5Wyrg/edit?hl=en_US (may have to paste into a browser)

Business Rules derived from this sample are:

  • A Customer MAY have Zero to Many Orders.
  • An Order MUST have One and Only One Customer.
  • An Order MUST have One or More Line Items.
  • An Order Line Item MUST have One and Only One Order.
  • A Product MAY have Zero to Many Order Line Items.
  • An Order Line Item MUST have One and Only One Product.

It is also interesting to note that since there is no relationship between Customer and Product there are no Business Rules that can be derived between these two collections of data (entities), YET.

Process Modeling

Flowcharts, Data Flow Diagrams, Swim Lane diagrams, Use Cases and other constructs have been used to reflect what a Business or Systems Analyst thinks the client is describing when they talk about Business Process and the use of information in the conduct of their business.

These diagrams have structure, syntax, and rules that have been described through the work of authors, vendors, and users throughout their popular years and are still being applied today; however my concern is that these techniques and their principles are being lost in the more pervasive information about AGILE, Iterative, and other quick fixes to some pretty old problems.

Other related types of drawings or ordered lists that I have seen used are: NASSI-SCHNEIDERMANN Diagrams, Functional Decomposition outlines, Warnier-Orr diagramming, Jackson Data Diagrams.  Although these had value in their day, they were not as pervasive as some of the others process and program design diagrams that were mentioned in the first paragraph here.

So, What’s the POINT?  I think that software needs to be an engineered product and these techniques and structured diagramming tools are, to me, a lot like Blue Prints for construction of buildings with electrical, plumbing, HVAC, Safety and Security viewpoints, each of which have similarities in the construction of Software.  And yet, the more recent Software design techniques are focused on RAPID, Iterative, AGILE development that implies to me that current solution development efforts want to skip over those planning, analysis, and design activities while they still expect usable results.

For one, I don’t think this is a healthy evolution for our automated business solutions future.

If you are interested in seeing sample diagrams or starting a thread of conversation about these topics, please send me an email at whendoyoustoplooking@gmail.com – thanx, bgbg