We are starting our first Enterprise Architecture practice. What would those that have EA in place, or have recently launched EA, found to be the most beneficial EA services you provide to help sell EA to the enterprise and gain support?
Excellent stuff ! I appreciate you taking the time to put your thoughts in writing. We are about to undertake an "ERP of the Future" initiative on, so we plan to get involved early from an EA perspective. I'm glad many of my thoughts align with a lot of your feedback. Thank you, again!
Excellent perspective from above. To add to his overview:
- define a crisp vision, mission statement and outcomes which you want to achieve and your EA services to deliver. And get that aligned first with your IT leadership and then socialize with business leaders. The "Why EA exists". There's no cookie cutter framework for that but rather you need to build that operating model for your organization which will align with your IT and corporate operating model.
- "the thinking ahead" framework. EA's business value delivery is steering your capital projects or business initiatives towards future state architecture but there's a lot of groundwork which you need to establish to get to that aspiration such as establishing EA guiding principles, relationships, understanding the business processes to define current state gaps, and providing business-centric target state options panel (backed by your reference architecture) in order for them to build a business case.
- build your team first. Get the right architects or upskill the existing ones in "modern" EA concepts before you start with socialization.
1. Being more agile. For example, application level design and development is more near business decision leadership team could make the enterprise more agile, which all leadership team want;
2. Build a common foundation for long term. For example, for data infrastructure foundation, security and privacy foundation, it is benefit to have one architecture for the whole enterprise, which reduce throw away work and even reduce the cost of R&D and making the whole enterprise architecture more maintainable;
3. Let decision making easier. Making each IT engineering team lead and business team lead has clear responsibility for how to make a decision, who to make a decision and make the process very clear.
The creation of a map or blueprint of an organization's operations may be one of the key objectives of enterprise architecture. Enterprise architecture will assist various departments in a company in comprehending the larger business model and articulating difficulties and potential hazards. As a result, enterprise architecture is crucial in integrating and harmonizing departmental activities within a business. The process of enterprise architecture entails analyzing, planning, designing, and ultimately implementing research on an enterprise. Since enterprise architectural concepts vary, each organization's version won't be exactly the same. The way an organization's various departments interpret EA may also vary. For instance, enterprise architectural plans are viewed in terms of the infrastructure, application, and management components that are under the authority of programmers and other technical IT specialists. Enterprise architects are still in charge of carrying out business structure analysis, nevertheless.
Is this chatgpt answer?
Typical steps are creating a charter/framework that EA will operate within, followed by:
1 - Capture current state, which generally uncovers duplicate systems or legacy technology that is no longer supported
2 - Proposed future state - ultimate state that business and IT would like to move toward
3 - Roadmap on how to get from current state to future state, generally has multiple steps to get there.
One thing I have seen is that for many organization EA follows a cyclical pattern. The organization will determine it needs an EA function. This will be because they are moving to slow, they are doing something different (e.g. Cloud), lack of standards have added to the cost, etc. The EA team gets up a running but isn't connected enough to value. Once the worst problem are taken care of the rest of the organization often rebels and says that we could be faster without the team. So it is disbanded. Until the organizing realizes that it has a lot of inconsistency and a big mess and start anew.
The other thing that I have observed new EA teams do that mess them up is to either spend too much time doing EA. Creating a lot of EA diagrams. Creating every conceivable view of the organization, or starting with complete business capability maps, or whatever and create a lot of diagrams that are expensive to create, impossible to maintain, and only consumed by the EA time.
The last point I will make before getting to the actual question is that some years ago MIT came out with an EA maturity model. This model had 5 levels of maturity. They stated that it takes about 5 years for the average EA team to raise a level of maturity. With the cyclical pattern above, I find that many teams die before they mature. The ones doing all of the diagrams think they are more mature than they are and just waste everybody's time. I don't know that 5 years is still the timeframe as the body of knowledge is much better and there are a lot more experienced EAs out there now than there used to be but still, it takes time.
With all of that back drop there are a number of areas that I have used with my EA teams that added value to organizations early on. But as I said everyone was different and I wouldn't do all of these things. Your job is to increase the value created by the organization. Your team isn't the part that creates that value. Find out what can help those that are creating the value that can benefit from an EA perspective.
1. IT Decision frameworks -- IT organizations often get paralyzed by over analysis or different opinions. Often getting the organization to agree enough on anything to actually move is more important than whatever the actual decision is. By creating decision frameworks you can help the various stakeholder get to decision faster without taking ownership of the problem itself. For organization struggling to move forward, this is often a good thing.
2. Principles & Guidelines -- Most EA teams provide some kind of governance on enterprise standards. Often this doesn't work well because they are thought to slow down the process considerable or their principles are often violated due to business necessity. The problem often is that the EA team is putting itself at the center rather than those creating value. From the solution teams, the principles should be helpful to them in understanding what they have to do to align to organizational ideas. From the executives perspective every principle should be something they actually care about if it is violated and if you throw up a red (or yellow) light they would want to understand the situation before going against it. I like to keep to no more than 10-12 principles, all must pass the executive threshold test, and all must be documented in a way that brings clarity to the solution teams rather than mandates. If teams struggle on satisfying any of these principles, then work with the teams to figure out how to improve the principle (or guidance) to accelerate it so it is easier next time.
3. Capability/Domain Mapping -- I don't recommend starting with an end-to-end capability map but can certainly be something worth starting on. Instead of doing it all. Find the most critical ones and then build a solution for it. Need to do more with data, great create a domain model for one use case get that built. Or migrate one capability to the cloud or whatever. Start the model but tied to short term value.
4. Talk with teams, ask them where they need help. Build reference solution with them (rather than to them) better yet, create a community of practice, let them decide the priorities. They can worth with you but your team will be the dedicated resource to solve some of their challenges.
5. Be a consulting team to the executives. Put together briefings on key technologies.
6. Or, find the few big sticky hairy problems that are really preventing your organization for moving forward. Perhaps it is something related to cloud migration, or integration, or security. Whatever it is, solve those couple of thing and forget all the above until you do that. Get that big win that shows the EA function was needed.
7. Some of my most successful teams focused much more on how we architect and organization to execute. Left the majority of the architecture to the team but focused on culture, agile, DevOps, quality assurance to quality engineering, developer experience, metrics & KPIs, program/project intake, design thinking, etc.
I'm sure there are many other early wins I could think of but those are a few things that worked for me with different teams.