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?
Director of IT in Services (non-Government), 5,001 - 10,000 employees
Starting with the specific architectural framework—either one that is already in existence or one that you have customized—is the first step in creating an enterprise architecture. The first phase is to organize, which include identifying a target vision, establishing the development team, and scoping the project. Some essential enterprise architect best practices recommended by Gartner Research for program success in enterprise architecture include: Enroll in the EA program. Create (and carry out) a plan for decisions and communications. Consider each revision of the plan as a separate project.VP of IT in Software, 201 - 500 employees
There is no ground truth for a general EA for all enterprises. There are always balance between short term agility and long term growth. A few quick thoughts,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.
Director of IT in Healthcare and Biotech, 1,001 - 5,000 employees
Before you implement EA for your organization, as you mentioned, it will be your first deployment. You need to understand difference between a matured EA deployment and first start-up. Deploying EA is a maturity cycle and many of the practices of a matured organizations may not be relevant to you. Take very initial approach and define scope and objective of deploying EA for your origination. Main steps in EA are analyzing, planning, designing, implementing and reviewing. since this is your first deployment, steps involved in each stage may differ. Depending upon necessity, project you undertake, you may want to start with EA and then keep auditing and reviewing your implementation and take next steps to gain maturity. Takin too much time to start or spending too much resources on any of the stage my kill overall initiative of EA and you may get lost in your vision. EA is too large scope, hence it is critical you first finalize scope and resources first.Asst. Director of IT in Software, 51 - 200 employees
An enterprise architecture (EA) is a conceptual framework that specifies how enterprises should be structured and run. Determine how an organization can successfully accomplish its present and future goals by using enterprise architecture. 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.
CTO, Cybersecurity in Finance (non-banking), 10,001+ employees
Is this chatgpt answer?
Director of IT in Finance (non-banking), 1,001 - 5,000 employees
Ensure that EA is not just an IT function, needs complete business support and sponsorship, as mentioned by GW below.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.
VP of IT in Real Estate, 201 - 500 employees
Enterprise Architecture is not just an IT initiative; you'll need buy-in across the company - and the earlier, the better. This is also not just revamping/re-analyzing workflow, but putting in standards and infrastructure processes that will align with business goals and support digital transformation. EA is also about constantly evolving, with sometimes shifting priorities in support of modernizing technology as much as still supporting those business goals.Measure - manage - measure again - learn - react - repeat. Don't let department/project leaders live in silos; they need to communicate with each other vertically and horizontally throughout the organization to ensure their teams continue working in the same direction.
Good luck!
Director of Operations in Education, 2 - 10 employees
The first stage in developing an enterprise architecture is to begin with selecting an EA framework that is suitable for your enterprise. The first stage is organisation, which includes setting up the development team, determining the project's scope, and outlining the target vision that would help doing it more efficiently.IT Operation Manager at Yotta Infrastructure Solutions in Services (non-Government), 1,001 - 5,000 employees
The first stage in developing an enterprise architecture is to begin with selecting an EA framework that is suitable for your enterprise. It should align with the business need and requirements of the organisation and outlining the target vision that would help doing it more efficiently
Director of IT in Education, 2 - 10 employees
Work on the EA Inplementation as a whole, connect and communicate with all teams related to business information and work on a roadmap that factors the current state at your organisation.Director in Manufacturing, 1,001 - 5,000 employees
Fantastic comments by allI will only add that you should ensure you are offering services. Eg don’t set the strategies and standards and consider it done. Be ready to help teams implement and execute your architectures. It will also insure your architects are realistic technically and economically. I can’t stress the economics enough!!
CTO, Cybersecurity in Finance (non-banking), 10,001+ employees
I would also add to ensure that once directions are defined, they are actually implemented. To do so, you need to be sure that EA as a voice in prioritization and allocation of budget. Such voice needs to be embedded in the processes and not based on personal/team influence.
Content you might like
CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.Sales and Marketing7%
Operation41%
Customer Interaction19%
Compliance13%
Risk and Fraud Management5%
Strategic Planning2%
Finance/Accounting3%
Data Security and Privacy6%
274 PARTICIPANTS
Director Global Network / Security Architecture and Automation in Finance (non-banking), 10,001+ employees
Nothing ever dies in Enterprise. Why did Broadcom Software buy Symantec and VMWare, why did SDX Central post a story today about MPLS and how it lives on. Why is the hot news about cloud repatriation becuase a terrible app ...read more
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.
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!