Comprehensive software reviews to make better IT decisions
Enterprise Architecture and Agile
The meaning of “agility” is a bit different at different architecture levels.
At the business architecture level, agility means the ability to regroup/change/remove/create new enterprise capabilities to remain relevant and competitive on the market:
- Represent the organization as a combination of capabilities forming value streams.
- Identify the core capabilities and the ones that can be eliminated/reduced/offshored.
- Create new value streams from either existing or new capabilities.
At the services architecture level, agility means the ability to change, plug in, or unplug services, thereby rearranging processes in order to optimize existing services or create new ones:
- Scale services without changing the components.
- Change components without changing interfaces.
- Keep defined inputs and outputs (service interface) for pluggability and composability.
At the platform and infrastructure architecture levels, agility is minimal and cannot be governed by any Agile framework; however, the enterprise architecture becomes essential for the right selection of a platform or infrastructure/cloud since it should understand how the selection supports the agility of the upper levels.
Traditional Agile frameworks are designed for the level of application code development – which is inside the service encapsulation. It implies that enterprise architecture (EA) does not have a direct impact on the processes inside the Agile framework but serves only as a governance framework for the AppDev Agile in the form of policies and best practices – foregoing procedures and standards.
EA also provides the technology environment for Agile as it controls the platform selection.
EA must understand the varying degree of agility across the levels and help create the governance and technology environment that accounts for these differences:
A special case – which creates a lot of confusion in Agile-related discussions – is when the enterprise creates software products as its core business. Maybe the right approach to this special case should be to place the product “business” design (e.g. business canvass creation) at the level of the business architecture, encapsulate development of product modules as services and apply Agile framework to code creation within the service encapsulations.
From the business architecture perspective, agility does not mean the ability to successfully repeat certain processes (which is the focus of Agile in AppDev) but rather the ability to quickly change structurally and operationally to react to external changes or to create new business value. Enterprise architecture comprises business and service/application architecture – therefore, it needs to provide an environment for harmonized agility at each level.
Want to Know More?
This note outlines some tips and tricks that you should be aware of when embarking on the installation and configuration of a Kubernetes cluster. Such an endeavor should only be attempted if the need for an enterprise-grade container orchestration solution is required.
These are the trends we predict will be most important is it relates to Enterprise Architecture in 2021.
Lean IX and Apptio have partnered to produce an integrated solution that better informs the strategic decision-making process with improved visibility into an application’s total cost of ownership and alignment to business capabilities.
This note outlines some of the fundamental KPIs that you should measure to show the success of the enterprise architecture team. It also discusses how you measure them and visualize the result.
The application portfolio management (APM) tool space can be a confusing one, as many software vendors offer their own take of what APM is. Enterprise architecture, application management and project portfolio management tools offer an APM use case, but these are often quite skewed the primary function of the tool.
Application rationalization fails when the chosen framework does not match your scenario or the goals for your application portfolio. This note looks at how to apply application rationalization during an M&A.
Often people misidentify the purpose of application rationalization, leading to misuse and unsatisfactory results. We try to break application rationalization down to its simplest form to understand how to make the most of this critical IT function. tr
Measuring technical debt is important, but more important is communicating the implications of this problem in terms of risk to business capabilities. Cast Highlight tools are used for application portfolio management (APM), specializing in applying code analytics to business decisions regarding your organization’s applications.
Many application rationalization tools and frameworks miss the true benefits of this practice, as they only assess the individual application without consideration for its redundancies. Infusing an enterprise architecture perspective, as seen with LeanIX, will generate the bigger savings you are looking for.