Structure in Threes: Organizational Design

Business Structure verses Organizational Structure

One of the interesting issues that came across my desk today as I was discussing a colleague’s new venture was the taxonomy and ontology of our conversation.  She wanted to cover multiple concepts in the same conversation which is a notable goal regarding economy of one’s time.  However, it became apparent that the terms being used were being overloaded during the conversation.  Example: Discussing the Business Structure and Organizational Structure both terms were used interchangeably.  However, when I hear the words Business Structure I think of the legal form in which the business is established (Corporation, LLC, Partnership, etc.).  When I hear the term Organizational Structure I consider whether it is centralized or distributed; a partitioning along functional, product, customer or geographic lines.  As I continue to develop the Business Design Tool (see below) the question becomes how-to ensure that the dimensions are orthogonal to each other while retaining the interconnectedness of these dimensions.

Organizational Development Tools

Many of the recent texts define various dimensions such as complexity, market, size, etc.  However, the interconnection is only a Infographic.  Perhaps these interconnections are only a probabilistic connection leading one to only heuristics.  I will make a interesting systems dynamic study at the Center for Understanding Change when I have some spare time.  In the meantime I continue to develop the Org Design and Modern IT Portfolio Management tools which are looking more and more like an enhancement to the Business Analysis System and Environment (B.A.S.E.) application built in 1994 on MS Access V1.

B.A.S.E. at that time performed a variety of management consulting analysis:

This application will eventually become the basis for the semi-automated workflow for several of Intellectual Arbitrage Group’s practices and services


Old Projects and memories

During my office relocation project I’ve started sorting, purging and scanning files from my archive.  As I look back I’ve been on or lead lots of interesting projects.  I’ve been fortunate to have the trust of many brilliant mentors and executives, such that they gave me projects to challenge me or I was too foolish to say no.  Either way its been a great education and most likely shaped me into the creative thinker and researcher I am today.  This afternoon’s excavation brought to the surface one of my favorite projects which most likely started my journey thinking about language, enterprise as a biological organism, and eventually to the digital nervous system.  I think around that time I presented my Enterprise Linguistic –a Factor in CIM paper.

The project was a stretch assignment my mentor at IBM, Mike Kutcher, gave me based upon the group technology scheduling ad routing project I had built as Rockwell prior to joining IBM.  I was fascinated by the though of using various dialects or languages to solve specific engineering / manufacturing problems.  At that time Darpa and the Mantech program was still in operation.  Mike had volunteered me as principle investigator to come up with a neutral manufacturing language.  That brought me I contact with many brilliant people at IBM Research and around the corporation; Dr. David Grossman, Ricardo Conti, and Dr. Arno Schmackpfeffer to build an intelligent factory; one that would he its devices talk with each other to understand product requirements and determine how to manufacture the product itself.  The components I worked on was the creation of various parts of the device control, scheduling and manufacturing operation descriptions in a man-machine sensible form.  This eventually lead me to meeting John Sowa of conceptual graphs renown.  The POC was a success, but unfortunately research directions at Darpa changed so we never went forward with the full scale pilot.

Neutral Mfg Language

Is SaaS the Killer App for the CAD Industry?

 For the past few decades, the Engineering Software Industry has been experiencing a consolidation like many other markets.  If you read the trade press and analyst reports, the signs are that, like the Aerospace Industry, Engineering Software is consolidating down to a few major players in the geometry creation and capture (i.e., CAD) market segment.Under a CAD is the Engineering Market’s major segment backdrop the industry is ripe for a radical disruption.  The business model most major CAD vendors operate under –market share and maintenance annuities– is showing its age.  It will not be long before an innovative company will introduce a new business model and value proposition; one that is more closely aligned to current engineering and business priorities.This “Slywotzkyian” disruption is likely to drag this sleepy industry, content with advertising new CAD features with the zeal of GM and Ford discussing cup-holders in the 90s, full throttle from the 1970s into the 2000s as vendors seek to transform or be marginalized.

There are several low-key experiments testing various attributes of a potential new business model.  One new model that is gathering momentum in other related software markets is Software as a Service (SaaS).

SaaS provides many benefits to the Engineering community.  First, all the procurement and maintenance costs are put back on the vendor’s lap.  Second, Engineers need not worry about the process of updating their workstations and are freed to focus on design issues. Engineering departments will be freed from having to have a fulltime CAD system manager and programmer.  Third, the fixed costs of some hardware and software become variable expense; thus, as utility needs rise and fall, so do the costs freeing funds for other business initiatives.


This model is not without perceived pitfalls to be addressed before engineering firms and departments make it the dominant business model.

While upgrades and maintenance costs shift to vendors, this is not done without some loss of control and flexibility by the end user.  Those customizations engineering departments do on a regular basis will be significantly more difficult to achieve unless a major change to the code vendors provide enables Engineers to dynamically link their code to the base code in a loosely coupled environment.

Two other issues that may stall this model’s acceptance center on intellectual property: 

First and foremost, who will own the information and data put into these applications?  Will a vendor guarantee the safety, security, and reliability of the service and ensure only your company or designate has rights and access to it? 

With monthly scandals about identity theft, unauthorized data access and theft in the financial community, it does not appear that information technology has sufficiently addressed this issue yet.

Second, information transparency or data access; long a major point of contention between user and vendor, this issue is likely to become even more sensitive.  If a company stores its engineering information in a vendor’s system, what assurances are there that it can be taken out or migrated to another system should the need arise?                      

In today’s current model, data is locked up in proprietary formats in a vendor’s system with some minimal export capabilities.  For an Engineering firm to place its faith that all the information will be accessible, given today’s experiences, may be a bit optimistic.  Perhaps requiring a vendor to keep an up to date copy of the source code in an escrow account may mitigate the risk enough in a user’s mind, or maybe the industry will, like the financial industry, adopt a common medium of exchange.  ISO 10303 echoed such an objective but became mired in politics and missed its window to deliver.

With the advent of XML technologies and other graphical display standards it may now be possible to enable engineering models’ true transparency between systems by dividing the representation, presentation, and manipulation of engineering data into three loosely coupled technology stacks.  Some of these design approaches were proposed in the ISO 10303 Architecture Principles and Concepts Draft in the 1990s, but did not survive the vendor and time pressures to be implemented.  That could change given today’s open technologies orientation.

With these two major issues addressed, the SaaS model for vendors to host CAD services could provide a great opportunity to grow their business and reduce maintenance and support costs.  Vendors could gain a more intimate understanding of their customer’s utilization, needs, and priorities on a daily rather than monthly or quarterly basis, thus cementing a relationship between user and vendor, making it much harder for competitors to unseat the current vendor than what proprietary standards provide.