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


Structure in Threes: Capabilitiy Models

Most of yesterday was dedicated to continuing to fix my wife’s IPhone contacts and syncing with desktop.  By 10pm I had finally reloaded a restored copy of her contacts to both laptop and phone.  Later today its back to AppleCare to restore her apps.  Apple is still suggesting using ICloud to sync multiple devices, but at this juncture its unlikely she will trust any cloud provider.  This has taught her a lesson businesses are either about to learn the hard way or have Enterprise Architects, like myself, developing disaster contingency and continuity plans prior to jumping to the cloud:  Technology changes that you run your business on require serious change management.  And even then the a poor implementation can require many hours to recover.  Another lesson or side benefit, she’s starting to see what my career really is about: enabling others,  preventing crises, and recovering from crises.  The unfortunate thing about the Enterprise Architecture profession is that goals one and two are what enables goal three, but goal three is the only one that gets other’s attention.

This morning before jumping back on IPhone recovery, I’m reading through the COBIT 5 management guide.  It’s rather odd how most standards, processes and models now take the form of the CMMI maturity model.  While I’m a supporter of the maturity model construct it has it’s deficiencies or rather I should say poor adaptation of the concept leaves deficiencies in the applied domain.  Often I’ve seen various organizations adapt the maturity model construct for their domain of expertise but as a marketing tool to infer gaps which their product or service naturally fulfills.  However, these capabilities are often not completely filled by the product or service as the capabilities have to be built with these tools, knowledge, processes and behaviors.

The COBIT 5 generic capabilities model points to level characteristics, level generic enablers, and generic level enabler capabilities.  However, it appears the rating of conformance is a subjective exercise.  May be that is acceptable at present as this field become more defined.  However, linking performance to organizational design then become more subjective also.  It may be the design methodology I’m working on will have to include the concept of tolerance and performance ranges (similar to physical product engineering) for the results of selecting the various design attributes.  I’ll have a better handle on that when I encode the governance model into a spreadsheet and link it to the organizational design spreadsheet.  The results should give me a more robust assessment criteria as well as a diagnostic tool for clients that will guide them to a more specific areas to address rather than a shotgun approach.


Office365 Small Business

Installed and started to configure Office365 Small Business Premium yesterday.  A little buggy and limited on guidance.  Still have a lot to cleanup on configuring; Issues with ID or Email Address, etc.  Guess that means there’s a market for someone to write a “how-to” book on install, configuration and operation.  Of course this has been one of the major deficiencies in Microsoft’s Business Model.  They can tell you how to flip switches on the product, but not how and why for your business.  The entire ITSM concept for Microsoft is still primitive which is why I keep getting questions from friends & family on how-to manage their IT environment.  Additionally that last several engagements I supported behind the scenes, customers where asking for the Microsoft equivalent of an IBM Redbook.  Unfortunately my old group was not chartered to fulfill such a request despite the growing need.  This suggests that when I’m finished my first book project, I start on a IT Operations Methodology and Guidebook similar to the Strategy and Market Planning methodology IP I developed for other Global 100 corps.

Today’s agenda is more physical office clean-up, troubleshooting structured wiring system, and Structure in Threes book layout wireframe design and if time permits back to configuring Office365 Small Business (wireframe layout for external site)

Pay me now or pay me later

The more things change the more they stay the same or so goes the old yarn.  Researching life cycle cost again for a paper I’m working on.  Found the often referenced but not often credited Iceberg and total cost commitment diagrams.   These were based on several studies from the DoD,  related components and documented in Design and Manage to Life Cycle Costs, B. Blanchard, 1978.  Most of the TCO discussions today are based upon the insights revealed in this book.

The unfortunate fact about this book was that the core message was never addressed by industry; Design Decisions determine overall costs and therefore should require special attention.  Today there is much talk about Cloud, reducing costs and converting CAPX (Capital Expenses) to OPEX (Operations Expenses).  If not considered carefully, switching from an On-Premise solution to Cloud will cost an Enterprise more and not provide the benefits anticipated.

This is not to say Cloud is not a valuable strategy.  Much to the contrary.  However, to really take advantage of the elastic nature of Cloud requires planning.  Planning on how to optimize the technology, utilize the elasticity it offers and mitigate the risks.  Without investing the time and effort it becomes not an opportunity but a pay me now or pay me later situation

Markets, Market Planning, Marketing, Business Development and Sales

I’m in the process of considering going out on my own again, after almost two years with a small “boutique” firm. The exercise in trying to help them grow had its pluses and minuses. One of the insights I already knew, but this experience provided a more current data point: Without an ongoing effort every day to identify opportunities, move those through a sales pipeline to eventual close your destiny is bleak. A lot like sitting on the wrong end of a tree branch and sawing away. You may feel you’re making progress but you’re actually undercutting your future.

With that said, I wonder why the message at the executive level didn’t take on a sense of urgency until it became a crisis. In the past when I consulted to Senior Executives they were well aware of this insight, they just didn’t know how to go about it, so it was easy to lay out a simple structure each could grow with. I happen to like Keith Eades book, The New Solution Selling. He refined Bosworth’s principles down to a implementable process for large organizations. Corporations such as IBM and Microsoft have created and deployed customized versions of such, I had assisted in those efforts.

However, for small businesses the approach was not scalable down. Over the past few years I’ve taken the core concepts and reengineer these into a family of tools which I’ve posted onto Microsoft Office Templates Online under my corporate logo Intellectual Arbitrage Group. These are available for free for a limited time, as I’ve been informed the site will be taken down in October. While distribution for free from Microsoft will not be available I will still freely distribute in the future.

But with the advent of the Cloud; Azure, Office365, etc. I am in the process of designing a service that will integrate these core functions into a system that will enable small businesses to manage the Marketing and Sales function at or beyond the level that corporations struggle to attain or maintain. While it will not be as sophisticated as systems I’ve done for these larger corporations effectiveness should raise for these firms an order of magnitude. Originally I had planned to release a SharePoint version, and I still might, but a Cloud Service makes more sense to address the small businesses I’m so fond of

More Cloudly Issues

With Microsoft suffering another outage with Office 365 potential enterprises must again evaluate the risks involved with going off-premise to the cloud.  I will not debate the proposed benefits of going to the Cloud.   The magic transformation of CAPX to OPX has to have every CFO pulling out their spreadsheets and CIOs examining the possibilities of elasticity.

These do come at a cost.  Increased risk.  While the infrastructure behind the cloud maybe resilient –depending upon the architecture used to implement the solution– Internet Access is still a potential single point of failure.  There are multiple places in the communications channel where glitches could take down an entire enterprise.  

Imagine your gateway is down.  On-premise this is not a problem, end users still have access to services behind the firewall.  Another possibility your provider is down, again access to all your services is at risk and then in the case of this latest glitch, and unconfirmed network appliance on Microsoft’s premises took the service down for three hours.

This is not an article bashing Azure or Office 365.  As an Enterprise Architect I find Cloud and specifically Azure a useful approach.  Actually before Cloud was Cloud I was writing articles about Virtual Corporations using the Internet to create a virtual service infrastructure between corporations -and had demo’d some of these concepts at Autofact and prior to that discussing the digital nervous system at IBM Guide/Share conferences in the 80’s.

But like any tool its only as good as the skilled hands that use it.  What I mean by that is when considering a move to the Cloud multiple factors should be considered beyond reducing cost.  These factors need to be weighted carefully at the enterprise level and brought to the attention of business executives.      

 About a decade ago corporations when through a scare called Y2K, may companies spent millions on prevention.  One of the large Fortune 500 corporations clients I had the meter spinning with all the contractors they brought in to fix the possible issues.  They were concern that they were wasting money by the truckload and asked me to assist.  I developed an approach, or rather adapted a systems engineering approach [FMECA] toward Enterprise Architecture to help prioritize which systems to address as well as the urgency for each.  I later incorporated it in a revision of the Enterprise Architecture Methodology I co-developed and use today.

Simply put, looking at the Enterprise as a biological entity with various systems that support its health gives you a different perspective on the factors involved with cloud, on-premise, hybrid, etc.  Once this perspective is used multiple factors become clear as to the tradeoffs that should be expectedly address.