Most companies I speak to share a similar goal: to adopt best practices and leverage available solutions to free up resources and focus on true areas of differentiation or innovation. My job, of course, is to tell them how to do this. While my advice to each customer is unique- reflecting their historic business and IT evolution- there are some common “must get rights” when trying to realize a target architecture.

I’ve pulled these imperatives together in this blog with the aim of introducing you to how this can be achieved by being both sympathetic to the current architectural start point and pragmatic about reaching a target architecture in a seemingly never-ending sea of business and technical change.

First, what is a transformational architecture?

To meet an ever-growing range of business & IT needs, companies require a transformation in architecture that can leverage the available solutions and, when required, deliver more bespoke solutions. This will often require a fundamental re-assessment of how solutions are supported via a more open and adaptable Enterprise Architecture.

Combining re-fashioning and re-designing into ‘transformational’ capabilities within an enterprise’s architecture is one way to ensure effective delivery of functions and services to the business.

For this, I recommend people focus on how they can deliver a more “transformational architecture.” What I mean by this is an architecture that can meet the following two main goals:

• Re-fashion the existing architecture: Support, develop, and re-model the existing architecture to enable a gradual readiness and transition to any future state enterprise architecture which allows you the time needed to start to support newer delivery options.
• Re-design for a future architecture: Aim to realize a new architecture for both - a target operating model, and also a model that allows much more open and flexible delivery through on-going changes in design and delivery practices. This “re-design” may include (and imply) a more fundamental change in the underlying architecture, and hence signals a larger step change in approaches and practices.

Combining re-fashioning and re-design into ‘transformational’ capabilities within an enterprise’s architecture is one way to ensure effective delivery of functions and services to the business.

To support this outcome, the enterprise architecture (and underlying Business and IT solutions) needs to go through some initial changes that start to unlock new capabilities. After this initial change, you will be better able to support larger and more fundamental step changes in delivery (so both small and large change phases may occur). Lastly, be aware that this is not a ‘one off’ process, and there needs to be an ongoing task to review and update the enterprise architecture so it can keep reacting to changes and go through continuous improvement and evolution.

Understanding the architectural challenge(s)

Many companies have large enterprise applications that form significant core pillars of their architecture, so embarking on fundamental digital transformation projects (often in conjunction with a move towards cloud enablement) can be daunting - especially when you add in the fact that the actual internal architecture of these enterprise applications has fundamentally changed as well.

My background is with both SAP (one of those large enterprise applications) and strategic infrastructure solutions such as integration layers and data management solutions. More recently, I’ve added open ‘side by side’ cloud development to this too, to help my customers minimize change in their core ‘best practice’ applications. Why is this important? Because I see that the change challenge from both angles and know how critical having a blend of experience across these areas is when updating your enterprise architecture.

So how do I approach delivering a transformational architecture?

In short, working with the people already in the company and helping them become aware of newer practices and approaches can help bring transformation in architecture. Fundamentally, it is agreeing how critical the import of an overall technical architecture and its underlying principles and design is, and to update this not just for a digital transformation program but also for the ongoing business use to support wider business aims.

Enterprise Applications – but not as you know them

SAP and many other vendors now have much more open solutions, and understanding how these solutions are realized within a hybrid (multi-vendor and flexible design) landscape is critical. Looking specifically at larger applications such as SAP, their own internal architecture is designed to support key principles to ease delivery within the SAP domain of solutions. With SAP, in particular, there is now a common one data model, best practice functional processes, configurable solutions, and “open” services and features for integration or reuse. These have historically been within the SAP platform, or at best “open” in an “opinionated” manner. Yet, as SAP has moved to a more domain-based delivery (of a collation of cloud or even on-premise solutions), including associated extensions or innovation options, so too has the SAP architecture changed.

SAP’s architecture has gone through a fundamental shift. Fiori 3.0 now provides a consistent user experience across SAP products, the One Data Model is also aligned across SAP’s domains, and looking ahead, integrations will be via common APIs regardless of the application being updated as shown by the Graph (available from 2022). This means that while application delivery, such as via SAP solutions, will still have its own specific considerations, the overall corporate enterprise architecture also needs to have its own wider underlying principles, framework, and architectural objectives. Additionally, the wider architectural objectives of a corporation cannot remain static. This is why transformational architecture is needed that will allow continued improvement and evolution.

Often, enterprise architects will naturally look towards recent open and cloud-first architectural strategies and trends to inform their vision and design of a target architecture, However, I would argue that large applications and delivered solutions or services with their own architectural frameworks still have a significant part to play in any solution. This can include large full domains of solutions, such as an ERP like SAP, or how component parts of a business function or service can be reused or plugged into other solutions in a composable manner.

Delivering a transformational architecture

Most companies still want to have a large portion of standard business processes supplied by vendors such as SAP. Whether this means full end-to-end best practice process or component parts, there will be a large percentage of standard functionality utilized. The key question when delivering transformational architecture is: how will these standard processes, services and functions be combined into a single user experience with seamless integration a common approach to items such as data, security, reporting and analytics?

Obtaining business solutions for a domain of expertise, such as ERP processing, human capital management, or warehousing potentially simplifies some of these challenges. And the solutions themselves come with a pre-supplied architecture that has often been redesigned for cloud and open delivery. However, these Line of Business (LoB) solutions and domains still need to interact with each other and (ideally) with common support services for observable monitoring, operating, and development.

To support this, you will need to consider some key topics when re-assessing the strategic technical architecture:

1. Refashion – Use and extend the current architecture
   1. Confirm current architecture and establish a central register of systems, applications, services, & integrations. This should include a current system landscape, integration overview, and technical architecture to confirm the current use and overview of the existing architecture. Additionally, the operating model needs to be covered, from how developments or changes are managed through to how operation, observability alerting, or monitoring is handled.
   2. Assess opportunities and direction for applications and services – Having a methodology such as HCLTech’ FENIX 2.0 helps with this type of assessment, which should confirm the level of investment applicable per application and its potential roadmap in relation to business use and value.
   3. Detail and collate key influences on the enterprise architecture – The influences may have been previous or current business needs and/or IT preferences and design patterns to how the existing landscape was realized (such as main systems used, evolution of components or wider company acquisitions or disposals). Additionally, there is a need to collate and understand the underlying architectural principles or policies that need to be adhered to as well as expected architectural targets and objectives.
   4. Understand the security & resilience approach – How security and resilience is addressed can have a significant impact on the landscape (as well as Disaster Recovery and High Availability). Typically, these are already key focus areas, yet understanding the current status can influence what changes or improvements might be required.
   5. Data strategy definition – Data is a company asset, and data model, governance, and quality are all key to a reassessment. The target architecture must include key overviews of how data is modeled, managed, governed, and delivered consistently across the enterprise for both transactional processing and analytical needs.
   6. Confirm adopted architecture & frameworks - The current architectural frameworks and the principles they are reliant upon should be documented. These can be direct items from enterprise architects, or indirect items (for example underpinning core application or solutions already in use within the company). In addition to what has already been adopted, there are typically evolving items which can be supported (at least in some manner) in the current architecture, such as API use, and wrapping services to expose in open manner or moving items towards a more Cloud native delivery (such as Automation, DevOps, AIOps etc.). These additional items need to be included to confirm existing and potentially available architectural options.
   7. Detail organization status – The current knowledge, skills, and organizational setup will also influence existing and potentially updated delivery options. So, this may need not just documenting but potentially also formal assessment via methods such as the Dreyfus skills assessment.
2. Redesign – Applying newer architectural methods and solutions
   1. Collate current or expected initiatives & programs – Through collating these details, future requirements can be understood and included into any redesign considerations. This may include Digital Transformations, Cloud Enablement, Automation, IoT, Intelligent Enterprise delivery and Big Data/Analytic initiatives to provide new solutions, improve efficiencies, or reduce costs.
   2. Understand hybrid environment impacts – Likely, solutions and services will exist from multiple vendors as well as from bespoke corporate solutions across both direct solution delivery and in supporting development or operation. As such, the target architecture will need to support a hybrid environment with coordination and integration, but also for overviews and common approaches. Any updated architecture needs to define how it will be realized and operated in a hybrid landscape.
   3. Modernization expectation on updated principles, design patterns, & architectures – This modernization can be refactoring for the cloud, supporting composable solutions, or decoupling applications using design-driven solutions and a product focus with agile & DevOps delivery while also avoiding vendor lock-in and technical debt within systems. The target architectural principles and strategy would then be updated to consider the expected areas of modernization, which may have a wider impact than the smaller refashioning of the existing architecture. This can then lead to new approaches, methods, and tools with larger organizational change impacts.
   4. On-going improvement and development – The target architecture, requirements, and solution will not be static and the approach needs to address how ongoing change is supported through improvements or development over time. A level of change also needs to be designed into any delivery to avoid future barriers towards adopting new practices or solutions. This allows product or program delivery to adhere to architectural preferences with the ability to approve deviation and allow possible new capabilities to be identified and realized without adding excessive central constraints or overheads to business or technical teams.

I recommend that companies consider these factors and place relevant focus on delivering a transformational architecture that can work right across the enterprise. Overall, the architecture needs to support a level of refashioning of the current landscape in a pragmatic manner and yet also identify a route to a wider redesigned architecture that can support ongoing business solutions and technical delivery at a faster and more adaptable manner.

To complete any architecture overview, items such as key business requirements, future roadmaps, change plans, and organizational aspects would also need discussion and understanding. A partner such as HCLTech can complete these at the start of project engagements or as dedicated pre-engagement strategy or assessment tasks.

HCLTech would be keen to talk to companies that have large SAP-focused landscapes to help them understand how they could transform their delivery SAP enterprise architecture and capabilities.