Assuming one has acceptance on an EA program, where do you go from there? You hear a lot on this topic. Some of the readings and recordings from this week reflect the "current state vs. future state" debate. The presentation from Gartner Research VP R. Scott Bittler "Enterprise Architecture Program Pitfalls- Current State First?" was focused on this topic and very thought provoking.
"Where do we start ?" is kind of like the "chicken or the egg" question. Which came first? Where you start, in my view, does not matter if you do not have a process to manage that change. If our goal, via EA, is to deliver value early and often, we need to provide not only decision-making guidance but a deployment process to support that business decision.
Once again I am going to pull back the covers of my past for some practical experience. In my opinion, some of my biggest disasters I have been a part of are due to the inability of an organization to implement a new process. As a consultant, I have found that once a process is defined and then agreed upon, it is the implementation process where the battle is won. A project can rapidly go off track if the organization does not have a process in place to facilitate deployment quickly and efficiently. We cannot deliver value "often" if the deployment process does not work right. It is like designing an emissions-free vehicle that everyone wants to buy, but you cannot get out the door to the market. No matter how great everyone thinks something is, people lose trust when one is unable to deliver.
In my business, we found we needed to build a strong team, establish guiding principles, and adopt a shared environment (people, process, and tools) when deploying new solutions for our clients. This became more critical than what they were currently doing or how they wanted to evolve their processes and supporting solutions. Once a delivery framework is established, these principles and methods can be applied to individual business unit initiatives and projects across the enterprise. The role of EA is to facilitate the movement from current to future state. That change is managed by adopting a common delivery framework and supporting toolkit. This, in turn, tends to reduce complexity and provides a means to deal with the diversity inherent in most business units. This framework provides the ability to respond to changing business needs rapidly and efficiently.
So back to the debate...what comes first? Mr. Bittler goes on to talk about doing the current and future state in parallel and the pitfalls of one approach vs. the other. To manage any of this, one would need to provide change management in a quick and dynamic way that allows for all types of changes. Incremental and radical changes will need to be managed at different times and across business units.
I believe the real starting point is having your delivery framework and management process established. Once you have that, it is "game on" in my opinion!
Thanks again for reading! What are your thoughts and experience?
Sunday, January 31, 2016
Thursday, January 21, 2016
EA 872 Week 2 The Effectiveness Challenge
Hello again and welcome to my weekly thoughts on Enterprise Architecture!
There have been several interesting readings this week, not just from the class assignments but also from classmates. I especially appreciate those that found what I wrote to be interesting enough to comment. Thanks!!
This week I ran through the EA Roadmap Process and also joined the class discussion on the review of the Gartner toolkit for driving strategic EA. There were quite a few interesting thoughts and comments around this toolkit and how to present to executives, such as how much is too much on a slide and other details around presentation formats. I joined in that conversation with my thoughts on what or how to present back to an executive team, but I started thinking about effectiveness and the challenge that we all face around initiatives and executive buy-in. As I was thinking through this, I came back to some of my experience as a C-level executive working through both internal and customer challenges.
What I am about to say might not be taken well, especially with the group that I am a part of, but hear me out. A lot of the time the challenge when it comes to being effective in a project is IT. We have all been there - we get pushed by the business, they do not understand what it takes, we do not have the people or budget. If you say "no, not me" take a quick look in the mirror and look yourself in the eye! So when we talk about EA and foundations we should take a look at the challenges with IT and how that can affect what we can do in a business-driven EA approach.
Executives are concerned about their Return on Investment (ROI) from IT. That is no secret. IT expenditures continue to grow, which directly affects the bottom line. Therefore, many executives begin to scrutinize the effectiveness of their IT organizations, and this scrutinization can lead to a bias the minute any new initiative is proposed. As a result, IT needs to gain credibility within their domains. They need to show that they can be adaptive and fulfill the strategic requirements of the business, in a timely and efficient manner. If not, then a roadblock to creating an EA foundation is going to exist. If a lack of credibility continues to exist, you may find executives agreeing with the need for EA, but experience shows they will take that initiative to large systems integrators and product and services companies for execution. Remember what I said about IT push back? It is bound to happen when the business hires a firm to tell IT what to do, right?
This idea is not mine, or even new. A quick search will show articles from 10 plus years ago talking about this same subject. For instance, read this one from CIO.com in 2005...
http://www.cio.com/article/2448774/enterprise-architecture/the-relationship-between-enterprise-architecture-and-it-governance.html
I could go on about this, but my point is that to be effective in building an EA foundation a better balance between the internal IT organization, internal business units and external service and technology providers has to be found. A foundation can only be built on solid ground. In most cases in an organization, that has to start with IT.
There have been several interesting readings this week, not just from the class assignments but also from classmates. I especially appreciate those that found what I wrote to be interesting enough to comment. Thanks!!
This week I ran through the EA Roadmap Process and also joined the class discussion on the review of the Gartner toolkit for driving strategic EA. There were quite a few interesting thoughts and comments around this toolkit and how to present to executives, such as how much is too much on a slide and other details around presentation formats. I joined in that conversation with my thoughts on what or how to present back to an executive team, but I started thinking about effectiveness and the challenge that we all face around initiatives and executive buy-in. As I was thinking through this, I came back to some of my experience as a C-level executive working through both internal and customer challenges.
What I am about to say might not be taken well, especially with the group that I am a part of, but hear me out. A lot of the time the challenge when it comes to being effective in a project is IT. We have all been there - we get pushed by the business, they do not understand what it takes, we do not have the people or budget. If you say "no, not me" take a quick look in the mirror and look yourself in the eye! So when we talk about EA and foundations we should take a look at the challenges with IT and how that can affect what we can do in a business-driven EA approach.
Executives are concerned about their Return on Investment (ROI) from IT. That is no secret. IT expenditures continue to grow, which directly affects the bottom line. Therefore, many executives begin to scrutinize the effectiveness of their IT organizations, and this scrutinization can lead to a bias the minute any new initiative is proposed. As a result, IT needs to gain credibility within their domains. They need to show that they can be adaptive and fulfill the strategic requirements of the business, in a timely and efficient manner. If not, then a roadblock to creating an EA foundation is going to exist. If a lack of credibility continues to exist, you may find executives agreeing with the need for EA, but experience shows they will take that initiative to large systems integrators and product and services companies for execution. Remember what I said about IT push back? It is bound to happen when the business hires a firm to tell IT what to do, right?
This idea is not mine, or even new. A quick search will show articles from 10 plus years ago talking about this same subject. For instance, read this one from CIO.com in 2005...
http://www.cio.com/article/2448774/enterprise-architecture/the-relationship-between-enterprise-architecture-and-it-governance.html
I could go on about this, but my point is that to be effective in building an EA foundation a better balance between the internal IT organization, internal business units and external service and technology providers has to be found. A foundation can only be built on solid ground. In most cases in an organization, that has to start with IT.
Friday, January 15, 2016
EA 872 Week 1 Getting Started
This will be my first go at a blog, professional or otherwise, so bear with me and please offer up any feedback you might have!
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:
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!!
https://ingenia.wordpress.com/2015/03/20/enterprise-architecture-and-systems-thinking-ian-glossop/
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!
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!
Subscribe to:
Comments (Atom)