Why Enterprise Architecture Use Cases Matter
Too many Enterprise Architecture Teams struggle. When we develop Enterprise Architecture Teams, we start with the clear best practice and ask, "what change do the stakeholders want help with?"
We focus on use cases, because the basic activity enterprise architects perform is the same. We develop an enterprise architecture that helps stakeholder make better decisions and lead successful change initiatives. That is why we can have the universal basis of the TOGAF standard.
We do the same things. The only difference is the question we are answering. Different questions mean we analyze different things, with different base problems.
When we know the use case, we can design the enterprise architecture team. Then we can develop the enterprise architecture team. During team development, you should harvest value.
Enterprise Architecture Uses Cases Describe Types of Change
We use the following classification to describe enterprise architecture use cases. First, are broad types of change. Second, the TOGAF patterns of successful enterprise architecture teams. Third, common problems that are worth focusing an enterprise architecture team on.
Broad Types of Change Enterprise Architecture Use Cases
Strategic or Disruptive Change Use Case
Enterprise Architecture Team Pattern Use Cases
Supporting Strategy Execution Use Case
Supporting Portfolio Development & Execution Use Case
Supporting Project Execution Use Case
Supporting Solution Delivery Use Case
Common Problem Enterprise Architecture Use Cases
Application Portfolio Rationalization
Develop your Enterprise Architecture Team with Enterprise Architecture Use Cases
The third step of developing your Enterprise Architecture Team is knowing what type of change your enterprise expects you to support. What you could do is irrelevant. What you think is valuable is irrelevant. What a pundit suggests is the 'best EA Team' is irrelevant. Sadly, most enterprise architecture maturity models suggest a 'best purpose.' Align your EA Team to the Use Cases valued by your enterprise.
Broad Types of Change Enterprise Architecture Use Cases
An enterprise will need to change in one of two ways, disruptively or incrementally.
Disruptive change will be deliberate or reactive. Either the enterprise will embark on a deliberate strategic initiative or it will react to a threat or opportunity in its ecosystem. When we do a deliberate disruptive change, we'll usually call it Strategic Change.
When an enterprise embarks on disruptive change, it is struggling for survival.
Incremental change is far more common. Hundreds, if not thousands, of times more common. The reason is simple. Most of the time, our organizations are successful. We are profitable. In the public sector, we deliver on our mandate. During incremental change, we are performing minor course corrections. Part of the continuous improvement organizations always do.
Strategic or Disruptive Change Use Case
Apart from words that make us feel better, all disruptive change means we are changing course to survive. Our organization is at risk. We must make significant lasting change.
We will change a course for internal reasons or in reaction to external forces. Most often, we react to an emerging opportunity or threat in our environment. Here, the enterprise architects are trying to help seize an opportunity or dodge a threat. The ability to perform disruptive change depends on your enterprise agility.
In short, a strategic change alters how an organization intendeds to engage its environment. The symbiosis of the organization and its environment forces the conversations about the environment.
Implementing strategic change involves making adjustments to a company's key traits, sometimes in response to fresh market risks or possibilities. This shift results from higher management, in particular the Chief Executive Officer. The process of making adjustments to a strategy is known as strategic transformation. A strategy is a long-term plan to accomplish specific goals. Strategies should focus on long-term transformation since they are directed at the future. To remain relevant in a market that is always changing, this is essential. The practice of managing the strategy in a disciplined manner to accomplish corporate goals and missions is known as strategic change management.
Strategic change has a few drawbacks, including being difficult to foresee and manage. Because of this, many companies make plans for all possible outcomes. Strategic change management is crucial for a company's long-term viability. Companies that reject strategic change will eventually be forced out of the market; Nokia is a well-known example in the smartphone sector. Businesses won't thrive if they aren't ready for abrupt, unanticipated, and drastic changes. Many businesses make the claim of transformation, but they rarely actually do it.
Businesses base their judgments on information, facts, and scenarios because they are unable to foresee the future precisely. Those circumstances are very significant. What if these things happened? How would that affect how we operate? Finding a needle in a haystack may seem like it, but many huge businesses have withstood upheavals by foreseeing events that may have looked improbable at the time. This includes risk management as well. If a business predicts something will occur in the future, it has two options: accept the risk or lessen the risk.
How We Design Enterprise Architecture Teams for Strategic Change Use Case
The most critical Enterprise Architecture Capability to support strategic, or disruptive change is being able to develop Architecture Roadmaps. In particular, your EA Team needs to develop Roadmap Scenarios and Architecture Roadmap Type 4: Scenario Analysis across multiple candidates.
We recommend the Seven Levers of Digital Transformation for a concise understanding of disruptive digital change. All strategic change alters an organization's engagement with its environment. When an organization is undertaking a Digital Transformation, Lever 7 - Ecosystem and Business Model include altering the environment.
Last, we know that engagement with stakeholders will include exploring direction. In terms of the TOGAF ADM, the team will explore multiple Phase A Architecture Visions. This will require staffing with people comfortable with ambiguity.
Characteristics of Enterprise Agility
Alertness: can you detect opportunities and threats?
Accessibility: can you access relevant information in time to respond?
Decisiveness: can you make decisions using the available information?
Swiftness: can you implement your decisions in time available?
Flexibility: what are you doing to reduce the barriers to action? Think of your stretching exercises
Incremental Change Use Case
Incremental change is the most common enterprise architecture use case. It is a natural sweet spot for an Enterprise architecture team. Tackling a problem space usually involves optimizing change. Breaking it down to provide change projects terms of reference and clarity of value delivery.
Incremental change is gradual change instead of abrupt or all-at-once changes. You'll prefer slow, incremental progress and improvement with change. Your preferred approach is to innovate with what already exists rather than always coming up with brand-new concepts or making bold, sweeping changes. You'll enjoy enhancing current strengths and viewing situations through the perspective of potential improvements. Plans are simple to divide into phases and comprehend when they are spread out over progressive timescales.
The status quo can be modified, adjusted, or refined by a process known as incremental change, which involves only small, straightforward modifications. Considering this description, it's critical to stress that this form of organizational change, also known as first-order change, doesn't modify an organization's fundamentals. On the larger scale of things, incremental change refers to relatively few changes made to pre-existing systems, hierarchies, models, goods, services, and processes.
In addition, incremental transformation combines several diverse traits. It mostly happens in a series of tiny stages. No one stage in the process takes an excessively long amount of time, even if it may take place over a long period. Sometimes the stages are planned out in advance, although it isn't required. Sometimes, when problems develop and are resolved along the road, these changes can place spontaneously and go unnoticed by management.
Implementing gradual change has various advantages. We closely connected it to those who build successful companies that persist for at least 10 to 15 years. You won't become paralyzed by grandiose thoughts, but will actually do things, one step at a time. Your track record speaks for itself; your continued success is a proof that anyone can rely on you.
In short, incremental change takes a strategic priority and ensures that change is optimized.
Most commonly, incremental change will improve one of:
- an organization's cost
- quality of products or services
- improve enterprise agility
Improve Cost
Organizations have been seeking to improve their cost position as long as we have had commercial organizations. The Deloitte Value Map provides a simple analytic frame to explore cutting cost.
Improve Quality
There are many non-architectural techniques aimed at improving quality, most notably Six Sigma. Today engaging enterprise architects to improve quality will mean a Digital Transformation.
The Seven Levers of Digital Transformation provides a framework for quality - are you speaking about:
- the quality of business process (Lever 1),
- the quality of customer engagement (Lever 2),
- the quality of products (Lever 3),
- the quality if IT & Delivery (Lever 4), or
- the quality impact of your organizational culture (lever 5)
Improve Enterprise Agility
The characteristics of enterprise agility are drawn from sports and the OODA-loop. The activities of responding to an unexpected threat or opportunity come down to your ability to observer change, decide what to do, and complete your response. All successful sport players work to close these cycles.
We call the 5th attribute of enterprise agility flexibility because of the sports root of the OODA Loop. Athletes practice and work on flexibility. Your organization should do the same. Reduce the barriers to observing a threat or opportunity, gathering information, choosing a response, and completing the necessary actions.
All of the best organizations we have worked with consciously work on continuous improvement.
How We Design Enterprise Architecture Teams for Incremental Change Use Case
The most critical Enterprise Architecture Capability to support incremental change is being able to develop Architecture Roadmaps. In particular, your EA Team needs to develop Architecture Roadmap Type 1: Heatmaps and Architecture Roadmap Type 3: Impact and Dependency.
Incremental change entirely depends on being able to analyze change against multiple criteria. An enterprise architect who is not comfortable creating Views is useless. Incremental change requires effective architecture trade-off.
Last, we know that engagement with stakeholders will include enabling change, and transitioning to planning change with sponsors. In terms of the TOGAF ADM, the team will develop clear Architecture Roadmaps. This will require staffing with people with strong analytic skills and experience leading effective change.
Enterprise Architecture Team Pattern Use Cases
The second set of enterprise architecture use cases comes from the purpose of your EA team. High-functioning EA teams will be optimized to deliver architecture to support strategy, portfolio, project, or solution.
I explained these purposes in the EA Team Leader's Guide and the Enterprise Architect Practitioner's Guide.
Enterprise Architecture to support Strategy Use Case
EA Teams that support strategy will deliver an end-to-end Target Architecture looking out three to ten-years, Their architecture roadmaps will typically span many change programs.
Enterprise architecture to support strategy is used to identify change initiatives and supporting portfolio and programs. Sets terms of reference, identify synergies, and govern the execution of strategy via portfolio and programs.
Enterprise Architecture to support Portfolio Use Case
Enterprise architects that support portfolio assist cross-functional, multi-phase, and multi-project change initiatives. Their deliverables will usually cover a single portfolio.
EA to support portfolio will identify projects, and set their terms of reference, align their approaches, identify synergies, and govern their execution of projects.
In the contemporary market economy, businesses must constantly adapt if they are to remain competitive. Such growth causes modifications throughout the organization at many levels. Changes must be carefully planned and monitored as they are implemented. EA approach and modeling languages offer for overall planning and stakeholder communication. Project Portfolio Management (PPM), which includes Program and Project Management, offers controlled execution and change delivery.
Since EA and PPM are two different approaches, it is crucial that they are fully linked with coordinated and effective business processes. Their combined implementation must produce more additional value than they would if done separately or without correlation.
Few resources are accessible for researching the integration of the EA and PPM fields. This may be because of a strong symbiotic relationship between these two approaches. Nobody has thoroughly investigated the difficulty of their integration yet. Many frameworks exist that attempt to address almost all facets of enterprise and IT change management, but none of them have and probably never will become internationally standardized.
Since project and portfolio management are not goal-oriented work management, EA cannot address it. What EA offers is a technique that identifies a number of work packages that have been agreed upon across the business and that must be planned, carried out, and delivered by PPM-managed projects. The management of changes in the enterprise at the level of organizational structure, application support, data structure, and technological infrastructure is thus handled jointly by EA and PPM.
Enterprise Architecture to support Project Use Case
EA Teams that support project are directly assisting their organization's project delivery method. They will usually work on a single project.
Enterprise architecture to support project will clarify the purpose and value of the project. It will highlight cross-project synergy and future dependency. A critical use is enabling architectural governance, and support alignment between projects.
Road maps are produced by EA as a deliverable to identify the connections between organizational capabilities and organizational objectives. The technique depicts a path of how these goals will be attained by listing various task packages between the existing processes and future state processes or goals, dependencies, and analysis of the gaps.
Goals broaden the company's vision. Goals are benchmarks necessary to achieve the company's vision. In order to produce an executable road map that will guarantee the realization of the business strategy, EA also encourages dialogue and offers a mechanism between the Project Management Office and the business leadership. In the absence of an EA department within an organization, a PMO may employ business analysis to compile IT requirements that support business objectives, highlighting potential intersections between EA and the PMO.
Enterprise architecture helps project management at the project or solution delivery level by specifying the work packages that are part of a project management strategy. To determine what has to be done to accomplish the specified goals, project teams consult a catalog of work packages. These work packages aid in resource management, which is important for project human resource management and activity resource estimation. To properly execute and oversee a project, both are crucial elements of a thorough project management strategy.
The project management office and business leadership consult with enterprise architecture. Working together with business executives, EA develops a structure proposal that includes all the requirements for the business architecture, including the purpose, vision, mission, capabilities, business goals, scope, process, and functional requirements.
Enterprise Architecture to support Solution Delivery Use Case
Enterprise architects working to support solution delivery usually are focused on a single project or a significant part of it. Their architecture defines how the change will be designed and delivered. It ensures understanding of constraints, controls and architecture requirements. It directly acts as the architecture governance framework for change.
Enterprise architects put in a lot of effort to find architectural gaps, evaluate potential fixes and dependencies, and identify and prioritize projects, but somewhere along the way, they lose focus. The Enterprise Architect is also involved in transition architectures, which show how the Enterprise Architecture will be in a certain condition at a point in time and how the project will progressively provide those transition architectures.
With the aid of enterprise architecture, all the recognized initiatives may have their estimated business value developed. We may argue that project completion takes time, and as Enterprise Architects are a busy bunch, they often move on to other urgent tasks within an organization and may no longer be aware of or informed about continuing efforts. Knowing which projects successfully finished and produced business advantages, and which ones were not, as well as the potential causes of success or failure for future planning, is helpful for portfolio management.
Take the praise if the project is successful and produces advantages, but if there are setbacks, look into the causes and determine if the beginning was flawed. Enterprise architects must-see projects through to completion, maintain open lines of communication with business stakeholders, stay in touch with project teams, and try to assure project success.
How We Design Enterprise Architecture Teams for EA Team Pattern Use Cases
When designing an Enterprise Architecture Team to support a standard purpose, we reach for the Enterprise Architecture Capability Reference Model.
Then we look at the key capabilities aligned to each purpose.
Support Strategy Capabilities
- Develop Enterprise Strategy
- Develop Departmental Strategy
- Develop Initiative Strategy
- Develop Strategy Roadmaps
Support Portfolio Capabilities
- Enable Program Establishment
- Develop Solution Architecture (Portfolio)
- Develop Program Roadmaps
Support Project Capabilities
- Enable Project Establishment
- Develop Solution Architecture (Project)
- Perform Procurement Support
- Develop Project Roadmaps
Support Solution Delivery Capabilities
- Develop Solution Architecture (Solution Delivery)
- Perform Procurement Support
Last, we know that the engagement model shifts at the purpose shift from supporting Strategy to supporting Solution Delivery. Along the Strategy-Solution Delivery continuum, Architects will shift from:
- exploring target architectures with stakeholders to performing governance for the stakeholders
- providing guidance and constraint to sponsors to performing governance for sponsors
In terms of the TOGAF ADM, the team's work products will shift depending on what pattern they support.
| Architecture to Support Strategy | Architecture to Support Portfolio | Architecture to Support Project | Architecture to Support Solution Delivery | |
| Phase A Work Product: Architecture Vision | Key deliverable
Before framing of a strategic planning session Refresh before initiation of program budgeting |
Key deliverable
Before start of budget planning |
Often not used
Activity to produce a vision overlaps with portfolio/program candidate architecture and architecture roadmap Deliverable can be used at initiation of business case |
Limited use
Primary use is prior to implementation cycle (via internal providers or execution partners) |
| Phase B, C, & D Work Product: Candidate Domain Architecture | Key deliverable
Primary use is stakeholder understanding of target and work. Secondary use is the creation of Architecture Requirements Specification for Architects |
Key deliverable
Primary use is stakeholder understanding of target and work. Secondary use is the creation of Architecture Requirements Specification for Architects |
Before project initiation and finalization of business case
Primary use is the creation of Architecture Requirements Specification for Implementers |
Before engagement of execution partners (including internal providers)
Primary use is the creation of Architecture Requirements Specification for Implementers |
| Phase B, C, & D Work Product: Candidate Roadmap Items | Key deliverable
Primary use is stakeholder understanding of work. Secondary use is the creation of constraints for Architects |
Key deliverable
Primary use is stakeholder understanding of work and dependancy. Secondary use is the creation of constraints for Architects |
Limited use Can be used as an input to projects with multiple interactive changes |
Before engagement of execution partners (including internal providers).
Primary use is identification of required change, and preferences of how to execute change, to manage solution delivery partner selection and engagement |
| Phase B, C & D Work Product: Architecture Requirements Specification | Limited use
Usually Architects can infer constraints from superior architecture. |
Limited use
Usually Architects can infer constraints from superior architecture. |
Key deliverable
Before completion of project initiation |
Key deliverable
Before engagement and contracting |
| Phase E Work Product: Candidate Enterprise Architecture | During strategic planning session
Refresh as required in program budgeting |
Key deliverable
Before start of budget planning Primary use is stakeholder acceptance of target and definition of gap |
Before project initiation and finalization of business case
Primary use is the creation of Architecture Requirements Specification |
Before engagement of execution partners (including internal providers)
Primary use is the creation of Architecture Requirements Specification |
| Phase E Work Product: Architecture Roadmap | During strategic planning session
Refresh as required in program budgeting |
Key Deliverable
Before start of budget planning Refresh as required to support budgeting and program management |
Limited use
Can be used as an input to projects with multiple interactive changes |
Before engagement of execution partners (including internal providers)
Primary use is identification of required change, and preferences of how to execute change, to manage solution delivery partner selection and engagement |
Table from TOGAF 10 TOGAF Series Guide: Enterprise Architect's Guide to Developing Architecture
Enterprise Architecture Common Problem Use Cases
We continually are asked to optime an enterprise architecture team for common problem-based use cases. Most of these enterprise architecture use cases are IT-oriented. They address EA questions with an IT-slant.
Mitigating Technology Risk Use Case
Technology debt. Many organizations pile up technology debt. When organizations face real cash-based debt, they do two things, address the source of the debt or declare bankruptcy.
Technology Risk is risk, pure and simple. Risk is the effective of uncertainty in meeting objectives. Technology that creates the risk of meeting objectives needs to be dealt with.
Organizations depend on technology to properly manage their operations across all industries. Cyber danger is a given with any technology and may take many different forms from many sources. The most frequent yet most avoidable causes of data breaches are IT failures, aging applications, and the infrastructure that supports them. The effects of a cyber disaster may be very challenging to recover from in terms of both monetary and reputational losses.
No matter how talented your team is, technology risk management is a vast, complicated problem that cannot be resolved by manual data upkeep. Enterprise architects can easily get up-to-date product data across all technologies. This knowledge is necessary to properly design, manage, and retire technological components as well as to evaluate the risk of application landscapes.
EA Team Design for Mitigating Technology Risk
When we face Mitigating Technology Risk, we use the Navigate SABSA Atlas and the Navigate Program & Portfolio Management Atlas. We pull SABSA's Risk Domains out and look at the technology in terms of Portfolio.
In all cases, you are looking for a clear, actionable roadmap to drive these results.
IT Modernization Use Case
Information Technology acts like other infrastructure - it ages. As it ages, IT increasingly fails to meet current hopes and dreams. We like to think about IT-infrastructure as infrastructure that doesn't physically wear out. Other infrastructure suffers wear and tear - a truck puts on miles. Wind, rain, salt, rust, share-rattle and roll. It wears out.
By contrast, IT-infrastructure keeps working. Think about an old Model-T. Starts, runs, leaks oil just like when it was new. However, it can't carry 50,000 lbs at 65 MPH like a modern semi-trailer truck.
Modernizing It is often like a fleet replacement - everything is connected. We love the theory, cutting out or moving away from resource-intensive applications. Find replacements for those with a high cost of ownership. Then you hit the reality of the old application processing a third of revenue, with the business focused on new services for new revenue.
IT modernization initiatives frequently use an incremental strategy, which involves gradually modernizing IT assets until the entire system has been upgraded. It has been shown to be helpful to modernize IT systems gradually, particularly to reduce the operational hazards that would arise if everything was done at once. The drawback of this strategy is that development teams operate in isolation and lack a broad perspective. Enterprise architecture integrates every layer of an organization, from business to IT infrastructure, allowing IT executives to prioritize modernization initiatives based on business objectives and see how these projects will affect their IT systems.
Enterprise Architecture connects business objectives with business capabilities in the context of IT modernization. In order to map present business capabilities and understand how they may evolve, enterprise architects collaborate with business teams. This will offer a clearer picture of how a capacity should develop in the years to come or whether it targets a new consumer category.
By aligning transformation objectives, business capabilities, and necessary IT functions in a timeline, enterprise architects may use an enterprise roadmap to capture both present and future business demands. The future IT architecture that will completely support the intended business capabilities will be defined.
Enterprise architecture may also specify future IT architecture, which is helpful. Enterprise architects map the present IT environment as a starting point. To do this, an organization's applications and technology must be inventoried. Application lifecycles, costs, deployments, exchange flows, and how they serve the business are just a few of the aspects that may be used while doing an application inventory. Enterprise architects can create new IT architecture based on the recognized business capabilities when the application inventory is complete. Business capability maps help demonstrate the IT resources needed to support business operations as the organization changes to address fresh problems.
Through IT modernization initiatives, certain components or portions of the IT environment can be updated to meet the new business capabilities after the intended IT architecture, including applications and technologies, has been established.
Last but not least, enterprise architecture may coordinate your IT plan with your corporate goals. Each project comes with a rationale, or business case, outlining why it should be done, along with costs, resources, a timeframe, and any potential dangers.
Companies might assemble an executive council made up of both IT and business experts to prioritize these initiatives. Projects are prioritized by bringing together both sorts of leaders according to the goals of each stakeholder.
We may form the IT roadmap once tasks have been prioritized and placed in a timeline. A declaration of the strategic business goals, a project timeframe, a business case, the expected cost, and the length of each project are all necessary components of an effective IT roadmap.
EA Team Design for IT Modernization
Good enterprise architecture teams help with a get a clear view of your IT investments, their current value and provide pragmatic advice about where to invest. Investment advice is a Portfolio problem. IT Modernization is not just a technology problem. We always strengthen the Business Architecture capability because designing just for technology will not succeed.
To enable the IT Modernization Use Case, we align to designing for Architecture to support Portfolio.
Digital Transformation Use Case
Far too often, we see people talking about Digital Transformation and Cloud Transformation as an infrastructure switch. What nonsense.
There are Seven Levers of Digital Transformation. You can control all Seven Levers or you can try to change without control of your trajectory, speed, or ... Each lever enables or disables a different change feature.
- Lever 1 - Business Process Transformation
- Lever 2 - Customer Engagement and Experience
- Lever 3 - Product or Service Digitization
- Lever 4 - IT and Delivery Transformation
- Lever 5 - Organizational Culture
- Lever 6 - Strategy
- Lever 7 - Ecosystem and Business Model
EA Team Design for Digital Transformation
Digital Transformation will need some strategy questions answered. However, many can be answered quickly, leaving execution. As a result, we align to designing for Architecture to support Portfolio.
Cloud Transformation Use Case
New value-generating service-driven company models are now possible thanks to cloud technology. Cost reductions, productivity gains, accelerated time to market, and the capacity to grow with demand are just a few advantages of cloud computing. After switching to the cloud, businesses may also significantly increase asset utilization, save operating costs, and reshape relationships with their IT employees.
A significant factor in determining IT and business strategy is the cloud. But understanding cloud transition is seriously hampered by complicated corporate environments and continuously evolving technology.
Major organizational, operational, and technological changes are needed to successfully migrate to the cloud. Budgetary restrictions, the requirement for exponential growth, the intricacy of business rules as they get more sophisticated, and external laws are just a few of the obstacles that affect cloud adoption along the road. The ability to implement a roadmap from traditional infrastructure to the cloud is a must for enterprise architects.
Corporate Architecture offers an automated, all-encompassing perspective of multi-cloud infrastructures at the enterprise scale, which aids in the governance and improvement of your cloud projects. A wide range of elements, including existing and future capabilities, the application portfolio strategy, operational and organizational questions pertaining to people and processes, as well as cost indicators, should be taken into account for a successful cloud transition. To reduce risks and uphold compliance across cloud deployments, it is essential to fully comprehend these complexities. In order to simplify the import of data, enterprise architecture integrates with top cloud providers and offers a perspective on cloud architecture. Enterprise architects may specify target capabilities, choose whether apps should stay on-premises vs transfer to the cloud, and define target capabilities.
EA Team Design for Cloud Transformation
Cloud Transformation is a Portfolio problem. The enterprise is re-designing its IT Organization. We always strengthen the Business Architecture capability because designing for technology will fail.We must re-architect the IT Organization.
To enable Cloud Transformation, we align to designing for Architecture to support Portfolio.
Application Portfolio Rationalization Use Case
We can do well Application Rationalization, or poorly, When done well IT expenditures can be reduced by over 20%. When done poorly, there is no saving. Ever.
Application rationalization is driven by business impact and business value - not IT cost. You need to groom your IT portfolio according to technical profile and business value. Invest in those with a future-ready technical profile and business value. Explore the best ways to retire or replace those holding you back.
The business side frequently ignores the requirement to coordinate the supporting IT landscape since it is primarily concerned with promoting economic development. As a result, different apps are frequently introduced at different times as needed by different teams. The business side is blind to the fact that having an IT environment consisting of applications with conflicting lifecycles, duplicate technologies, and overlapping functionality frequently leads to serious integration problems and organizational inefficiencies. Operating a costly, restrictive IT environment results in hundreds of millions of dollars more spent on IT while immediately lowering satisfaction and service quality for people who depend on it.
Large businesses frequently launch a sizable number of apps all at once. As a result, running older systems and maintaining applications consume a sizable portion of IT expenses. These programs don't all have to be mission-critical. Enterprises benefit from having a properly rationalized application ecosystem to remain on top of modern innovation trends, deliver world-class customer service, cut costs, and expand worldwide. Although application reduction projects need a onetime expenditure, the savings far surpass the cost.
Enterprise architects can start working on optimizing the application portfolio as the business side continues to authorize the acquisition of apps left and right.
Enterprise architects can first gather all pertinent data about all deployed apps and import it into their preferred software. Enterprise architects can determine the application rationalization project and prioritize it based on the operating model of their company by starting with a particular core process or one entire business unit, for example, from this organized view of the entire inventory of applications and their direct business value.
Enterprise Architects may then use the application matrix and application rationalization surveys to swiftly evaluate the utility of apps and offer data-driven recommendations on which applications to tolerate, invest in, relocate, or remove.
Enterprise architects will now have the knowledge they need to create a roadmap for carrying out the rationalization effort through a series of decommissioning initiatives. This road plan can also be used as a benchmark in the future to determine if additional apps are required or not.
EA Team Design for Application Rationalization
Application Rationalization is a Portfolio problem. Application Rationalization always fails without a solid Business Architecture. We always ensure the EA Team has a business architecture capability, even if we focus it on reverse engineering.
We align to designing for Architecture to support Portfolio for the Application Modernization Use Case.
Acquisition Integration Use Case
Always integrate acquisitions in accordance with the strategy & the purpose of the acquisition.
An acquisition will be done for a few simple reasons
- acquiring customers
- acquiring products
- acquiring physical assets
- acquiring capability
We like the Medical oath, First do no harm. If we made an acquisition for the customer base, then our integration needs to first ensure we keep the existing customers.
Acquisitions for Capability are the most difficult. Typically, here the acquiring company has a gap and is looking to speed-up its capability development by using the new capability. We use this example of capability development in our on-demand course Enterprise Architecture with TOGAF and Navigate course.
Corporate and private equity leaders predict that merger and acquisition activity will go up in the upcoming years, both in terms of volume and dollar value of acquisitions.
However, mergers and acquisitions frequently fall short because the firms involved cannot properly integrate or cannot achieve the projected synergies. There are several reasons IT integrations fall short. After a merger, it is extremely difficult for two organizations to successfully integrate their IT systems while still maintaining commercial operations. It is necessary to unify various technological items, standards, and procedures.
There are several starting conditions for mergers. Sometimes a big business eats a tiny one, and other times a merger happens between equals. Gaining technical proficiency or capturing new geographic markets are two possible goals. Enterprise Architecture has the potential to be extremely important to the success of the IT integration in each of the aforementioned scenarios. The foundation for choosing the appropriate applications for a common target IT environment is provided by enterprise architecture, which helps to rationalize applications, consolidate locations, and consolidate locations. This enables businesses to take advantage of synergies, make savings, and strategically align their operations going ahead. The long-term success of a merger is influenced by the creation of synergy between two IT departments.
EA Team Design for Acquisition Integration
Acquisition Integration is a Portfolio problem. An IT-centric Acquisition Integration will always fail. Business architecture is the foundation of effective integration of acquisition. Without knowing why your company made the acquisition, the default approach is to change the acquired organization. Change it to the point of destroying the value proposition. The EA team needs a solid business architecture capability, even if we focus on reverse engineering.
The second critical capability is Risk Architecture. Those simple reasons tell you what value needs to be protected. Navigate's Governance, Risk and Compliance Atlas uses Asset and Risk to clarify what needs to be protected and what threats will damage the asset.
We align to designing for Architecture to support Portfolio for the Acquisition Integration Use Case.
Security Architecture Use Case
The SABSA focus on value, either through realizing a benefit or preventing a downside, is critical.
As an enterprise architect, your job is to protect the asset and remove the uncertainty. Your organization is most secure when it has certainty that it will meet its expectations.
To put it simply, security architecture is the portion of enterprise architecture that is concerned with protecting corporate data. An organization's fundamental security policies and practices for protecting data are described by its security architecture, which also includes personnel teams and their roles and responsibilities, as well as other systems. This is a more complete explanation of security architecture. To assist ensure that the security architecture matches both present and future business demands, this information is supplied in organizational requirements, priorities, risk tolerance, and related considerations.
For informing security planning at all levels, having a strong security architecture is essential. It offers the in-depth details needed to make the best choices on the procedures and solutions to use throughout the IT environment, as well as how to manage the technology lifecycle. A thorough documentation and publication of the business information security architecture is also essential for adhering to the various current industry standards and legal requirements.
A collection of tools from TOGAF are available to build an enterprise security architecture from the ground up for the first time. It aids in defining precise goals and bridging the gaps between your EISA's many levels. The TOGAF framework is flexible enough to help you when the security requirements of your company change.
EA Team Design for Security Architecture Use Case
The Security Architecture Use Case will focus on removing uncertainty or reducing threat. In both cases, this is a Portfolio problem.
We leverage Navigate's Governance, Risk and Compliance Atlas that combines Asset with Risk and Threat. We look at things of value. What threatens their value, and what creates uncertainty. The foundation for addressing uncertainty and threat is Risk Architecture. Navigate's Governance, Risk and Compliance Atlas uses Asset and Risk to clarify what needs to be protected and what threats will damage the asset.
We leverage Integrating Risk and Security with TOGAF. We wrote this guide with the SABSA Institute brought best-practice Security Architecture and Enterprise Risk Management.
We align to designing for Architecture to support Portfolio for the Acquisition Integration Use Case.
Final Thoughts on Enterprise Architecture Use Cases
There is no reason for Enterprise Architecture Teams to struggle with engagement. Every organization's leaders are looking for useful advice on effective change.
The difficulty is when the EA Team follows one of the two failure patterns. Either they:
- do not support the use case the stakeholders want help with
- try to use the stakeholders to drive some' else agenda
We design and develop EA Teams for a living. We focus on these use cases, because it drives our attention to the change that matters. Keep in mind that the Common Problem Enterprise Architecture Use Cases are almost always addressed by an EA Team design to support Portfolio.
When we know the use case, we can design the enterprise architecture team. Then we do the same three things:
- Improve your architect's skills
- Develop your enterprise architecture method
- Enhance your organization's use of architecture
If you want help to develop your EA Team - reach out. We'd like to help. With our Predictable EA Approach, we ensure you have useful enterprise architecture being developed as your team develops.