Methodology Engine for Consultants

Early wake-up call…well not actually early for me.  Today’s agenda: More Data Mining and evaluating the best course to capture methodology for my consulting firm.   Four primary factors to consider: 1) Knowledge and Skills transfer 2) Job Aid and Execution support 3) Ease of maintenance 4) Accessibility for field consultants

In prior roles I help construct or constructed my own methodology engines for various domains: Marketing Management and Strategic Planning, Enterprise Assessments (e.g., ISO 9000, CALS, etc.).  Depending upon factor four the technology choices I had narrowed down to were: Lotus Notes, SharePoint, and MS Access.  Of all the platforms to build on, MS Access was the most popular as one could carry the engine into a client’s site where Internet access was limited.

 

I was consider a hybrid on desktop MS Access and Access Services, however, given the uncertain future of both I’m considering another option such as Pega which would have the accessibility limitation pointed our prior, but gains an orchestration engine and data consolidation of multiple engagements for future BI application.  However, to kick start the project I’ll likely use the Methodology Engine I created in ACCESS as it has the basics to capture the workflow, methods and R&Rs

Philip K. Dick was right but may be wrong also

For those who are not Science Fiction fans, Philip K. Dick was a writer of notable insight to cultural trends.  His books have later been turned into blockbuster movies: BladeRunner, Minority  Report, Total Recall,  and Next to name a few.  His books had a dystopian perspective to these, where governments and social agents become tyrannical.   I will not dwell on that forecast of the future of society is this post.  One interest concept I thought interesting was his focus on media.  More specifically how the media would change.  Though the movie adaptations only hinted at it media, print for example, changed from a primarily word based format to more of a graphical based one.  Well the saying goes “One Picture…”

When moveable type was created it did two things. First it made production of information cheaper.  Thus distribution of information increased and was made available to lower income people. Second, it changed the cost ratio between text and graphics.  When books were hand drawn, the cost of graphics was on a par with text.  This ratio changed only slightly over the years until the application of computer technology.

What is interesting about this was that prior to the movable type revolution much communication was through pictures and other symbols.  Dick’s prediction of the future was a return to graphical communication and a reduction in text.  This inferred a lowering of grammatical literacy within society as a whole.  Having just complete several Government RFP response marathons where reply instructions were specific about writing to an 8th Grade level that would seem to prove Dick’s point.  However, I took a few steps back in considering such.

What came to mind were presentations and proposals I’ve seen and participated in over the years.  Many times I was privy to executive decision-maker sessions.  What struck me over the years was how these sessions have changed.  Initially presentations and proposals were fully of textual information.  A slide or page was filled with paragraphs of descriptions and opinions.  A little later after spreadsheets had become the go-to business tool, these became filled with tables of data and charts.

Then as graphic software became more capable presentations in many companies became more simple and focused.  A term which was not originally meant to be complimentary became popular code for these presentations to executives: “Big Animal Charts”  I suppose this was because someone thought reducing issues down to the simplest concept was similar to old children’s books; “See Spot Run, See Tiger run…”   A sort of arrogance was hidden in this comment lay just below the surface.  That is “I’m the expert and you’re not.  I have fancy jargon”  While jargon is useful to shortcut the communications process, its also an inhibitor for those that are not dedicated to a particular discipline or domain.  What many proposers and presenters forget, myself included, is that the presentations and proposals are not about me but about the audience.  So any means to make understanding easier for the audience is good.

Now I get back to my most recent RFP and presentation efforts.  After writing my technical responses I ran a reading level analyzer.  The results didn’t shock me.  The text was rated at Ph.D or beyond.  A far cry from the 8th grade level requested.  After significant effort I managed to reduce it down to 12th grade reading level. There I was stuck and required assistance from team mates, who thankfully jumped in.  What I found interesting beyond the reading level issue was that when I presented similar or more complex material I used very little text, choosing to use pictures, diagrams, and charts.  When I asked several audience members if the material was too complex and I should simplify it, thinking the words needed to be “dumbed down” I got a surprise.  They hadn’t even read the words, instead they got all they needed from the charts and spoken words, even though I used very technical jargon.

Which brings me back to Mr. Dick’s forecast of the future of media.  That graphics would dominate communications in the future.  Interesting points to consider: Look at Steve Jobs presentations, Nancy Duarte’s books Slid:eology & Resonate or books on Storyboarding –Hollywood’s go-to method to organize and present complex information.  All of which rely on graphics.  May be Philip was right in his forecast of the rise of graphics but others were wrong in thinking that graphics is dumbing down the communications.

Morning’s Ponders and Tool Suite Rational

Prior to jumping into finishing writing the technical approach for an RFP response this morning I spent a little time reflecting on the past few weeks of work.  I’m a big fan of Covey’s approach to analyzing your time to gain insights and understand patterns that could help you become more productive and enjoyment.  Yes I said pleased.  In a day when everyone talks about work-life balance as though these are separate things, I’m wondering if I’m the only one that gets enjoyment out of my work.

Must work translate into drudgery?

That seems odd.  I’m a woodworker, initially to assist my wife’s real estate projects and create items specific to what we need around the home, then it became a hobby.  As I participate in other social media sites around woodworking and makers, the pattern seems the same.  Then I find some others taking it a bit farther and creating businesses around their passion (e.g., Stumpy Nubs, The Wood Whisperer, etc.)  It appears woodworking has gotten a resurgence in popularity.  From their online appearance it seems they are have a passion for their work.  May be I’m reading into what I see in their public appearances and activities, but I continually see signs of real enjoyment in their participation in the craft.  Marc Spagnola,  The Wood Whisperer, has a science background and he uses it daily to expose the science behind the craft, right down to using the scientific method and experimentation to discovery such.  On his video blogs you see him and his wife Nicole banter back and forth.  To me its clear they are enjoying not only success in their business, but the process.

Which brings me back to this morning’s musings.  Do others also enjoy the process of their work like I do?   As I’m about to get back to writing the technical approach, I find myself excited about the process.  I really, no love, the entire process of discovering new methods and figuring out how to solve problems.  This is probably why I had gravitated to Management Consulting and Information Technology.

With that bit of personal insight, like always, after I closed out work last night I when back to working on the next section of my CAD for Enterprise ™ Design Tool suite.  My thoughts around this as a worthwhile endeavor is that there are plenty of technology corporations creating tools for what is the equivalent of CAM for Enterprise.  This matches what happened in the physical product industries for decades, lots of industrial automation technology while Architects, Engineers, and Designers continued to use manual methods and slide rules to accomplish their work till the computer technology became mature enough to be applied.  I’m seeing this as a similar pattern.  Last night I did a quick inventory of the “tools” I’ve built throughout my career to aid/automate various tasks around Enterprise Design, some I.T. oriented, some financial, some business management.  Then I looked at a tool I created in MS Access decades ago, B.A.S.E. ™ (Business Analysis System and Environment), it enable me to work in multiple functional domains on an engagement and reuse the information.  That goal I’ve continued to work on throughout my career.  A few weeks ago I had a brief exchange with my mentor regarding integrating various information domains.  With his encouragement and the involvement of others in their respective fields it looks like I’m close to creating the infrastructure that would support such a tools suite.

In the meantime I continue to create various point tools that will eventually snap-in, like the B.A.S.E. ™ product I created which had a similar idea of point tool modules.  This along with my question-based methodology is the goal I’ve set out to accomplish.  –and yes the point tools can be used in stand-alone mode; and yes I have shared these to others over the years (some on the Office Templates Online under the brand Intellectual Arbitrage Group which appears to have been syndicated on multiple sites as free downloads).

Cloud –hype or a lesson to learn about ongoing technology change

A while back the model was there was a market for just 10 mainframes worldwide, or so the quote goes.  The in order for a corporation to join the big boys, you needed your own.  Decades later I’ve the equivalent of a S/360 processing power in my pocket.  If one follows the technology generations: On-Prem. Mainframe; Department Minis; Timeshare; PCs; Client-Server; then Internet, Now Cloud. There is always a new technology on the horizon (e.g., quantum computing) that will solve the worlds problems and put the kids to bed on time or so the marketing hype goes.

I’m neither a fan-boy or luddite when it comes to new technology.  I believe I’m a pragmatist.  I’ve a set of simple rules when it comes to acquisition and holding onto technology:

  • Explore and examine, but do not commit till conditions point to such
  • When exploring the technology, examine both the technological aspects:
    • does it add new capabilities
    • Is it stable (mature enough, reliable enough, has enough market share to continue a reasonable lifespan)
  • and business application:
    • does that new capability add something to my business
      • Reach to customers or markets
      • Improve customer relationships
      • Allow me to do something new for customer or improve my operations
    • or reduce costs and risks

Which brings me to the latest R&D I’ve been conducting over the past few decades that fits into my larger research project of creating a CAD/CAM system for Enterprise Design, Construction, Operations, and  Remodeling.   That latest research has been all about the overlap between business and technology strategy.  This is something my mentor John Zachman had started decades ago.  By now I can imagine several people’s eyes rolling. “Zachman Framework!, that so yesterday…”  However, those that have seen the decades of methodology hype go by know that the Ontology expressed in the Framework still is relevant.  Its just not the “silver bullet” everyone wants.  It takes some work to understand that the views defined in the Framework are there for a reason: To understand the various aspects of an abstract entity, Enterprise, to be manifested.

Given the hype and technology priesthoods that have developed around various methodologies: TOGAF, DODAF, SAFe, BPMN, etc.. I will not enter into the fray, other than to say these all have some aspect of utility and all address some dimensions in the Zachman Framework. 

Back to Cloud and business/technology strategy:  As of late business models or various levels of business models (Campbell’s Operation Model Canvas**) are become more mature from decades ago and starting to reach across to technology or rather technology has been identified as an enabler to business strategy.  With that as an underpinning to this post.  I post the real question around Cloud and Cloud Hype:

The real issue is how or should you take advantage of such. If you’re just switching technology to “modernize” that’s fine.  If the cost of maintenance or business continuity risk due to end of life is a significant threat changing technologies is a simple model (i.e., you’re replacing you car because you can’t get anything more out of your Model T).  That does suggest however, it will be running business as usual.

That, in my opinion, is short sighted as few businesses are in an environment that enables that.  Today business as unusual is the norm.  There is so much volatility and change going on in the space we call enterprise that operating a business is now more an effort of managing complexity and change than executing a simple production line was twenty or thirty years ago.  As such prior to committing to such a change it behooves Executives to ask the questions beyond the easy just replace On-Premise with On-Cloud for a supposed cost saving, how will I exploit the technology to improve my business besides just keep it operating another day?  As well as ask what are the trade-offs I make with such choices:

  • Dependencies/Risks on a service provider
    • Will they be around tomorrow
    • Will the service change
    • Besides Security and Data Ownership, can I extract such to a new provider should I decide to
  • Will/Can I integrate a broad spectrum of services together (primary vendor and others) with moderate or less effort, or is it really a closed system
  • How long will it take to covert?  Will the conversion take more time than the technology is likely to be in place

The thing I tell my clients continually, there is no free lunch, there are always trader-offs.  Some immediately, Some during an event, and Some eventually (i.e., in the future).  It is up to your executive team, not the technology providers or operators within the company, to understand these implications and impacts.  -And if your team does not have the confidence in making these decisions get a Business – Technology Strategy Consulting firm to assist.  This is not a technology strategy consulting firm (i.e., how to install, configure, and operate), but one that focuses on how-to use the technology for business as well as what are its implications to the business.

**full disclosure I’m working with Andrew Campbell on a tool suite to evaluate Operating Models similar to the evaluation tool suite I built for the Business Model Canvas community

Zachman Ontology (Framework) and other Ontological Models

This past Friday a had a short but insightful email thread with a new colleague, Karen Morphy. I’ve been busily working on my –to quote a joke from my PDES Inc. / ISO10303 development friends and associates — Mother of All Frameworks. Except its not my framework or ontology. Its John Zachman’ s.

I had previous discussed my various discussions with John about the Architect Metaphor and the drafting paradigm that people only partly understand. My thought around such is that the Framework is a 2D projection of a Multi-Dimensional Problem-Solution Space. The issue I brought up then to John and continue to work; on sending him insights that I discover for he and I to discuss. [I am still a supporter of and hopefully contributor to the advancement of the framework] Is finding the logical/mathematical connection that binds the rows and columns together into a unified whole. The Unified Field Theory of Enterprise Architecture if you please.

I had agreed to read and review [soon to come on Amazon] Operating Model Canvas book by another colleague Andrew Campbell.

About a quarter in I found that it would provide some valuable insights to a project of mutual interest between Karen and I.   I fired off a quick note suggesting this may be of value as it focuses upon the “architecture of implementation” –cringe at the application of such a phrase, but in this context I think its true to my definition of architecture .

Her question back: “How does that differ from the Business Model Canvas? Seems like it puts the Value Chain at the center so there is more of a customer journey represented? Being a Zachman disciple, I see many of these as just a rearrangement of the Zachman ontology…”

Almost without thinking my reply came. It seemed so natural: “I see all of these models as either subsets of Zachman Ontology or auxiliary views (I.e. Combinations of columns or rows to create a specific perspective needed for illumination (same thing is done in other engineering fields)”

Which brings me back to the drafting metaphor and my original personal R&D. With so many I.T. and Business Framework popping up every day how is one supports to make rational sense of such. As stated above I believe all these others are simply views or auxiliary views of the Zachman Framework. These are not better or worse than each other, but specific perspectives needed to illuminate a specific item of interest, similar to such in the drafting domain.

 

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