Structure in Threes: Positioning and Lessons not Learned

Had great discussion last night at Starbucks on Mercer Island with some former Microsoft Alumni.   One is at a Microsoft competitor now working at developing a competitive service to our mutual former employer’s.  The change in strategy at Microsoft has yielded a large shift in the Architecture domain enabling competitors to move in and eventually succeed.  My colleagues and I rather than sit around the table discussing what could have been are busy creating the future; spending several hours mapping out the landscape and what pieces need to be build or remodeled.  Sounds like Enterprise Architects at work.  However, unlike the paper mill approach that was being pushed we’ve been taking a more engineering design approach looking at how the methodologies we’ve each been developing yield implementable designs specific to client’s needs using modular componentry.

Discipline Maturity Lifecycle

I was wondering how much longer it would be before Enterprise Architecture would reach the next stage in its’ maturity.  I’ve been watching TOGAF, ZACHMAN, COBIT, ITIL, etc. for the past several years ideate and mature into a robust collection of heuristics waiting for the day these take the next step towards modularity. last night’s discussion inferred the time was rapidly approaching, both my colleagues began discussing their specific domains in context of creating a reusable component based approach.  That is to say having a set of design rules as to how to choose what components from a library or catalog of components to achieve design goals.  I was really pleased with the direction the discussion was talking.  Had I had my copy of Jon Lang’s Creating Architectural Theory –I leant it out to another peer at Microsoft this past month– I would have pointed out we’re finally making some progress.  However, that most likely would have confirmed in their eyes I was an academic (odd considering I spend more of my time building tools and applying these concepts than doing primary research in the area).

At different times during the conversation I was frantically searching for documents on my Windows Phone to point out some of the pieces I’ve already built or are in the process of building.  Unfortunately, this is where the promise doesn’t measure up to reality.  I could not get to my Office365 Small Business Online site or SkyDrive (it couldn’t recognize ANY or the Userids I entered).  Microsoft has a lot of work to do to get Services right before they can compete effectively with Amazon, Google, and Apple.  Sure individual components run, however, when combined in a system which is where the Services business is, they’re having challenges.  This systems approach is still elusive to the culture at Microsoft.  

We parted with a plan for a plan which could either mean this will result in just an nice academic discussion or that we will really start assembling a next generation of Architectural practice that will take one step closer to a engineering-like discipline rather than a artist colony debating about aesthetics of design.  In either event the discussion confirmed to me I am on the right track with ‘Structure in Threes” and creating the design methodology that enables using modular componentry at all levels of abstraction.

Elegance in Design

Spent last night installing my new monitor rack from Knoll (Sapper Monitor Arm Collection).  It took approximately 30 minutes to assemble and install the whole system.  The only two down points:

  • Took a week to find hardware to adapt Samsung Monitors (while Monitors have Vesa compliant attachment screw pattern, its recessed so the average adapter plate doesn’t fit)
  • The monitor rack is so awesome looking, now I’m going to have to save up to replace the desk it is mounted to with something on a par to the rack.  Hopefully I can find a multi-media workstation desk in the Knoll catalog that will fit my needs

I was fortunate to visit the Knoll facilities last year and got the full tour.  I was impressed with the entire design to manufacturing cycle.  It’s clear they take design and engineering seriously.  When I saw this rack system on staff desks, I spent a lot of time inspecting it, almost dissecting it with my eyes.  I fell in love.  To say its a beautiful piece of work is a understandment; it’s just plain elegant.  Knoll has to be congratulated for an excellent design and equally excellent execution of that design.

Discipline Maturity Lifecycle: History Data-Point

Yesterday during my drive home, after listening to an interesting Enterprise Architecture and Strategy presentation, another data-point that all the design disciplines mature in similar manner came to mind.  One of the current enterprise architecture trends beyond the usual economic pressures and cloud is enabling enterprise agility.

Enterprise Agility is having the flexibility to change how the organization operates, the services it provides or uses quickly.  This comes at a price.  However, as the product industries as automotive discovered, this cost was minimal compared to the competitive advantage flexibility created.  

One only has to look at the history of competition between Toyota and GM during the seventies.  Doctors Ohno and Shigeo, developed the Toyota production system which was exactly counter to the prevailing wisdom of the day to use economic order quantity / economic production runs (aka Traditional Mass Production).  Dr. Shingeo’s creation of flexible machining concepts –Single Minute Die Exchange- and Ohno’s JIT concepts enabled Toyota to reduce time to create and field new models.  This change from industry standard seven years to five years made Toyota more responsive to the market (read that ability to adjust to the gas crisis).  Suddenly American Automotive Manufacturers market share dropped and never regained its former glory.

The value of this flexibility was not lost on executives from other industries.  Today, IT is now running to catch up to the other engineering disciplines on designing for flexibility, and with that the argument as to the value of such.  As the IT community matures, it will come to the same conclusion as Systems Engineers, to develop the practices around supporting the –ilities and the competence to balance between these –ilities (i.e., Design of the Total Offering).                  

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.            

Business to Information Technology translation

Past week was rather busy as I relocated my office; another case of changing the tires while the car is moving.  It did give me time to continue to ponder how to translate business into enterprise architecture and then I.T. designs.  The idea I came up with was integrating various proven models and methods into a complete methodology similar to how I would design houses decades ago.

I came to this approach as I am using a similar approach to solving another problem for another enterprise project.  My project portfolio this year seems to be integrating components into complete processes or functions.  May be it’s because I have a large inventory of methods, tools, techniques and processes in my professional toolkit.  So today I’m looking at cataloging these into a database that will cover the various types of information these address and use. 

The issue seems to be the relating business models to I.T. models.  However, after years of working this I realized it’s not a direct translation.  There are intermediate steps that are not in the current inventory of most corporations, nor recognized.  Some of these I’ve used at other enterprises but where only internal use only as neither the business stakeholders nor the I.T. community understood or cared about them.  As such they seem to be of use only for architects as present.

During this week one of my peers who are facing this challenged asked how she could align I.T. with the business.  After discussing her current situation we agreed the first problem to address was having the I.T. group realize they couldn’t build business strategy from I.T. it goes the other way.  The next issue to address is, understanding that an intermediate form that both could use as a neutral exchange was needed. 

However, neither party recognizes the gap is too far to bridge, so a neutral exchange does not seem worth investing in yet.  That’s a plus as it gives me more time to develop a robust one based upon concepts I discussed in last post.

Steve Jobs remembered

Steve Jobs Feb. 24, 1955 – Oct 6, 2011

Entrepreneur, Reinventor, Stylist, Visionary

I was on the exhibition floor of SharePoint 2011 yesterday when someone gave me the news about Jobs’ passing.  My first reaction, you have to be kidding.  Sure he was ill, but he’d bounced back before.  How can he be gone, he’s Steve Jobs?   I was nonplused.  My next reaction was to check out the news on IPhone.   The report of his passing was true. 

I am not an Applehead, I purchased an IPhone reluctantly as my wife thought other smartphones were too complicated to operate.  It’s been several years now, I’m still using an IPhone 3G. I still prefer a Windows Laptop to a Mac though many of my relatives in creative industries are confirm Mac users.  The one thing that differentiates my thoughts regarding Apple vs. Microsoft is that my decisions are not techno-religious in nature.  I can point out the technical reasons why I prefer one over the other.  These reasons are based upon attributes of the design philosophy of each.  Sure there are some emotional aspects to that in regard to which attributes I prioritize higher.  However, what I believe makes my thoughts on the topic different is making those explicit.

Jobs and Apple had been written off years ago when the Windows operating system and Microsoft Office took off.  The company looked to collapse or at least fade off into history as a has been.  Those that wrote the company and Steve off didn’t understand this wasn’t the end, nor was the future caving in to business pressures and become another PC clone.  Steve had a design philosophy that he was sure would be successful in the long run.  Fast forward a decade or two Apple has surpassed Microsoft in market capitalization.  It has become an admired corporation again, though many would argue they’re not a PC or technology corporation. 

I would say to those critics; you’re right.  Apple is not a high tech firm, though they consume high technology.  Apple through Jobs guidance has become an experience and stylist firm with technology.  If Apple were in the food industry I would say they’d be Starbucks.  Both focus on all the details of providing an intentional experience.  As I sadly end this post and say good-by to an industry colleague and competitor by proxy with a modified quote by Steve: Where ever you are now I’m sure you’ll make it insanely great.  Bless