This article is part of a series. I would recommend reading the articles in order, starting with “Modern IT Ecosystem”, which provides the required framing.

As a brief reminder, this series aims to explore the “art of the possible” if an enterprise business could hypothetically rebuild IT from the ground up, creating a modern IT ecosystem.

The previous articles have focused on design, technology, positioning and delivery. This article will highlight my proposed enterprise architecture methodology, including the organisation structure and processes. The article builds upon concepts I explored in my 2016 series, focused on Enterprise IT Architecture.

These articles are not required reading, simply shared for reference.

Introduction

As per the 2011 Wall Street Journal article, “Software is Eating the World”. To some extent, every business, across every industry, must now consider itself a technology business. Therefore, every business strategy must inherently prioritise a digital business model.

As referenced by Simon Sinek, as part of the popular The Golden Circle framework, Information Technology has the potential to have a profound impact on the “HOW” and “WHAT”, powering the business vision (WHY).

The Golden Circle

Referencing my previously defined business characteristics, I believe that any business with an emerging digital business model must look to leverage the expertise and experience that undoubtedly exists within IT. In parallel, IT organisations must look to maximise their value contribution by proactively prioritising business outcomes. Therefore, a generic vision for IT could read:

*“Partner to create value through innovative digital products, services and insights, that help to ."*

To enable this vision, a direct and continuous connection must be established between the digital products/services/insights and the business outcome. I would position a “product mindset” as a key philosophical approach, evolving from the traditional “project mindset” that is common across IT.

  • Project Mindset: A way of funding and organising the delivery of a specific output with a fixed end date.

  • Product Mindset: Designed to continually create value throughout the lifecycle of a given product.

This philosophy would incorporate key industry concepts, such as product ownership, product teams, iterative planning, continuous improvement and continuous investment.

In short, instead of focusing on a fixed output, a product mindset would focus on the outcome, which would have a profound impact on how the business organises, governs and funds IT.

The diagram below highlights my proposed IT organisation design, supporting 170+ IT users.

IT Organisation

Enterprise prioritisation and a focus on maximising value would help ensure that resources were effectively utilised, directly and holistically supporting key business outcomes. Outlined below is a summary of each team, including the high-level roles and responsibilities.

  • Business Relationship Management (BRM): Accountable for product ownership (including product vision, backlog, lifecycle, communications), as well as enterprise governance, prioritisation and budgeting. BRM would represent the “digital vision” as part of a given business outcome, fostering the required business relationships, expertise and context. This holistic enterprise approach supports my belief that IT must aim to maximise its value contribution, being positioned as a differentiator and driving competitive advantage.

  • SolutionOps: Accountable for application solution design, delivery and operations, across all business functions, supported by an enterprise Application Managed Services (AMS) provider. SolutionOps would incorporate purchased (Commercial of the Shelf) and custom-developed applications, following a “DevSecOps” culture, with a focus on Continuous Delivery, Testing and Quality. SolutionOps would also be accountable for maintaining Line of Business Apps (commodity/highly-industrialised), allowing for the consolidation of common practices (e.g. release management, regression testing, data integrations and data obfuscation). In theory, this approach would drive economies of scale and efficiency, reducing the risk of duplication, as well as promoting standardisation and re-use through techniques such as innersourcing.

  • DataOps: Accountable for enabling an automated, process-oriented methodology that facilitates the design and delivery of Enterprise Data and Analytics. DataOps would include data architecture, engineering and stewardship, ensuring data is discoverable, consumable and reusable, as well as enabling advanced data concepts such as Predictive Analytics, Machine Learning and Artificial Intelligence. This dedicated focus on data respects the importance of data as a critical business asset.

  • TechOps: Accountable for the design, delivery and operations of enterprise IT foundations, including infrastructure, platforms and local site operations. TechOps services would be made consumable via the Automation (e.g. Cloud Direct and Cloud Brokered), enabling autonomy for SolutionOps and DataOps. This approach would help to maximise investments, as well as embed consistent information security, quality and privacy controls.

  • IT BusinessOps: Accountable for the enterprise management of financials, suppliers, resources, organisational change and the portfolio. IT BusinessOps would work alongside representatives from each team (BRM, SolutionOps, DataOps, TechOps, Information Security), looking to measure and maximise value across processes, policies, investments, financial planning, etc.

  • Information Security: Accountable for establishing and governing information security requirements, as well as protecting enterprise confidentiality, integrity and availability. Similar to Privacy and Quality, Information Security would be positioned as an embedded practise, therefore, this dedicated team would focus on providing specific expertise and external council, supporting the implementation of the previously described Zero Trust IT security model.

Although the organisation design highlights a horizontally split (enterprise teams), the actual work would occur vertically (product teams).

IT Organisation - Product Teams

Product teams would be formed organically, based on the enterprise backlog, prioritisation and budget.

Each product team would include appropriate business expertise (split across Customer, Product, Operations and Corporate), as well as a cross-section of skills, covering product ownership (BRM), application (SolutionOps) and data (DataOps) engineering, as well as consultancy from domain experts (TechOps and Information Security).

The ability to scale elastically would be achieved through the Application Managed Services (AMS) provider, providing access to engineer and specialist resources.

Architecture Community

Building on my 2016 article “Enterprise IT Architecture”, the Enterprise Architecture Community (emphasis on the community) would be a virtual team, including representation from across the organisation.

Enterprise Architecture Community

The community of architects, each with specific expertise (e.g. business, solution, data and domain architects), would ensure enterprise architecture remains relevant, practical and delivering against a clear value proposition. Each architect would represent their area of expertise, providing thought leadership and contributing towards the enterprise outcome. This approach positions architecture as a core part of the end-to-end product lifecycle (not a disconnected team and/or set of processes), which helps to ensure strong business continuity and situational awareness.

The goal of the Enterprise Architecture Community (EAC) would be to provide a “north star” for the enterprise, through the creation of principles, declarations and clear technology positioning via an enterprise reference architecture. Each member of the community would be accountable for distributing the enterprise direction, recognising that architecture as an embedded process, not restricted to those with “architect” in their title. This approach would promote the strategic direction of IT and the business by proactively triggering the right architecture conversations.

The diagram below highlights my proposed Enterprise Architecture methodology, with key components being owned by Enterprise Architecture Community, leveraged by a product team (specifically engineers) during the design and delivery of a new solution.

EAC Methodology

As highlighted in the article “Modern IT Ecosystem”, I have defined four IT principles for each architecture domain (e.g. Business, Information, Application and Technology). These IT principles have been designed to be easy to consume, remember and adopt, targeting all of IT. The article also includes IT declarations, which build upon the IT principles, providing additional context.

To help ensure a direct and continuous connection between IT and the business outcomes, business capability mapping would be positioned to highlight all required capabilities across the value chain (e.g. Research & Development, Manufacturing, Commercial and Global Services). Any enterprise capability (leveraged by multiple parts of the value chain) would be mapped to the Enterprise Reference Architecture and positioned against key technology investments. This process would help to maximise the return on investment, whilst enabling standardisation and promoting re-use.

EAC Reference Architecture

Recognising the number of enterprise capabilities, I have split them into the following categories to simplify consumption and maintenance.

  • Security / Risk
  • Customer Management
  • Employee Management
  • Supplier Management
  • Process Management
  • Document Management
  • Data Management
  • Asset Management
  • Engineering
  • Communications
  • Enterprise Infrastructure

Finally, I have defined the following process to govern enterprise architecture, placing an emphasis on the previously described IT principles, IT decelerations and reference architecture.

EAC Process

The Enterprise Architecture Community would be positioned as an enabler, not a barrier (something that adds unnecessary bureaucracy). Therefore, the process promotes and incentivises architecture alignment, rewarding the product teams with autonomy (no review required), resulting in speed to value and agility.

Conclusion

I believe this lightweight/embedded approach to enterprise architecture promotes the right behaviours, avoiding the trap of creating an “Ivory Tower”, where the value proposition of architecture would be quickly lost.

The approach does not follow a specific architecture methodology (e.g. TOGAF, etc.) Instead, I have taken the best bits from multiple sources, rightsizing based on my previously defined business characteristics.

enterprise architecture enterprise_architecture ea enterprise_architecture_community eac modern_it_ecosystem innovation strategy lifeinwork