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.



Structure in Threes: Taxonomy Research for IT Service Design methodology

This morning I’ve started doing a deep dive on IT related and other standards and practices.  The end goal is to create a coverage map to ensure these concerns are integral rather than a bolt-on later for IT Service Design.    On the table so far are ITIL, COBIT 5, TIPA, SOX, CMMI, ISO 9000ISO 20000, ISO 15505, ISO 27000, and ISO 22301.  My conference table is covered with earmarked books and papers.  Will likely turn all of material into a reference database –back to my favorite mapping tool MS Access.  The interesting issue I see with most coverage maps I plan to avoid is most are keyword based rather than diving deep into the semantics; this results in either an inference of overlap where there really is not or miss overlap or strong interdependencies due to mismatched taxonomies.

I had this problem initially when I was reengineering Strategy and Market Planning processes.  The two domains overlapped and under-lapped a great deal.  Each used different terms that meant the same thing; similar terms meant something different in each context; or had similar meaning but at a different level of abstraction.  In the end I had to do a deep dive on all of the concepts as the taxonomy mapping provided by others was not sufficient for creating a catalog of methods to apply to the process.  Consider identifying an item as a power plant.  At a high level this works, but without further detail selecting and applying this item may not work:  An Item is labeled a power plant.  However, further characterization using it in a vehicle may not work.  A diesel engine in a gasoline fueled car.  Application would require modifications to other components in the system.

Governance as Process

One of the interesting insights from my COBIT 5 deep dive which I was pleased to see; the standard generalizes governance as a process.  This falls in line with the General Systems Theory (Cybernetics) perspective that Stafford Beer developed for organizations.  In which you have components that perform processes to accomplish work, components that perform processes to sense and monitor, and components that perform processes to adapted or adjust the first process based upon measures received and evaluated from the second process.

Using that simplified taxonomy an intermediate level deep dive may be possible for all of these standards and practices.