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.

Discipline Maturity Lifecycle: Enterprsie 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.

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.