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.
Leave a Reply
You must be logged in to post a comment.