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.

Structure in Three: Governance

This week’s research agenda continues on governance and the interfaces of controls with decisions processes for portfolio management.  The further I dive into COBIT 5 the more I like the taxonomy and structure.  While there are gaps, these are explicitly called out in the management guide where research is needed.  Which is interesting as those are the areas I’ve been focused upon, so at some point convergence is likely.  I’ve started to White-Board an assessment tool (MS Access DBMS) which would include COBIT-like concepts yesterday.  As I reverse engineer and rebuild my Access V1 Consultant Workbench (B.A.S.E.) I’ll be adding TIPA & COBIT to the modules I previous built for the platform.  I like using ACCESS more as an intelligence platform that EXCEL due to its ability to build relational models, however, as of late I’m looking at build highbred applications using SharePoint, ACCESS Services and EXCEL.

With more than a few years under my belt in management consulting, methodology and support tools development I have come away with insights on how to make consulting practices more efficient and effective.  B.A.S.E. was developed with that insight in mind years ago.  However at that time management consulting was operated around time & materials billing rather than outcomes, so efficiency and effectiveness in operation was counter to the revenue model.  If it took less time to deliver results to the client you were taking money out of your pocket.  Despite calls for outcome based billing by such notables such as Allan Weiss, Peter Block, and Gerald Weinberg the industry and oddly enough clients still used T&E as the primary billing method.  Which I suppose makes both parties more comfortable and believe easier to contain risk, as time consumption is easier to measure than progress to an outcome.  Just an interesting side-note.

As I continue governance research, the next major area to develop is adoption.  While COBIT 5 describes the change management within implementation, like most other implementation activity very little is defined in this arena.  The majority of efforts listed are on planning the technical rollout and communicating the schedule of such.  From my experience with reengineering processes, such approaches limit effectiveness of change programs.  If left to the end of the lifecycle, stakeholders are suddenly thrust into dealing not only with technological and process aspects but also social and emotional aspects as well.  And as experience has shown experts in the field we continue to ignore, people take longer to change attitudes and behaviors than it takes to implement the technology and define the processes.  The work that John Kotter has accomplished on change management  looks to provide a good base, the next level of development is to move from his strategic framework to create a catalog of tactics and methods to support each stage similar to the business development framework I’ve been recommending to small and medium business colleagues by C.J. Hayden .  End of week I hope to post draft of tactics and methods for adoption stages or find and post a reference by someone else that has already done the research.

Structure in Threes: Capabilitiy Models

Most of yesterday was dedicated to continuing to fix my wife’s IPhone contacts and syncing with desktop.  By 10pm I had finally reloaded a restored copy of her contacts to both laptop and phone.  Later today its back to AppleCare to restore her apps.  Apple is still suggesting using ICloud to sync multiple devices, but at this juncture its unlikely she will trust any cloud provider.  This has taught her a lesson businesses are either about to learn the hard way or have Enterprise Architects, like myself, developing disaster contingency and continuity plans prior to jumping to the cloud:  Technology changes that you run your business on require serious change management.  And even then the a poor implementation can require many hours to recover.  Another lesson or side benefit, she’s starting to see what my career really is about: enabling others,  preventing crises, and recovering from crises.  The unfortunate thing about the Enterprise Architecture profession is that goals one and two are what enables goal three, but goal three is the only one that gets other’s attention.

This morning before jumping back on IPhone recovery, I’m reading through the COBIT 5 management guide.  It’s rather odd how most standards, processes and models now take the form of the CMMI maturity model.  While I’m a supporter of the maturity model construct it has it’s deficiencies or rather I should say poor adaptation of the concept leaves deficiencies in the applied domain.  Often I’ve seen various organizations adapt the maturity model construct for their domain of expertise but as a marketing tool to infer gaps which their product or service naturally fulfills.  However, these capabilities are often not completely filled by the product or service as the capabilities have to be built with these tools, knowledge, processes and behaviors.

The COBIT 5 generic capabilities model points to level characteristics, level generic enablers, and generic level enabler capabilities.  However, it appears the rating of conformance is a subjective exercise.  May be that is acceptable at present as this field become more defined.  However, linking performance to organizational design then become more subjective also.  It may be the design methodology I’m working on will have to include the concept of tolerance and performance ranges (similar to physical product engineering) for the results of selecting the various design attributes.  I’ll have a better handle on that when I encode the governance model into a spreadsheet and link it to the organizational design spreadsheet.  The results should give me a more robust assessment criteria as well as a diagnostic tool for clients that will guide them to a more specific areas to address rather than a shotgun approach.

 

ITIL muses

Considering all the churn in I.T. organizations today around skills, delivery models, development technologies application backlogs and portfolios, I’m surprise how little time CIOs and CxOs are looking at re-engineering the I.T. function to meet today’s and tomorrows new challenges.  Talking across the industry with friends and colleagues this month has indicated to me most organizations are using a scatter-shot quick hit approach towards fixing the issue which seems to only be treating the symptoms.  The Einstein and Clinton quote appears appropriate: “Doing the same thing expecting a different results….” or maybe it is a case of draining the swamp and all the alligators.

While pondering that, the idea of using a single instance of ITIL/CoBIt across multiple provider models (i.e., ITIL Provider Types I – III) seems doable if one takes the same mindset as OS Developers have had for years: Layers of Abstraction and delayed binding:  Since the IT Governance and management functions do not require the absolute details and seven layers of precision, it is feasible.  At the highest level of governance and management I would challenge anyone to see the difference between in-house IT and Outsourcing.  The differences only become apparent when you’re at the 1st and 2nd levels of operations.  While legal and financial details are different between in-house and Outsourcing the control objectives and processes are the same, just the R&Rs and accountabilities change and are adapted to the legal structures accountable to perform.  The Service Order Management, Service Portfolio and Catalog project I’d worked on last year and blogged about prior has convinced me of that fact.

I.T. is a business within a business, but has not been managed that way.  Adopting Service Management enables switching to that perspective.  That switch of perspective permits a CIO to consider other aspects of I.T. that have been not given a due consideration.  The surround around the technical aspects of an offering in business ( (Slywotzky, 1995) (Marks, 1998) has influence on success as much and in many cases more than the technical features.

Designing the attributes of the surround is something many businesses do by default and I.T. organizations are not even aware of but could benefit greatly by addressing.