EA Positioning
In my previous two articles (Enterprise IT Architecture and EA Principles), I described the Enterprise IT Architecture structure and methodology in place at my company, as well as provided a detailed description of the principles.
This article will focus on positioning and patterns, which are designed to support architects and solution engineers.
Positioning is achieved through a reference architecture, which can be considered a blueprint or play-book for the enterprise. It is split across seven layers (outlined below), with each layer including multiple complimentary enterprise technologies.
-
Security: Is enabled across the entire ecosystem, delivering consistent security controls such as identity, access management, threat intelligence and vulnerability management.
-
User Experience: Delivering an optimised experience to any end-point (web, mobile, wearable, etc.) It is fully decoupled from the application logic and content, enabling rapid evolution without any impact on the other layers.
-
Platforms: Focused on application and business logic, with an emphasis on microservices that are organised around capabilities. Also supports the deployment and hosting of commercial packages.
-
Information: Covering the traditional systems of record, data sources and content repositories, fully decoupled and accessed from source. The Data Layer also includes knowledge and analytic capabilities.
-
Integration Fabric: Includes a suite of integration capabilities, that act as the digital glue, connecting services through a commonly understood contract. The Integration Fabric also performs any required transformations and helps to maintain data linage.
-
Infrastructure Foundation: Includes commodity IT services that are critical for reliable and efficient business operations, covering workplace, collaboration, network, data centers, etc.
-
Delivery Tools: Includes a suite of tools to facilitate high levels of automation for IT deliverables.
The diagram below provides an overview of the reference architecture, which also forms the consistent foundation for all patterns. I have added example technologies to the reference architecture, helping to demonstrate how it can be used for enterprise positioning.
Architects and solution engineers leverage the reference architecture when buying or building technology. The goal is to align (where possible) with the enterprise standards, which reduces duplication and helps to maximise the return on enterprise investments.
The reference architecture also promotes a focus on customer experience. For example, instead of delivering multiple identity solutions (often resulting in multiple user logins), the reference architecture can clearly position the enterprise identity service. The same can be said for data insights, by reducing data duplication through clear positioning of enterprise data stores.
Similar to the principles, 100% adherence to the reference architecture is not an expected outcome, instead the hope is to proactively trigger the right solution architecture conversations. This statement is especially true for specialist areas (e.g. manufacturing), where niche technologies may need to be deployed.
As previously stated, the reference architecture is also used as a foundation for patterns, which describe how to leverage the enterprise technologies to meet specific use cases.
For example, the pattern below outlines a simple web application, targeting external customer engagement.
The pattern removes any technology that is not relevant to the specific use case, highlighting the core architecture (continuous lines), as well as the supporting architecture (dotted lines).
Knowing that a critical part of Enterprise IT Architecture is the ability to articulate complex solutions, the pattern provides a simple, consistent foundation to facilitate the story. Once widely adopted, architects and solution engineers will be able to quickly understand (high-level) almost any solution, simply by reviewing the pattern.
Finally, in common patterns, teams can leverage (or create) create accelerators (boxes highlighted in bold), which are code packages, modules and/or API endpoints. Accelerators can dramatically reduce development lead times, as well as improve quality and security through standardisation, however discoverability can often be the primary barrier (mitigated by the patterns).
In conclusion, the reference architecture aims to clearly position enterprise technologies, as well as proactively promote the principles. Individual patterns can then be created, using the reference architecture as a consistent foundation. This process encourages collaboration and reuse, as well as increases visibility and consistency across the enterprise.