Trends in EA in 2023
In the course of my work this year, I have had the opportunity to work with technology leaders in multiple organizations who recognize that their respective organizations need to change in order to better adapt and compete in their respective industries.
Consequently, several consistent themes keep popping up that have demonstrated value to clients, or which have the potential to significantly shape how technology organizations change and adapt through 2024 and beyond to better support their business.
All the content below reflects my personal observations and predictions. I record them here mainly for posterity, but perhaps they will be of some interest and value to others.
I should also note that I did not use GenAI to create any of this content.
If you find any of these topics of particular interest to your work, please do reach out!
The topics, in no particular order, are as follows:
Dependency Management
Dependency management has always been a challenge for technology teams. However, given the complex technology landscape in modern enterprises, every technology-dependent business outcome has architectural dependencies that must be managed to ensure projects are effectively scoped, sequenced and delivered to achieve strategic goals on an on-going and iterative basis.
?A significant part of the discipline of Enterprise Architecture is about understanding the relationship between 'things'. We chose to partner with Ardoq to use their dependency management tool to help accelerate key architectural decisions around scope, prioritization and sequencing for clients driving transformation efforts, and found it to be an innovative way to approach this challenge.
?Outlook: Expect an increased demand on enterprise architecture teams to provide tools, techniques and support for business technology planners and PMO teams so they can better manage program dependencies and agile project sequencing that ensure strategic architectural goals can be met.
?Project-to-Product
The 'project-to-product' movement has been around for a few years, and is gaining traction within enterprises, especially within CTO organizations, prompted principally by the need to manage the complexity, cost and risk of increasingly bloated enterprise technology environments.
The essence of taking a product-driven approach to technology management is to be intentional about what functionality to build into a technology solution, and to be able to tie it back to business value. This enables digitally driven transformations, where there is an increasing focus on generating a 'value-flywheel effect' on technology investment - that idea that instead of the cost of change rising with technology investment, the cost of change actually decreases.
In addition, many enterprises are incentivized not to take a product mindset to technology investment, as financial incentives are heavily oriented towards funding projects and not products (e.g., using Capex to spread project costs over multiple years). This generally results in an overly complex and disconnected approach to technology investment, where project outcomes prevail over other more strategic technology objectives.
Business-Technology change planning oriented around a product mindset and underpinned by modern agile architecture practices is an emerging area which enterprises are beginning to consider.
?Outlook: Enterprises will seek to demonstrate what 'good' looks like for pilot technology portfolios and use that to drive IT transformation agendas across the enterprise. The pace of change may be slow as supporting functions, such as Finance, must also adapt their practices.
Scaling IT Processes
A common problem for IT departments is how to define IT software development lifecycle processes that can scale to support many different applications, platforms, quality and control requirements.
With traditional SDLC processes, this problem becomes intractable, as procedures can vary within and across teams, even with the same underlying tools. For complex, regulated environments, this may lead to many control-related issues which impede IT's desire to become more agile.
The Open Group's IT4IT v3.0 reference architecture standard allows end-to-end SDLC processes to be defined in ways which enable modern agile processes optimized for individual product portfolios, but which share consistency in information flows. This enables end-to-end management and optimization of enterprise IT processes, to better support complex cross-portfolio change initiatives, as well as improving development/operations feedback loops.
Used effectively, IT4IT can provide an effective 'north star' to guide enterprise IT's ongoing transformational improvements in end-to-end SDLC process automation, in alignment with business digital transformation goals.
Outlook: As enterprises build out their digital capabilities, the benefits of using the IT4IT standard to align processes and information flows across internal portfolios, managed service providers and software product vendors should become more evident, leading to increased adoption and acceptance.
Reference Architectures
Large, complex enterprises are increasingly turning to enterprise architecture to help make sense of the complexity of their technology environment and guide effective decision-making to minimize potentially costly misalignments between technology and business goals and objectives.
However, progress has been slow partly because business area do not understand how business architecture helps IT planning, and IT organizations do not have the skills internally to bridge the business/IT gap.
As business architecture as a practice has matured, there are an increasing number of mature, well-defined reference architecture standards that can help accelerate IT's ability to engage business stakeholders in meaningful ways, and which enables more collaborative, cross-silo, strategic technology planning. Good examples are the IT4IT v3.0 reference architecture, the BIAN reference architecture for banking, and the various Industry Reference Architectures published by the Business Architecture guild.
Using these reference architectures, aided by data-driven visual collaboration tools such as Ardoq, enables rich conversations between business and IT stakeholders, without getting bogged down in technical discussions.
Outlook: Business technology planning teams will increasingly rely on reference architectures to streamline complex initiative planning across multiple stakeholder groups and ensure well-scoped technology projects that enable delivery of technology strategic objectives that better enable business goals.
领英推荐
Generative AI Use Case Management
Organizations have rightly recognized that Generative AI (GenAI) is a game-changer, but a key question facing enterprises is how to leverage the technology for maximum business benefit.
Every business capability has the potential to be significantly improved or completely re-imagined through the use of GenAI.? But where to start? By leveraging reference architectures, and mapping capabilities in those reference architectures to enterprise applications and/or services, a GenAI adoption strategy can be articulated.
For example, almost all 3rd party software vendors will include GenAI capabilities into their product roadmaps, so they can be leveraged by enterprises as they are made available. Some enterprise capabilities may be differentiating, and may require more bespoke GenAI focus, using internally fine-tuned large language models (LLMs) or using Retrieval Augmented Generation to leverage internal datasets.
The output of this exercise will be a series of candidate projects, which can then be evaluated and prioritized on their individual merits.
Outlook: Generative AI, when provided with (non-proprietary) industry standard reference architectures used for business technology planning, can be used to accelerate identification and prioritization of business functions and activities that would significantly benefit from investing in Generative AI capabilities, and which are feasible to deliver in short timeframes.
Operational & Technical Resilience
Operational resilience continues to be a big theme for many organizations, and a significant focus for regulators. While many organizations have Disaster Recovery plans, they do not add to resilience, as they are typically only invoked in the event of a major disaster, such as losing an entire data center. The core concept of resilience is that failures (including cyber-related incidents) can and will occur, but the direct negative impact on customer experience should be minimal when they do.
?Infrastructure teams have long had multiple resilience levers at their disposal to ensure that if individual compute nodes, storage disks or network components fail, applications can continue operating with no user-noticeable impact. With the advent of cloud, even more programmatically driven resilience options are available.
?As operational resilience concerns move up the stack to application architectures, a much stronger collaboration is needed between business architects, solution architects and operations teams to ensure business solutions are resilient by design, in line with business needs.
?Technical resilience refers to the specific technical architecture patterns and practices that make a solution more tolerant to failure. Adopting resilience patterns can materially change the cost and complexity of a solution, so it is important that the risks, costs and benefits are fully understood by all stakeholders.
?Generally speaking, architecture teams should facilitate the creation of patterns for resilience that application teams can adopt at relatively low cost and which are directly supported by multiple developer, infrastructure and operations teams.
?Outlook: An on-going and increasing focus on operational resilience will drive demand for enterprise architecture teams to play a leading role in aligning business, technology and operational stakeholders in achieving operational resilience objectives.
?DevOps & Internal Developer Platforms
While the DevOps movement started out as a cultural change intended to breakdown communication silos between developer and operations teams, more focus is being given on technology-led ways to facilitate that change. The idea of an 'internal developer platform' (IDP) is taking hold, where enterprise infrastructure teams deliver their solutions to application teams through consumable digital products rather than through ticket-based services.
?The key benefit of IDPs is that consumption of infrastructure components is programmatically driven, enabling a much higher level of automation around infrastructure service delivery throughout the lifecycle of those infrastructure components. IDPs enable enterprises to provide opinionated infrastructure component configurations built on top of standard cloud services that comply with enterprise policies and are aligned with strategic infrastructure and technology objectives as well as enterprise resilience and compliance policies.
?CTO organizations recognize that may of the goals of business-led digital transformation cannot be fully achieved without the productization of core infrastructure services, but it will take time for traditional infrastructure and cloud organizations to learn and apply the software engineering practices needed to operate effective IDPs, due to the high level of automation required, as well as driving application development teams towards consuming those products in their solutions.?
?Outlook: More examples of what 'good' looks like for IDPs will emerge, through enterprise software vendors as well as successful enterprise initiatives, and enterprise infrastructure teams will continue to drive their transition from a physical and hardware-driven mindset to a software and digital product-driven mindset.
?Zero Trust & Enterprise Architecture
With the advent of cloud, enterprise information flows are no longer bounded by the network infrastructure that is controlled by the enterprise, and so traditional perimeter-based security methods are no longer sufficient.
?Zero Trust means that no technical service, device or application is trusted by default, regardless of where it lives on the network.
?Many of the concerns of CISOs implementing a Zero Trust strategy relies on data about the environment that are ideally governed by Enterprise Architecture teams. In particular, CISOs need to know the enterprise protect surfaces, locations of sensitive data, application inventories, critical service inventories, and the relationships (transaction flows) across these components.
?Business Impact Assessments, when performed across recognized architectural dimensions, are a good starting place to identify protect surfaces. Within a given protect surface (typically a business application, but could be a capability or end-to-end process, or even a person), the sensitive data, application components, infrastructure services and business data flows need to be cataloged. CISO teams can then consume this information to implement appropriate zero trust security mechanisms.
?CISOs and EA teams should collaborate on the creation and maintenance of information necessary to enable Zero Trust. In particular, relationship mappings tools like Ardoq can be extremely helpful to enable Zero Trust teams to model protect surfaces in a data driven way, importing data from automated tools where possible to accelerate the mapping process.
?Outlook: Examples of increasing collaborations between CISO organizations and EA will help break down traditional barriers between these parts of the enterprise, enabling EA teams to demonstrate their business value, and CISO teams to greatly expand their productivity.
?Payments & ISO20022
Payments are a foundational capability for almost every type of digital transaction, and so it is not surprising that there is a lot of focus on making payment capabilities easy to consume - for consumers, merchants, payments providers, corporations and banks.
?ISO20022 is an international standard intended to standardize core aspects of payments processes within and between financial institutions and their customers and is being used initially to streamline cross-border payments through its adoption as the SWIFT international payment network's new messaging standard, which is expected to be fully operational by all member banks by November 2025.
?Within different markets, localized standards are being created to support digital payment innovation within those markets - these typically focus on consumer-oriented payments processes initiated from mobile phones, web sites, etc. and are less focused on B2B payments processes. Examples include APIs from fintech's such as Stripe (in the USA), PIX (in Brazil), and PayPal (Europe), as well as open banking standards defined in markets such as the UK, Europe, India, Nigeria, and Singapore.
?These innovations enable a rich exchange of information between payment network participants, allowing higher-value payments-related services to be delivered - but they also necessitate a complete modernization of legacy applications to fully exploit these new capabilities.
?Outlook: Enterprises will start to focus on existing processes and technology that result in payment instructions being created, to look at opportunities to fully leverage new capabilities offered by ISO20022-compliant FSIs to automate, enhance and optimize internal and client-facing services, including exploiting opportunities provided by real-time payment capabilities.
ERP Project Manager at Shire of Dardanup
11 个月Nice article Darragh. Ardoq looks interesting.