Oct 282013

I was recently asked the following question:

What was your intent for distinguishing data access and data transfer? – I failed to appreciate the significance, or the fundamental reason…

The quick and simple answer is that data transfers result in information being copied and data access represents interacting with information in situ.

The more elaborate answer goes into a little more detail and uses some examples to illustrate how each relationship is used.

Data access is primarily a relationship between behavior and information.  The behavior reads from or writes to the information in place.  There is no transfer of information or copies being made of the information.



The image above simplistically shows how a team performs the activity to the inventory levels stored in a computer system.  This is a good simplification which shows the main actors.  In reality, direct interaction by a team with the information stored in a system does not occur.  The image below shows what actually happens.


Here I introduced a functional access relationship between the Inventory Management Team function and the Inventory Management Systems function.  Note that the direction of the arrow on the functional access relationship indicates the most relevant direction of data flow.  In this case since we are talking about updating the product inventory, an update is sent.  This allows us to easily follow the flow of the information in the diagram.

Now to contrast data access with data transfer.



In the image above a copy of the inventory levels from the Inventory Management System is transferred over to the Order Taking System.  The product inventory levels are then used locally by the Order Taking System.  In a sense this depicts a caching approach at a systems level.  However, in situations like this it is more likely the Order Taking System product was built assuming a local copy of product inventory levels and the enterprise solution involved integrating the Inventory Management System with the Order Taking System using a data transfer approach.

If you want to go a little more advanced in your diagrams, I have found it is a good idea to differentiate between information records and information references or copies.  The image below is using the PrimaryScape extended notation, which is also really simple.  The information records in this diagram are shown in bright green.


The example so far has shown data transfer directly between two systems.  In many situations this is exactly the level of detail you want to capture and convey.  One can also use the data transfer relationship to show in greater detail how two systems are integrated.  The image below shows how an FTP server is used.  It also uses another extended notation to indicate transiently stored information.



Technically speaking the data transfer relationship is just a very useful shorthand used to keep diagrams simple and easy to understand.  The two images below shows you one simple diagram which simply shows what happens and another diagram which goes into the detail of exactly how the file is transferred.  Note that the second image does not use the data transfer relationship.





Hopefully this clarifies the difference between the data access and data transfer relationships.  To understand this difference and how to use these relationships appropriately is more important to those who create PrimaryScape diagrams.  When it comes to a greater audience it is enough to explain that the direction of the arrows used with the different types of relationships shows them the direction of information flow in the PrimaryScape diagram.  Most of the times this simple understanding is enough to get what a PrimaryScape diagram is intended to convey to a greater audience.

If you have any other questions feel free to email them to info@primaryscape.com.




Jul 182013

One of the great challenges for customers of enterprise software is to understand how a product truly functions.  Every product company has their own approach to visually describe their products to the customers.  Often this involved beautiful looking diagrams.  Some product companies are better than others when it comes to clearly conveying how their products work.  What is lacking is a general approach to “blueprint” their products in a way most customers understand.  Technical notations such as UML tend to be avoided as they are considered to technical and more likely to scare customers away or loose them because it requires an understanding of UML.

The PrimaryScape modeling notation is perfect for this situation as it strikes a balance between being able to express the most important concepts of a system (product) and simplicity.

I am going to give SalesForce.com some free publicity.  I got the information about their Sales Cloud product offering from http://www.salesforce.com/sales-cloud/overview/.  Using PrimaryScape I created a very simple diagram showing an example of how the Sales Cloud would look like with respect to one of SalesForce.com’s customers.



It is clear the Contact Management, Opportunity Management, and Chatter functionality runs within SalesForce.  The customers information (your sales information) is also stored within SalesForce.  The Sales Team is shown to be a part of Your Company.  The Email Server is used by the Sales Team to interact with Your Company’s SalesForce Org.  It is clear that other companies also have their information stored within SalesForce.com.  Ensuring that each customer’s information always is separate from every other customer is one of SalesForce.com’s most important protections.

Now this example may not be the best example of how to showcase a product, but it is one which is well known by most.  If anyone would like to collaborate on capturing their product using the PrimaryScape modeling notation then please contact info@primaryscape.com.  Until more examples have been built out this will be a free service offering.


Jun 182013

Architecture in the simplest terms is something which allows many people to gain a shared understanding.  I have found that this perspective on architecture maps to traditional construction architecture as well as the various fields of architecture which exist within Information Technology and Enterprises in general.

Reality based architecture is the idea that architecture can be based in reality.  A very effective way to create shared understanding is to create a model of the thing we are trying to understand.  Models are simplified representations of the real thing.  A model of reality makes it easier to see the whole thing and understand it.

It seems rather obvious that architecture should be based on reality so why bother writing about it?  In traditional architecture, of buildings, a blueprint represents the real thing intended to be built.  However, in software architecture the models which are often created are meta-models.  A class in UML represents a type, categorization, or class of objects, but not the actual objects themselves.  A class diagram show relationship between classes which actually represents the relationships between actual objects that is allowed and may occur.  It is not until the software runs that objects and relationships are created.  The same kind of meta-model approach is used for Entity-Relationship data modeling.  Entities represent Tables in a database which is the tabulation of records of a type, categorization, class, or entity.  The records actually represents the real instances of an entity.

The software meta modeling practice has heavily influenced architecture practices in both Information Technology and Enterprise Architecture.  The meta-model approach is great for capturing and describing patterns and reference architectures.

The meta-model approach is not as effective when we need to understand the current state of an enterprise, business unit, org unit, IT system, business system, team, project scope, or program scope.  This is where a reality based architecture approach which models the actual, “real”, things is more effective.

A simple litmus test to figure out if an architectural artifact is reality based or if it is a meta-model is to ask if it is specific to an enterprise, business unit, system, etc.  If it is specific to a context then it is likely a reality based architectural artifact.  If it is an artifact which easily could be used for a different enterprise, business unit, or system then likely it is a meta-model architecture artifact.

I am not arguing that meta-model architecture artifacts are not valuable.  There are many situations where it is the best approach.  As mentioned earlier it is great to capture and describe patterns.  However, if the goal is to describe the current state of a real thing or to describe the desired, tangible outcome of a project then using a reality based architecture approach is more effective when it comes to creating a shared understanding across the greatest number of people.  When a meta-model is used, people have to map the meta-model to their specific context and situation.  Mapping an abstract meta-model to a real situation and context comes easy to some and hard to others.  The point is a meta-model is not as effective in creating a shared understanding for the greatest number of people when describing existing things or tangible desired outcomes.

PrimaryScape was to a great extent created to make it easy to create simple, visual models of reality.  The key lies in its ability to show the complete picture, processes in context with information and systems along with teams.

Feb 082013

SIPOC is a tool to capture information about processes.  SIPOC is an acronym for Suppliers, Inputs, Process, Outputs, and Consumers.  A SIPOC is typically captured in a table or grid format.

Here are a couple of examples based on some quick google research.  Click on them to zoom.

wiki_example_sipoc example_sipoc LnL-Do-you-SIPOC-template
example_sipoc_table example_sipoc_diagram isixsigmaSIPOC
ref 1, ref 2, ref 3, ref 4


PrimaryScape™ can be used to capture the SIPOC process model.  The most simple representation using only the SIPOC terms is shown below.

PrimaryScape™ Basic SIPOC

However, this simple model can be elaborated to more clearly capture the concepts involved.  Input and Output is information which comes from and goes to the Supplier and Consumer respectively.

PrimaryScape™ Expanded SIPOC 1/3


The Process itself is realized in some kind of structure.  Showing the structure which realizes the Process help convey the scope of the SIPOC.

PrimaryScape™ Expanded SIPOC 2/3


The Process is triggered by an Input data transfer from the Supplier and it ends by transferring Output data to the Consumer.  However, most behavior tend to act on information and produce information.  In this expanded SIPOC model both reference information and transactional information are shown.

PrimaryScape™ Expanded SIPOC 3/3


PrimaryScape™ diagrams are also easier to explain by using a sequence of diagram snapshots.  The mini slideshow below is an example of using this trick.

These kinds of storyboards makes it possible to present relatively complicated diagrams while at the same time bringing the audience along step by step.  This greatly increases the chance that the audience will truly understand a complicated diagram.