Throughout my career, I have always straddled the line between IT and business. My hope with enrolling in an EA program is to lend some formalization to aspects of my work that I do or have done. With that said I hope you enjoy what I post and look forward to any comments you might have.
This week's focus has been on some of the core concepts that are necessary to both understanding EA and applying it within an organization. Readings this week focused on building foundations for excellence along with activity cycles for categorizing the type of work effort that goes into building and maintaining these foundations. One of the other items that was discussed is context, in fact, context is one of the first and most important deliverables in the EA process.
As I read this information, I thought back on some of my consulting work in the mid-2000's. During that time, I was part of a small BI company. We worked in quite a few Fortune 50 companies, and one thing that we consistently observed was that key metrics were often used, defined and reported on differently across groups, teams, and executives. This often resulted in projects and deliverable delays when delivering BI projects that spanned several lines of business. Try providing an Executive Level Dashboard or Scorecard when those users cannot agree on a metrics use or definition. The deliverable or project is always going to be wrong to someone in some LOB! This is not going to achieve the value add to the business nor the project ROI. Not to mention how successful it is perceived to be!
Going back through lessons learned it became apparent that this was a common thread across customers and organizations. To better execute we developed a series of workshops and processes to establish context around the project and across the organization. We offered this as a Solution
Assessment service that focused on creating "Context" for the solution and the associated efforts. We called this approach our Service Factory. This approach requires a shift in the processes and organization to achieve a business-oriented model-driven process to recoup investments in its infrastructure and potentially create an ‘information on demand’ environment. Our approach was to provide the new procedures and practices to conduct:
- Project initiation (selecting the right projects for using the infrastructure-enabled value);
- Project enactment (executing the projects in an optimal manner);
- Project support (efficient use of tools and solutions infrastructure provided as service through the Center of Excellence).
This linkage from Systems Engineering and EA is discussed in some detail here, and I found it to be a great read, maybe because it supported my thought process!!
As I continue in my EA journey, I am beginning to see how some of my previous experience is relating to these fundamental concepts being laid out here at the start of the program. That is both exciting and reassuring from my perspective and tells me that I am on the right path.
I hope you have enjoyed my ramblings for the week. Until next week, please let me know if you have any thoughts or comments!
Thanks for reading!
Hi Joe,
ReplyDeleteFirst and foremost, let me say that your first post turned out well. I found it to be an interesting read. Unlike you, having experience from both ends, I only have experience on the business end. Your story about your experience with the BI company hit home. I know what it’s like to work with different departments that cannot agree on anything. Sometimes it just takes a consulting firm to come in and give direction.
As for your discussion about core concepts emphasizing context as “one of the first and most important deliverables,” I could not agree more. When working with a system that is so multi-dimensional, sometimes we lose sight of where to start. I have been known to be guilty of this myself. Sometimes I get so hyper-fixated on the end results I lose track of where to begin.
Once again great post, and thanks for the read.
-Nate
Nate,
DeleteThank you for reading and replying. As noted agreement is often the single hardest item to deal with, especially if a defined metric or process is tied to some standard of measurement by the organization. As for "Context", I'm right there with you. Back in the early days of Data Warehousing, we used to say "Garbage in - Garbage out." In today's world, that is important, but I believe "Context" is, even more, relevant in regards to big data and the analysis effort. In the end, I think EA is the solution to a lot of these issues.
Thanks again,
JC
Joe, I can appreciate your experience with BI challenges. I too have experienced those same challenges. It is easy to say, "Hey I need a dashboard of data", the challenging part come with the question, "Ok, what do you want to see on that dashboard." I have found that even if you can identify what you want to do from a BI front the data is not always available or understood enough to make that happen. I feel like this is were some business context can come into play, specifically business context around data. What does the data mean to Business Unit 1, how does Business Unit 2 interrupt the same data, how does Business Unit 3 calculate the output of that data. If you can define (and agree upon) some business context then you can produce data that means the same thing to different people. We are still working on that, we have made some progress in certain areas and none in other.
ReplyDeleteTroy
Troy,
DeleteThank you for reading and replying. As noted in the comments to Nate, I am right there with you on context. One of the exercises we did and I still use with my team is GQM or Goal Question Metric. This technique was pioneered at NASA, and I adapted it to my efforts in defining a common ground around core metrics. You can read more here https://en.wikipedia.org/wiki/GQM
Essentially the process is a top-down approach starting with the goal we are looking to achieve, the associated question this objective is to answer, followed by the actual metric(s) that should be used to answer or measure that question. You would be surprised how many time we find that the metric or even a core data element is not available.
Thanks again,
JC
Joe,
ReplyDeleteGreat background story and an intro to how data and analytics are so important to business yet so elusive. I love the example you mentioned about not agreeing on what is the definition of a metric. My background is BI & Analytics and I have always struggled with how systems built in silos could get so complex that integration becomes a problem prohibiting business from meaningful insights into their data that is crucial to their progress and advantage.
Ziad,
ReplyDeleteThanks for commenting! Amazing how often this is a problem and projects or initiatives just spin their wheels.
JC
Wow I can so relate to what you said about the metrics and how it only delayed the programs/projects. I have been in that boat where metrics and KPI's took over the actual work. One of the big projects I was working on was scrapped because of all these measurements and metrics. But it is totally cool how you started building something similar to an EA initiative. Yes, we are certainly on the right path and this is in no time going to be more popular as we see more and more companies start to realize what EA is.
ReplyDeleteWow I can so relate to what you said about the metrics and how it only delayed the programs/projects. I have been in that boat where metrics and KPI's took over the actual work. One of the big projects I was working on was scrapped because of all these measurements and metrics. But it is totally cool how you started building something similar to an EA initiative. Yes, we are certainly on the right path and this is in no time going to be more popular as we see more and more companies start to realize what EA is.
ReplyDeleteCertainly right about that. I'm really enjoying what I'm learning and how it all relates back to EA!
DeleteThanks for reading!
JC