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.