The desire to modernise an enterprise business is often a familiar battle with legacy and technical debt. This article is the first in a series, which will explore the “art of the possible” if an enterprise business could hypothetically rebuild IT from the ground up.

Over the coming months, I will share my thoughts regarding the creation of a modern IT ecosystem. I will take on the persona of an enterprise architect, therefore the articles will predominantly focus on the architecture, technologies and positioning, however, I will also highlight key processes and methodologies.

Recognising that all good IT decisions must include business context, with a clear value proposition. I have defined the following hypothetical business characteristics.

  • Global Business (Americas, EMA, APAC)
  • Regulated Industry (Food and Drug)
  • Customers in 90+ Countries
  • Value Chain includes R&D, Manufacturing, Commercial and Global Services
  • 15,000+ Total Users (Employees and Contractors)
  • 170+ IT Users (Employees and Contractors)
  • 50+ Physical Sites Globally
  • 10+ R&D and Manufacturing Sites (24x7 Operation)
  • Established Traditional Business Model
  • Emerging Digital Business Model
  • $5Billion Revenue

Selecting a regulated industry (Food and Drug) enforces a set of rules, regulations and guidelines. This decision will impact the design of the ecosystem, but also hopefully add credibility to the analysis, recognising that the proposed architecture must meet a minimum set of standards, governing safety, efficacy, quality, privacy and security.

Throughout this series, I will use these business characteristics to inform my proposed architecture, as well as take into consideration other key business drivers such as maximising the return on investment.

IT Principles

Prior to any architecture decisions, I believe it is important to baseline the approach by defining a set of IT principles. These IT principles aim to drive better strategic decision making, by proactively triggering the right architecture conversations.

I have established four principles assigned to the “classic” enterprise architecture domains, covering Business Process, Information, Application and Technology.

IT Principles

The rationale behind having only four principles is to ensure that they could be easily consumed and remembered. As highlighted in my 2016 article “Enterprise IT Architecture”, architects tend to overanalyse, resulting in unnecessary complexity which could limit adoption and adherence.

IT Declarations

Although the IT principles provide a high-level direction, they could be difficult to translate into a tangible outcome. As a result, I have created a corresponding set of IT declarations, which aim to add additional context, reinforcing the target-state architecture.

  • Hybrid-Cloud: By default, Public Cloud must be prioritised over Colocation Data Centres and Edge Computing.

  • Open Source: By default, new applications must prioritise open-source technologies, with any proprietary technologies looking to maximise strategic investments.

  • Custom Developed: By default, new custom-developed applications must embrace a Cloud Native architecture (Twelve-Factor App and FAIR), prioritising FaaS and PaaS.

  • Commercial of the Shelf (CotS): By default, new Commercial of the Shelf (CotS) applications must embrace a Cloud Native architecture, prioritising SaaS.

  • Server Deployment: By default, new IaaS deployments must target immutable infrastructure, including ephemeral (short-lived) and stateless (do not persist a session) servers.

  • Automation: By default, new application deployments must be automated, leveraging build tools and/or automation services.

  • Datastores: By default, new managed datastores must prioritise open-source technologies, avoiding proprietary/licensed technologies.

  • Integrations: By default, new system-to-system integrations must leverage the approved Enterprise Integration Fabric.

  • API-First: By default, new applications must leverage open and documented web service APIs and/or Webhooks.

  • Client Plugins: By default, new client-side applications must be browser-based, avoiding the use of proprietary plugins (e.g. .Net Framework, Java, Flash, etc.)

  • Internet Accessible: By default, new applications must be accessible via the Internet, secured at source and in transit, removing the need for a VPN/VDI.

I would not anticipate 100% adherence to the IT principles and/or IT declarations. For example, specialised capabilities from R&D and Manufacturing, which commonly require proprietary software/hardware.

Modern IT Ecosystem

With the previously stated business characteristics in mind, the diagram below highlights my vision of a modern IT ecosystem. It is purposely “marchitecture” (a combination of marketing and architecture), used to communicate the desired end-state to a non-technical audience.

IT Ecosystem

The bullets below provide context to the diagram, describing the philosophy and intended direction for each area. As part of this series, I plan to analyse these areas (among others) in greater detail.

  • SaaS: Recognising the limited competitive advantage, all highly-industrialised/commodity capabilities would be positioned as SaaS. Examples include Productivity, Collaboration, Service Management, Customer Relationship Management (CRM), Human Resource Planning (HRP), etc.

  • Public Cloud: Public Cloud would be prioritised for all application/data hosting, emphasising “up the stack” services. For example, FaaS and PaaS would be prioritised over IaaS. The underlying architecture would strive to be cloud-agnostic, embracing a hybrid multi-cloud strategy.

  • Colocation Data Centres: Multiple Colocation Data Centres would provide support for capabilities that would not be commercially or architecturally a good fit for Public Cloud. For example, the previously mentioned, specialised capabilities from R&D and Manufacturing. The Colocation Data Centres would securely and dynamically connect to each other via a managed network backbone, which would also provide high-performance connectivity with key partners and Public Cloud providers.

  • SDDC: The infrastructure deployed within the Colocation Data Centres would be highly-converged, leveraging modular (blade-based) hardware that would allow compute, storage and network to be scaled independently (providing flexibility). All Data Centre resources and services would be software-defined, following modern Software-Defined Data Centre (SDDC) techniques.

  • ERP: Enterprise Resource Planning (ERP) would be fully managed (SaaS-like), but hosted in a specialised cloud that would ideally interconnect with managed network backbone provided by the Colocation Data Centres. Recognising the importance of ERP, this approach would aim to exploit the benefits of a fully managed service, whilst offering “LAN-like” performance, reliability and consistency. It would also help avoid unnecessary lock-in with a specific Public Cloud provider (AKA Hyperscaler), which could become a costly investment based on ingress/egress charges.

  • IAM: Identity Access Management (IAM) would support the Cloud (SaaS, Public Cloud), Colocation Data Centres and Edge Computing, providing flexibility and resilience for any application. Modern authentication and authorisation mechanisms would be prioritised, enabling single sign-on and password-less capabilities for users.

  • Automation: All cloud services (SaaS, Public Cloud), Colocation Data Centre and Edge Computing would be fully automated, leveraging Software-Defined techniques. As depicted by the “DevOps” cloud, the automation would be delivered via a unified suite of services, covering provisioning, governance, budgeting, discovery, testing, security analysis, quality assurance, documentation and change control.

  • WAN: The Wide Area Network (WAN) would utilise an SD-WAN architecture, simplifying management and operations, whilst enabling the use of commodity Internet circuits instead of traditional MPLS.

  • User Endpoints: Applications and services would be Internet-accessible, via the web and/or an API. This approach would simplify the endpoints architecture, removing the need for specialist hardware and/or software, whilst promoting a “consumer-like” experience covering any operating system (e.g. Windows, macOS, Linux, ChromeOS, iOS, Android, etc.)

  • LAN: Wireless technologies would be prioritised at the local sites, made available via a unified SSID that would dynamically provision access based on the endpoint conditions. R&D and Manufacturing would include strict segmentation policies, following the Purdue Reference Architecture, allowing for a clear separation of concerns and ensuring sensitive workloads could run autonomously.

  • Edge Computing: To support latency-sensitive applications at R&D and Manufacturing sites, edge compute and storage would be made available. Similar to the Colocation Data Centre architecture, Edge Computing would target a highly-converged (possibly hyper-converged) infrastructure, supported by software-defined techniques.

  • Information Security: A Zero Trust security model would be followed, localising and isolating threats through microcore, segmentation and deep visibility. To achieve this outcome, multiple technologies would be embedded as part of the wider architecture, including Layer 7 Firewalls, Network Segmentation, Agent-less Network Access Control, Data Loss Prevention, Privileged Access Management and a dedicated Security Operations Centre (SOC). These technologies would be complemented by a clear “least privilege access” strategy and appropriate governance, monitoring, auditing, etc.

Conclusion

Over the coming months, I plan to build upon this initial article, incrementally detailing the capabilities associated with my vision of a modern IT ecosystem. As highlighted in the framing, these articles will reference the previously defined business characteristics, predominantly focused on the architecture, technologies and positioning.

enterprise architecture enterprise_architecture ea modern_it_ecosystem innovation strategy lifeinwork