This posting is my final blog of the semester, but I have to say I have really enjoyed it! I want to thank anyone that has commented. I really value the thoughts, ideas, and feedback that I have received.
As a final topic, I want to discuss the execution of metrics and tracking performance. I had several comments around metrics, the value of performance tracking, and over commitment. One classmate noted that one approach could use a "value-to-effort assessment for each metric. How will the collection of each metric increase workload?" You can find that discussion here
He was quite right. If we don't understand how deploying these new metrics will impact the data collection or the other efforts associated with IT and business operations, one could create a problem before getting started. I feel that some of this would get flushed out during the project complexity assessment. You can find more detail on project complexity here:
- http://joec3s.blogspot.com/2016/03/ea-872-week-8-route-planning.html
- http://joec3s.blogspot.com/2016/03/ea-872-week-10-how-to-measure-gap.html
Yet, I still wanted to dive deeper on this. One way to understand the effort for a metric is to translate that into code and see where it falls apart.
For simplicity let's agree that a metric can be defined and a conceptual, logical representation reflected as such:
To better highlight this concept, take a look at this example:
This image highlights several items to consider. It takes both business and IT to produce a metric, much less EA performance metrics. A metric definition can be translated into code, at least pseudocode, very quickly in order to evaluate complexity.
As always, I welcome your comments and thoughts. It has been great working with everyone this semester and I especially thank all who have taken the time to read and comment!
Hi Joe,
ReplyDeleteThanks for the detailed discussion on Metrics and Measurement. From this blog I found the concept of converting metrics to a pseudo-code for measurement of complexity to be interesting. The way the SELECT statement of database has been modeled helps to retrieve relevant metrics based on the constraints identified. Finally, the fact that both IT and business contribute to the various components of metrics is totally agreeable. IT and business are the main drivers of an organization and a metric that considers just one of them will not provide efficient performance measures.
Best,
Swathika
Hi Swathika,
DeleteThanks for commenting. Yes it can yield some interesting results. It is something that can also get some buy in amongst the developers and sys admins as well. It at least can be part of your level of effort analysis.
Thanks again!
JC
Hi Joe, thanks for another interesting post. Metrics are something that is of interest to me in my position as an enterprise architect. Often the work we do is hardly quantifiable and while we can drum up some metrics to show progress, often those, at least for EA seem to be more or less arbitrary in nature. How does the old adage go, tell me how I am to be measured and I will change my behavior to match. Anyway, thanks again and have a great summer. Cheers - Mike
ReplyDeleteMichael,
DeleteThank you for your comments. I do a lot of thinking around metrics, I could probably break out the primitive component into 3-4 postings.. I agree with you around measurements which is why so much of what I posted about has been in trying to establish measurable details to the process. It would be great to have an in depth discussions around metrics sometime. Enjoy the summer!
JC