Should you fire your CEO as part of the company’s next RIF?

It’s the next corporate off-site, the stock price is down, revenue is down, and margins are shrinking. The new CEO has had approximately one to two years in tenure. His recommendation to the board to “save the company and boost stock price” is to rebalance the workforce aka Reduction in Force (RIF). After several years of building up the workforce, capabilities, knowledge, and skills this seems the logical thing to do from his perspective. Lay off workers and get newer, cheaper employees. This is after stating its employees are its most important asset.

But is it? A decade or so ago several Blue-Chip corporations did such. Stock market reacted, as it does quickly with a momentary boost. However, as the years went on, the corporation’s product quality, customer service, and eventually its competitiveness dropped.

Solution? Hire back seasoned professions they laid off. Only problem, those employees when on to competitors, became competition, or now will cost the corporation more to hire back and will likely not have the same loyalty they once had (i.e., it’s now just a job not a career; they’ve learned from millennials all too well).

Given this state of affairs, should stockholders and the board consider laying off the CEO as part of that RIF also? Consider the statement: “Employees are our most important asset”. If so should the CEO be judged rather harshly for losing a large percentage of the corporation’s assets and value?   If intellectual property is really of value as inferred tens of thousands or possibly millions of dollars have walked out the door.   Would an executive at any company still be in place if they allowed a factory to be sold off for pennies less than what could be sold on the open market?

In the declining age of Superstar CEOs maybe a rating/tracking system is needed similar to those in professional sports leagues to see if those CEOs really do add value? Just a thought to ponder as I consider where to invest my retirement funds…

Structure in Threes: Revised Preface and start of Part One/Chapter One – An Architect’s View of Organizations

PREFACE

It has been close to thirty years since John Zachman coined the term Enterprise Architecture and introduced business to the Zachman Framework. Over the years, the metaphor has been used and abused, technical religions have grown around methodologies and still the term Enterprise Architecture is derisive.

  • Is it an activity that produces a plan for building various systems?
  • Is it the actual plan for an Enterprise?
  • Is it a methodology to produce standard compliant designs?
  • Is it a collection of diagrams that represent different types of information about the information systems used in an enterprise (the Zachman Framework Aka Ontology)
  • Or maybe a specific set of standard components organized in a specific structured way

When I started the initial concept for this book years ago, I had considered creating a text that would provide methods for designing an enterprise; this being the goal of Enterprise Architecture or at least my belief is the goal. However, over the years’ experience has taught me five things:

  1. Nothing is simple when explaining yourself; a lesson taught to me by John Zachman
  2. Words have different meanings depending upon the context and experience of others; a lesson taught by Michael Kutcher, John Sowa, Gil Laware, and Frank Kowalkowski
  3. The difference between a methodologist and a terrorist is that you can negotiate with the terrorist; a lesson taught by IBM CIM Architecture Department and TC184/SC4 & SC5 working groups
  4. Thinking in the abstract and in multiple dimensions while technically possible by most, is often avoided in most enterprises in the name of speed and comprehension; a lesson taught by most managers and mid-level executives I’ve had to deal with
  5. Nothing is foolproof as fools are so dam cleaver and Nature always sides with the hidden flaw; Murphy you were an optimist

Those insights came to light over the years of associating and working with those I consider giants and mentors in the field. Included in this book are vignettes of how those insights were developed; if for no other reasons than to pay tribute to my mentors and colleagues and to establish part of the context for the content in the book.

That being the bedrock I started building this work upon, I realized I needed to answer several questions first before I introduced my approach to Enterprise Architecture. The book itself is meant to be a practical guide on “practicing” Enterprise Architecture, a theoretical text explaining my perspective on what Architecture or more specifically Enterprise Architecture is, and how these fundamentals are expressed in practice.

Why Structure in Threes

Structure in Threes praxis guide toward the design of enterprise based upon a fusion of several concepts:

  • A classic work from Henry Mintzberg, Structure in Fives, on strategy
  • My original research and training in dwelling architecture from works by Vitruvius, Soleri, and Christopher Alexander
  • Studies in Systems Theory from works from von Bertalanffy, Checkland, Forrester, Meadows, and Weinberg
  • Studies and learnings from John Zachman

The title is meant both to honor Mintzberg’s leap of using a spatial reference to describe an abstract subject as well Zachman’s ontology that defines a multi-dimensional problem space that is enterprise.

About this book

This book is both a stand-alone work as well as a companion text for an educational curriculum taught by the author. The sole purpose of both book and curriculum is to raise the knowledge and skill level of practicing architects and associated stakeholders. While it will reference a methodology for demonstration it should not be construed as THE sole approach towards developing a praxis.

Simply put I am not intending to form yet another priesthood in the field. There are many paths to this destination and fulfilling the goal of designing an effective enterprise.

Part One – Theory and Methodology

 

An Architect’s View of Organizations – creating a coordinate system for an abstract space

In 1997 I had published an article “What is Architecture” to lay out the context for the full problem space I believe enterprise architecture should cover. In this article, I recounted an earlier discussion with several IT provider executives that I worked with. Primarily the dispute was around the representations of architecture, but quickly moved past representations to what architecture is.

My opponent in this discussion strongly advocated documenting a set of components in a hierarchy. “Here the architecture is these six devices connected together by this specific network type. That’s the architecture” He’d laid out a hierarchy of computing systems that looked much like an organizational hierarchy; One master mainframe at the top with a descending hierarchy of smaller and smaller mainframes, and eventually workstations or personal computers.

I had asked what was the rationale behind using a hierarchy and the selection of each component type at each level. The response was a blank stare. It was though I was speaking Martian to him. Then suddenly a rather heated response back. “O.k. tell me YOUR definition of architecture”.

Without trying to escalate what had become a heated situation I fell back to my original training. “There is a difference between architecture and design. Many people use the term architecture when they really mean a design….an architecture are the rules for the selection and usage of components and/or elements to achieve a stated functional objective. These can be structural and non-structural such as light & shadow, space, stone, glass and wood. This how these components are selected, used to fulfill an objective is the architecture. The actual instance of using these are the design.”

Defining the problem-solution space

From that discussion and the Zachman Framework I came to the conclusion that to effectively design and construct an enterprise one really needed to visualize this conceptual entity, Enterprise” in an abstract multi-dimensional space. A similar concept to how architects use the dimensional metaphor to define dwellings. What is missing in those dwelling visualizations (designs) are the rules that were used to create those designs. That is the architecture that was developed inside the head of the architect during his/her education and practice.

However, in discussion of those components, elements, and rules has not been a topic of discussion in most Enterprise Architecture narratives or methodologies. Instead what has been taught and discussed has been documentation/representation practices. This is equivalent to teaching drafting standards. And when rules are discussed it typically has been around sizing of components, not selection and use. Occasionally one gets into discussions around implementations: Mainframe vs Network, Network vs Cloud, etc. These are typically religious wars from vendors attempting to justify why their products are better or inclusion in the latest technology theme.

Hoping to avoid such conflicts, the first part of this text is aimed at providing the theoretical foundations for the reader to move past such religious wars by establishing the coordinate space for discussions on why and in what context to select and use.

Strategy, Resource, and Structure – the three dimensions of Organizations

Keeping with the theme of threes I believe that Strategy, Resource, and Structure are the primary dimensions of this abstract space where enterprise can be defined. This may seem to go counter to the Zachman ontology, however, if one looks at the ontology in an architecture context, the various dimensions are actually views of an enterprise. Thus, each box in the framework is a projection of one or more of these primary dimensions.

Class Structures in Dimensions

One other aspect of these primary dimensions is that each is actually a family of instances based upon the context in which these are used. A simple example, there are corporate organizational structures, software structures, business structures, etc. Each describes the arrangement and relationship between components. These will be discussed further in each dimension section to follow.

[Preview/Outline] Constraints in Design – Money Changes Everything

  1. Money is both resource and measurement system for the game
  2. Perishable Resource -Time the one resource that can’t be stored for later use
  3. People – the multiplier resource

Speed, Simplicity, and Results – an equation that often doesn’t balance

How often have you heard in the context of entertainment, he or she was an overnight success? Only to find out later it only took x numbers of years to become such. In an Internet age everything, everything appears to be instant including out coffee.

The Internet brings us everything instantly, or so we think. How long did it take you to get that book from Amazon Prime? Two days, not fast enough! Get a Kindle and get it immediately! However, what are you missing with all that speed? What are the trade-offs? And yes there are tradeoffs.

Like old lessons in engineering, nothing is free, one always has tradeoffs to balance the physical equations. You may not see these or be conscious of these, but these are still there in the background being made. Which is the main point of this article.

It may seem from the start that some old guy is about to pour his heart out about how good times past were. -And yes, they were good. However, what Millennium isn’t already reminiscing about that great time they had at the club last night or even brings it up several weeks later as their friends roll their eyes having heard the story for the fourteenth time already. Good and bad times cement lessons in our memories. But I digress.

Years ago, before PMI existed, project managers latched onto the concept of the Project Management Triangle: Time, Cost, Quality -picking any two dictated the other. Heuristic Functions like this are applicable today as much as we’d wish the Internet would change these.

I’ve working on several projects over the past few years –well decades—each a part in a much larger equation. My previous article, The Virtual Situation Room, hints at such. One fragment of that equation involves Business Intelligence as it’s called today. That is having not only data but information for decision makers to make effective investment decisions within the business. I consider N. Dean Meyer’s Internal Market Economics as a data point in the growing digitization of business.

As such any resource decision –Capital, Intellectual Property, Human, Equipment, etc.—is a statement of internal investment priority to address what Milton Friedman stated as business’s primary if not sole justification: maximizing shareholder value. [While I disagree with the total adherence to economics of selfishness, it is the current trend in business, but I see the pendulum swinging in other direction, hopefully to some middle ground.]

Current Internal Economics aside slightly, I come back to the engineering premise that tradeoffs are made in any decision to balance an equation, often unstated. A brilliant colleague of mine Dr. David Ullman, out of the Oregon academic society, attempted to explicate much of those tradeoffs using an application of Bayesian Analysis. Only to end in frustration. The Business World was not ready for such ideas 10+ years ago, nor the work involved to get those “simple answers”.

Speed is a relative term in Business. What is fast one day, is tortuously slow the next.

Simplicity is also relative and is based upon context. What I see readily apparent, maybe intricate and complex to you.

 

Thus we’re left with Results as the great common ground, or so one would think. However, results are based upon expectations, experience, and context. I order a meal at a restaurant. They serve me my food within a ten minutes, I eat it and don’t get food poisoning. Is that the result I was looking for? Was it satisfactory? Before you answer consider these two scenarios both fit the facts above. First I was at a Fast Food place, the second I was at a 5 Star restaurant.

If all my expectation was to get a quick meal and move on, then a Fast Food experience was adequate. If, however, I was with others and make this also a social experience the above maybe lacking.

So what does this have to do with internal business projects you’re asking now?

Consider the nature of questions leadership has to address. These are often boiled down to quick decisions: Go, no-Go, and Redirect to consider later. They are often looking for simplicity to enable speed in decision making. However; first simplicity often hides important information, and second I’ve always found it takes time to create simplicity. Boiling data and information down to its essence means understanding the truth nature of the decisions to be made and the interactions of variables in that decision.

This morning I am on the 10th iteration of a Portfolio Management initiative I came up with in ’95. I am using writing this article to reflect and document lessons learned for these activities for an upcoming paper for a June Business Architecture conference in DC.

A few insights I’ve come up with this morning as I look back on the various version of this initiative are:

  • Decision-Makers appear to have less and less time to assimilate the information
  • Simplicity is good for speed but often hides the icebergs ahead; so these captains of industry need someone in the crow’s-nest to look ahead
  • Decisions are often made by gut feel, even though analytics has proven to be more accurate
  • Follow-up on results while desired is often not accomplished: Many organizations are professing a learning culture, however the current state of being is most reviews are still flagellation inquiries [management is still a political game]

Business Architecture

There is a lot of “Architecture” out there in the enterprise world?  It seems that the title ARCHITECT once held a lot of cachet.  You’d find someone titled or a book titled with the term architect in it almost everywhere.  However, during my most recent deep dive into the term applied almost all –IMHO– were not architects but designers and in many cases project managers.  I reached this conclusion based upon the definition I used to define architecture.  That definition has as it foundation the understanding of the components, interactions and uses of such used to create a desired entity.  That entity can be as concrete as a house or as abstract as an enterprise.  Which has led me to an interesting linguistic puzzle:  In many organizations and associations there has been a stated difference between an Enterprise and a Business architect.  Yet isn’t the definition of enterprise a business?  So rightly so shouldn’t an enterprise architect be a business architect?

With that puzzle aside, I again started to ponder my activities around Portfolio Management.  Much of what I’ve seen and experienced in large corporations in regard to Portfolio Management has been around economic prioritization.  That is “We has a fixed budget, how can we spend it all to receive the greatest return on each individual investment?”  This inevitably results in a effort to stack rank projects by simple ROI or in the case of IT projects KLO (keep the lights on).

Most recently I watched several organization build up a portfolios (aka backlogs) of projects to be prioritized and executed.  Many of these projects were classified as either KLO or Innovation projects which were given the highest priorities depending upon who in executive leadership was overseeing.  However, deeper investigation revealed that these where neither, but rather what I would call optimization projects (see portfolio management project portfolios).  While not a bad thing doing such gamesmanship results the enterprise as a whole not achieving the optimum return on investment strategy.  That is to say senior leadership has developed a strategy and middle to lower management, though well meaning, compromises achievement of such through their efforts of local optimization.

The way out of such conundrums is not having senior leadership make every investment decision down to the smallest detail though.  My belief is the best way to ensure investment optimization for the enterprise is to make the business architecture explicit and develop a consistent means to determine alignment, interdependency, and priority of current and future desired states.  Though looking at the existing enterprise’s state as a whole — what needs to say the same, what needs to change and when– an optimum path to an uncertain future can be charted.

The problem with such an approach is that it is often looked upon as complicated, thus is rejected out of had as lately the management trend is make things simple.  Which is rather ironic given we are in an time of multiple priorities and the second generation of the information age.  Such thinking is both comical and disturbing, given that many high tech companies are pushing products for Business Intelligence and Analytics to gain actionable insights yet they are still managing their own investments with nothing more than glorified spreadsheets.  Maybe I should not be so critical of the state of industry, given how long it has taken other engineering and design disciplines to mature into well understood principles to be applied.

In either event I’m now about an eight (real swag) through defining a comprehensive enterprise design methodology and associated curriculum for the book.  In architect-speak, I’ve laid out the rough framework and have started construction/acquisition of components for the methodology.  Two moths in, I may have to push back my anticipated book completion date.  One the positive side my employers will gain the benefit of this research and hopefully be able to apply it to their advantage.

 

Enterprise Portfolio Management -Thoughts and Insights

Woke up early this morning to the buzzing in my head…An idea that Options Theory as currently applied within more sophisticated enterprises for IT Investment was off the mark.  I’d spent the past year going through application of approaches such as Black-Sholes which for external markets tracks well.  However, for IT Investments there is something slightly askew.  That uncomfortable feeling of what and how finally popped in my head this morning.

Several things about the standard approach to Investment Markets Options Theory rely upon market forces to determine value.  However, within the Enterprise Ecosystem value is not measured by standard economics of buyer/seller in the traditional sense.  Arbitrage in the market does not apply in the traditional sense.  The investment is either exercised for its perceived utility or not; typically based and prioritized upon return on investment of the asset (in the broadest sense of the word asset).   In corporations however there are two economic systems at play:

  • External Ecosystem, the one in which the enterprise participates in.  Here the economics that investment professionals typically discuss and where options theory approaches such as Black-Scholes apply.  One can apply hedging as in Black-Scholes to capture the best Risk/Reward.  Within this ecosystem market dynamics have investments flow between investment vehicles based upon perceived future value.  With items other than perishable commodities the perceived value is not always inline with standard accounting practices.  When valuation of corporations occur Intangible assets such as “Customer Good Will” and “Intellectual Property” are used as a filler to account for the difference between residual value of physical assets in general accounting practices  (i.e., cadaver accounting) and investment accounting.
  • Internal Ecosystem, a set of economics that is governed more strongly by general accounting practices; costs and benefits must somehow be in balance.  However, a semi-closed system is assumed within such an economic system.  That assumption is later adjusted each quarter or year by increasing an Intangible Asset valuation on the books.  This ecosystem is driven by several factors: Asset Depreciation and Utility Value of Assets deployed.

These two economic systems interact through several interfaces of which not all are visible or easily measurable.  Monetary funds go into the Internal Ecosystem from the External Ecosystem on the assumption that these funds will be used to purchase assets and through utilization of these assets return more or increase in value the enterprise.  This in the external system takes the form of stock price or dividends.   Which in many US based firms now provides a stronger drive to the internal dynamics of a publically held corporation.

However, the value of individual assets inside a corporation is not as simple as those in the external ecosystem.  Inside the corporation assets are combined with a purpose in mind, to create a utility value.  While the individual assets are accounted for in general accounting practices the utility value of a configuration of assets is typically not.

An example; a machine is purchased, a process developed to use it and others to create a product or service, supplies/consumables are also purchased, and people trained to create and sell the product / service.  This creates some value if the product or service is consumed by the external ecosystem in exchange for revenue.   Ten years later the internal assets have been depreciated in value to zero, yet the enterprise is still getting utility value from this configuration of assets.  One year later a competitor’s product / service attracts enough consumers to make the enterprise’s offering unprofitable.  The assets once providing utility value, though zero accounting value through depreciation, are now in negative territory.  Now we’ll complicate things.  One of the assets in the configuration was a computer.  It can be reassigned to do other tasks thus extending its utility value in another configuration.

Thus the value of assets in an internal ecosystem’s portfolio needs to be managed differently.  Those management practices need to more strongly account for internal utility value that it contributes within an hierarchy of abstract portfolios that support an enterprise’s participation in the various value streams in which it is a member.  That insight realized this morning has been what has been driving me to revise the portfolio management practices I had defined for previous employers –though better than none– seem not adequate for the task.   With that insight in mind developing the economic methods –for what I’ve called Level 5 Dynamic Management that are closer aligned to how an enterprise operates internally– appears more attainable and palatable than just inserting a standard Black-Scholes model.

Structure in Threes -the Preface

Decided to start a little early actually writing the book.  I know by the start of next year I’ll have restructured the original outline to better address the objectives I have, but I though several chucks of material could be written as these are unlikely to change much in the later editing process or will just move to new locations in the book.

PREFACE

It has been close to thirty years since John Zachman coined the term Enterprise Architecture and introduced business to the Zachman Framework. Over the years the metaphor has been used and abused, technical religions have grown around methodologies and still the term Enterprise Architecture is derisive.

  • Is it an activity that produces a plan for building various systems?
  • Is it the actual plan for an Enterprise?
  • Is it a methodology to produce standard compliant designs?
  • Is it a collection of diagrams that represent different types of information about the information systems used in an enterprise (Zachman Framework)
  • Or maybe a specific set of standard components organized in a specific structured way

When I started the initial concept for this book years ago I had considered creating a text that would provide methods for designing an enterprise; this being the goal of Enterprise Architecture or at least my belief is the goal. However, over the years experience has taught me five things:

  1. Nothing is simple when explaining yourself [Lesson taught by John Zachman]
  2. Words have different meanings depending upon the context and experience of others [Lesson taught by Michael Kutcher, John Sowa, Gil Laware, and Frank Kowalkowski]
  3. The difference between a methodologist and a terrorist is that you can negotiate with the terrorist [Lesson taught by IBM CIM Architecture Department and TC184/SC4 & SC5 working groups]
  4. Thinking in the abstract and in multiple dimensions while technically possible by most, is often avoided in most enterprises in the name of speed and comprehension [Lesson taught by most managers and mid-level executives I’ve had to deal with]
  5. Nothing is foolproof as fools are so dam cleaver and Nature always sides with the hidden flaw [Murphy you were an optimist]

Those insights came to light over the years of associating and working with those I consider giants and mentors in the field. Included in this book are vignettes of how those insights were developed; if for no other reasons than to pay tribute to my mentors and colleagues and to establish part of the context for the content in the book.

That being the sand I started building this work upon, I realized I needed to answer several questions first before I introduced my approach to Enterprise Architecture. The book itself is meant to be a practical guide on “practicing” Enterprise Architecture, a theoretical text explaining my perspective on what Architecture or more specifically Enterprise Architecture is, and how these fundamentals are expressed in practice.

 

Portfolio Management Insights: Opportunity Gap

This morning’s R&D had me reviewing some previous work on Expected Commercial Value calculations.  One of the flaws or should I say weaknesses at lower levels of Portfolio Management Maturity is a the assumption that delaying a project only shifts to the right when a project yields value.  This however is most often not the case.  When evaluating each project’s value for a Portfolio one needs to account for both NPV of funds expected, NPV of funds received, AND also a potential reduction is value received as a result of a short recovery period and project lifecycle.

Consider this first scenario: Buying a new automobile.  While the utility may not change on a new vehicle purchased towards the end of the year its market value certainly drops as one gets closer to the next model year.  Another scenario: The utility value is sensitive to when in the lifecycle a initiative is executed (e.g., having a large shipment of ice cream available for summer in New York vs. fall).

As such Enterprises with more mature Portfolio Management capabilities will consider this factor in portfolio decisions.

Opportunity Gap