Hi Rick! You have a great point about the challenge of explaining EA's value. I agree, involving stakeholders in defining services is key. Would love to hear from the group on your questions, especially regarding tips for raising EA's relevance to the business.
I like to think of the ‘relevance’ question like this: “thank goodness we have an EA discipline, because if we didn’t, then (negative) would still be happening’… or more positvely, ’...because, if we didn’t, then (positive) wouldn’t be happening.’ I doubt many of us can complete that sentence. Many of us are part of EA discipline at our employers that were created because it was the right thing to do. EA is a mature IT discipline practice. Many, many shops are still very low on the maturity slope.
So much of this depends on the organization - is change good, or is change bad? Do we see problems/ risks as failures, or as opportunities to improve? And unfortunately, these perspectives often shift depending on who sits in the corner office.
The challenge at my organization is we still like to be firefighters. Many people make their living ‘fixing’ things.
Sorry Ricky, probably not the tone you were looking for, but just wanted to be candid.
Thank you for sharing this article Ricky and as you mention, it is quite a challenge to be able to bring this to the business. Although EA is more than 20 years old, in our case we are new (less than 2 years) and our first challenge was to have a good understanding of what EA really is and that the TOGAF courses only focus on showing the framework. After doing a lot of research, reading countless articles, blogs and also with specialist providers, we were able to understand what EA is, the different layers that make it up and the importance it has not only for IT but for the business. Challenge 1…check!
As we continued moving forward we saw the need to extend EA understanding to all areas of IT and after reading the article “7 Stakeholders Enterprise Architects Need Buy-In From” it was good to know that we are aligned and on the right track. And the challenge with IT Stakeholders is collaboration, that each one is responsible for a component of the architecture and that we as EAs are not only information collectors but collaborate with us, that is, the PMO responsible for the initiatives, business context processes, IT infrastructure, etc....and we are on that path. Challenge 2…in progress.
Finally, and as the third most challenging challenge, it is to involve the business and for this I believe that it is vital to be able to explain the concepts of EA in the simplest way possible and that they can understand the benefits that the implementation of EA brings to the business, that they can visualize this alignment between business and technology and how that contributes to the achievement of strategic objectives.
I hope that under my short but very rewarding experience I have been able to contribute with my experience and that it can help you as well as be able to hear about your experiences in this exciting world of EA.
Hey Rick. Definitely involving stakeholders is a crucial activity needed for a successful EA in an organization. From my point of view, collaboration among all parties involved to keep all the EA pieces up to date is the cornerstone needed to achieve the expected benefits behind an EA implementation. Sometimes is hard to obtain this collaboration because not everybody is fully aware of the EA benefits, in that case communication campaigns can help to let the people know more about EA concept and the value that can bring to the company, as for instance save time avoiding manually collecting data, reduce the risk of impacting business operations by having a plan for technical components replacement due to obsolescence or lifecycle or save money avoiding duplicities in technologies. Glad to hear more ideas from you.
Thanks for the insights/feedback. The best way to win buy-in from your stakeholders is to know which of them will be the most receptive to your ideas by defining the specific parts of your EA practice/services that matter to each stakeholder. Put your processes in the context of the stakeholder's business area and show the immediate value you will create and the structure you have in place. For example, you can ask some of the following questions to your stakeholders:
- What specific business functions do you provide services to?
- Who specifically provides the service?
- What are the deliverables and outputs of your EA service?
- Do you know which SLAs will be breached and what the price will be if critical services fail?
- Further questions are here.
These answers will help you define the EA services that provide value to the business stakeholders and create a portal, reports, and dashboards to drive value. As part of this community topic, I would like to create a workshop for interested customers. Would you like to participate? @Oscar
Here’s some typical EA Services: @Oscar
Services | Description | Deliverables |
Business Case Development | Business units create cases to gain approval for initiatives supporting objectives. | Business Case Template |
IT Strategies Development | Develop a clear strategic direction, including goals, guidelines, and initiatives, for a specific domain and effectively communicate it. E.g., Data/cloud strategy, API/integration strategy. | Strategy Document, Standards, Principles, Initiatives, Guidelines |
Technology Trend Analysis | Identify opportunities for applying technology to solve business challenges. | Technology Radar |
Innovation Management | Brainstorm, ideate, test, analyze, and iterate for creative problem-solving. Encourage non-linear thinking and multiple perspectives. | Solution Architecture Docs |
Technology Capability Management | Evaluate current technology capabilities and determine which to develop, retire, or maintain to support the business and technology landscape. | Architecture Technology Capabilities |