Structure in Threes: Business Design and Reengineering

The last round of brainstorming tightened up my thinking around the methodology.  Like all engineering endeavors I needed to identify the beginning point for creating the enterprise.  Most of the business model approaches are just that.  They document the existing and while that is necessary, is that sufficient?  When I’ve attended workshops focused on business models, often it ends up around optimization rather than innovation.  The strategy and planning methodology I devised and fielded for other corporations was purposely limited, because at that time these corporation’s business models were deemed untouchable.  Even though several people could see its useful life was coming to an end.  Secondly, reengineering a business model it difficult for most in management positions…their mentality is around optimizing the status quo.  Not a blame, it how they were successful and how they are managed in most corporations today.

The brainstorm I had the other day was along the lines I had decades ago when I suggested a practice that would design and build corporations custom for an entrepreneur.  Thus one has to look at what that means.  What would be the design parameters used in doing such.  The past month I came to the conclusion that businesses should be designed around the customer rather than businesses trying to find customers around them.  That insight brought me to using Peter Mark’s (Design Insight) tool Customer$APPEALS (C$A) to determine the design parameters for the “product” I’m building; an enterprise.

With C$A as a base one can use that to weight investment is the various aspects of the business model and value chain the enterprise participates in.  With that as the starting point my methodology has evolved to the following:

As of this positing I’ve tested this approach in two reengineering project that look to be successful and expect to do another pilot at another two corporations: one already in process and looking for another to pilot.  This “methodology model” will be one of several “views” in Structure in Threes” book and workshops I’m developing in spare time.  Expecting to have first workshop ready by summer.

IT Planning Methdology

Started putting together a tutorial deck this morning for an Enterprise Architecture Methodology which is more business based than IT.  Having watched IT over the years get lost in the technology details I though it was about time to create an approach towards really designing Enterprises; the thoughts I had years ago when I presented at the IBM Application Institute and AIAA Operations conferences.  Why couldn’t you design an Enterprise (not just the IT) the way you design any other product.  Years later, several “internships :-)” in other roles within the corporations, and researching various methods from multiple disciplines I’ve started to integrate these into a design methodology:

The above approach has business model as the root where other aspects are details to that end.  That is IT Planning is based upon enablement of the business model, Market Planning, etc. all come from that common root.

Structure in Threes: Service Design\Service Quality Part 2

This morning’s R&D started white boarding merging ServQual with Cluster Analysis & Stakeholder Analysis/Management methods to develop a measurement system for Service Value Management.  Reached out yesterday to an old IBM colleague — Bradford Hobbs, now running BizBrand Foundry– in connect to some R&D we did together on measuring brand value in a more objective verse subjective manner.   Like Brand Value can influence sales price on products (e.g., Firebird vs. Camaro which were essentially the same vehicle) Brand Value and what influences it will influence sales price of services (e.g., Brand X Business Management Consulting Service vs. McKinsey both may perform the same activity and to the same quality but the later receives a premium from its Brand Image.  I can foresee the same factors and phenomenon equally working in the IT Services arena:  IBM Cloud, Microsoft Cloud, Amazon Cloud, Apple Cloud, Google Cloud, etc.

What will separate the prices paid and the margins enjoyed by these corporations for providing these services will be more than just the actual technical performance.  The Brand image of the company, experience the user enjoys and expects which will either enhance or detract from the Brand image and perceived value which will ultimately influence the price a customer will be willing to pay.  While there are subjective studies on measuring Brand Value of products, I’m literature search so far on Service Brand Value has yielded very little other than subjective measures of service quality.  As such it looks to be a interesting area of Brad and I to collaborate upon once again.

Discipline Maturity Lifecycle: Enterprise Architecture example

Spent this morning thinking about operating models in IT organizations and ITIL initiatives.   After a few minutes of pondering , hearing a group next to me at a conference extol the virtues of the 4hr days a few thoughts came back to me; the IT discipline is still in a low state of maturity.  If I was to use a human scale, the IT discipline is like a 5 year old copying its older brothers thinking it is all grown up.  Sure the IT Discipline has many elements that other more mature design and development disciplines have, however, the behavior, standards, ethics and other aspects around the profession have yet to develop.

This revelation is not new to me, years ago I had started quantifying how other design disciplines evolved and matured.  I had presented a corkscrew diagram at some conference back then and left it as an interesting phenomena.  As I was in a keynote session the image popped back in my mind and the book I had started but never finished.

What triggered that thought process was a discussion of the Enterprise Architecture discipline/practice.  This had triggered another memory of drafting a paper and proposal to create “The Architect’s Office” within an IT Organization I was working in.  Some of the issues are still the same which were taken from my studies in residential architecture and later field experience:  Architectural Practice is not like Howard Roark in Anne Rand’s The Fountainhead the majority of the time.  It is a social and community effort.

There are two aspects to successful architectural firms:

• The Practice BOK –the body of knowledge and activities used to perform and deliver value to the client.  This is where most practitioners focus when discussing the discipline.  The mechanics of deliverable creation.   While this is the      foundation of any discipline and it grows as it matures, it is only part of the practice.  Many EA firms have yet to take that jump into operating the discipline as a business as opposed to only a methodology of delivery.

• The Business –the selection of market, the value defined to be delivered, and the means on how value controlled and delivered (aka the Business Model).   Without knowing your business model Enterprise Architectures are prone to produce limited value to customers though providing what was requested.       Eventually, the practice could end up in a different business or on the corner with a sign “will architect for food” as the activities performed do not deliver an acceptable cost benefit ratio to  clients. This suggests that architects need to understand their market and alternatives to their delivery of value.       Many residential architects left the calling in the 70s & 80s as customers failed to see the value they provided over general contractors that had draftsman on staff.

Enterprise Architecture Discipline Classification

Like the discipline of Physics which has multiple branches of practice, so too Enterprise Architecture should distinguish branches of practices such as Theoretical and Applied Enterprise Architecture.

In Physics: Applied physics is a general term for physics research which is intended for a particular use. An applied physics curriculum usually contains a few classes in an applied discipline, like geology or electrical engineering. While

Theoretical physics is a branch of physics which employs mathematical models and abstractions of physics to rationalize, explain and predict natural phenomena. The importance of mathematics in theoretical physics is sometimes emphasized by expression “mathematical physics“.[note 1]

The advancement of science depends in general on the interplay between experimental studies and theory. In some cases, theoretical physics adheres to standards of mathematical rigor while giving little weight to experiments and observations.

Again like Physics, the partitioning of the discipline into categories will likely require a richer taxonomy that the current hierarchy in use today which has its basis from the Zachman Framework.   This does not mean that the Zachman Framework and derivatives from it are invalid views.  However, looking at the Framework from a broader perspective may yield a more comprehensive ontology that could fill in the gaps between business theory and I.T. design and executional elements.

Today, as I continue my research in the arena I was watching various Black Hole and Physics programs on the Science Channel.  As I listened to some of the arguments and history regarding Black Holes and the physics behind these discussions it sounded much like some of the discussions I’ve heard over the years and more recently in the Google Group Enterprise Architecture Forum.   All of these ranged around what should be or not be in Enterprise Architecture verses Information Technology or Infrastructure Architecture.  The various sides all wish to include or exclude various areas such as BPR or I.T. and its subdivisions or business models or finance.  Add to that the difference between theoretical and applied ad EA is a mélange of sub-disciplines that are still to be related together into a cogent body of knowledge.

While initiatives such as TOGAF are attempting to amass a body on knowledge what I’ve seen is an orientation that still approaches the topic from a strictly I.T. perspective, projecting into the business domain from that orientation.  This has the effect to limit the non-I.T. contributions that are, in my opinion, just has valuable.  Business Models and Strategy, Organizational Design and other areas all have a contribution to the “Architecture” of an enterprise and therefore should be included in such a discipline.

As initiatives such collaboration and social networks gain importance so too shall these other soft sciences and sub-disciplines increase in priority and influence in how an enterprise is structured and operates.  That suggests that these are architecture components for enterprise, like light and space are architecture components in dwelling architecture.

The Meta-Framework for discipline definition I proposed prior a approximately decade ago at ZIFA was Jon Lang’s used in the field of Dwelling architecture. This does not replace the Zachman Framework but places a context for it to operate in to help distinguish between theoretical and applied, prescriptive and descriptive.

Translating Business to Enterprise Architecture: Methodology Activity #1

Converting Business definition to an enabling Enterprise Architecture is not a direct mapping.  Business definitions do not neatly fit into a structural taxonomy that most Enterprise Architects use.  Business definitions do not fare well in process oriented ontologies either.  The nature of business definitions is, as social constructs, these entities are multi-dimensional.  Thus any attempt to document has often met with gaps in perception that appear based upon the orientation of the modeler.  If you’re a structural focused, dynamics are missed.  If you’re process focused you might miss structures or goals.   The Zachman Framework, givens insight to this issue.  However, the establish linkage between on cell to another with the same robustness as in mechanical design has eluded the field for two decades.  While there have been attempts as creating production rules to project from one cell to another, the linkage and visualization has still to be accomplished.  This is not a failure of the framework, but of the representation systems we have at present.  The situation only gets worse as we move down the hierarchy from owner to builder the framework.

 Added to this lack of dimensional integrity between representations systems are the differences in language constructs at each level.  The structures and dynamics at each layer and within each dimension are substantially different due to context.   This until a unified representation system can be developed translation and design will always require human intervention to interpret and unify.  This inconsistency acknowledged a team can still overcome the effects of this situation.  This first activity addresses some of the intermediate forms to translate between the hierarchy levels previously identified in the framework. 

 At the Owner level, the common business model representations used have typically been based on those developed by Michael Porter or Adrian Slywotzky.  These models represent business activities on a broad scale and despite the author’s clear definitions, have merged activities and the organizational structures that accomplish these as a single construct. The Michael Porter models define how an enterprise competes in the world.

Adrian Slywotzky’s model describes how an enterprise creates and captures value within the business world.

Converting these constructs into I.T. Infrastructure Designs is rather significant challenges as the gap between these concepts are not direct translations.  Therefore Enterprise Architects should focus on intermediate forms that bridge these gaps.  One intermediate form that bridges this gap is defining capabilities.  During the late 1990s and early 2000s a method call Strategic Capabilities Network was introduced.  This technique has staff define and relate capabilities to the activities and functions used the business models most corporations use.  These capabilities are closer in concepts to the processes and applications that I.T. Architects use.  Thus mapping between functions and applications through a capabilities network provides a semantically rich association that can be discussed with business owners enabling them to understand how the I.T. Architecture will enable the functions needed to fulfill strategy.            

Strategy Alignment and I.T.

Been away from my blog the past few days as I’m heads down packing to leave my corporate apartment for new digs.   I had time then to mull over some ideas regarding Business and I.T. strategic alignment.  These circled back to ideas I had in the 80s regarding Computer Integrated Manufacturing (CIM) and a quote from a friend “Technology makes a good servant but a poor master”.    Most of the strategies, and I’ve seen a lot these days.  Everyone has an I.T. strategy and so called architecture –I’ll get on my soapbox about architecture another time—which is positioned as the silver bullet for what ails a corporation.  The problem I see with these is there is no linkage between Business and I.T. Strategies and Architectures.   

I spent most of yesterday in discussion with one of the people I’m mentoring about such.  She’s starting a new position as a Sr. Architect and was trying to figure out her first steps.   I suggested getting to know the organization and its business model first.  We spent time discussion Michael Porter, Adrian Slywotzky approaches and how to analyze the business.  In a short time we had decomposed her new employer’s business model and the competitive threats on the horizon.    She was amazed at how easy yet difficult this was to do.  The “wow” was in her voice.  I replied this was the easy part.  The tough part is determining what to do and aligning the critical stakeholders to do it. 

I had previously worked an engagement years ago, with IBM, in which we used a business strategic analysis method; Strategic Capabilities Network (SCN).  At that time it was just a IBM Research paper.  A subordinate and I built a quick tool to support the method out of MS Access for a strategy engagement we were doing.   We collected the data, analyzed it which helped us develop and eCommerce strategy for the client.  I took a quick mental note that this could be eventually used as the bridge between business and I.T. strategy.  

Fast forward to today, I still see gaps between business and I.T. that Evel Knievel would have second thoughts about jumping.  However, as I started pondering this issue It came to me the reason why was it still was a translation issue.  Business and Technology don’t talk the same language which has brought me back to my SCN application a few other tools and methods I’ve used in the past and how to integrate them into a more cohesive methodology than TOGAF or many of the other technology driven architecture approaches.   This is not a slight against TOGAF, etc. but rather a thought how to bridge Business Strategy and I.T. Architecture into a symbiotic relationship.

In the new role I’m looking at fulfilling I can see this greatly helping my peers be more successful; faster and with greater results that delight clients.