Co-authored by : Shobha Gujjari
During the pandemic lockdown of spring 2020, Netflix added another season of its beloved Spanish series, Money Heist. Now if that is unheard to you, chances are you would have at least seen Ocean's 11. A common link between these, or for that matter any heist movie that you deem worthy of mention, is the use of blueprints – the guide, pattern, or design for building anything. The use of civil architectural drawings has been around since as early as the 9th century aimed at bringing to fore a designer’s imagination and translate it to a 3D reality. Parallels between physical architecture and software architecture came into being in the late 1960s and since then software architecture has evolved into a blueprint of a conceptual software system, to be used by development teams to build the system.
Toward the end of the 3rd industrial revolution and with the advent of Industry 4.0, there has been a rising need to overhaul long standing software solutions, due to major economic transformation and unbridled technical advancements. These motion forward disruptions have impacted, but are not limited to federal IT systems, core banking software solutions, legacy logistics applications, integrated healthcare solutions, and multi-channel retail management systems. The focus then moves from just software blueprints to encompassing strategy, business processes, stakeholders, impact analysis, information structures, goals, and outcomes. Enterprise Architecture, though born much earlier, gained momentum as a response to this changing business landscape.
What is Enterprise Architecture?
Gartner describes Enterprise Architecture (EA) as “a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes.” Architecture that brings in the critical parameter of business to technology decisions. To understand some of the benefits that EA can bring to IT solutions, specifically, large scale transformation initiatives, it is worthwhile to evaluate some of the existing modern EA methodologies or frameworks. Detailed below are two of the most popular ones:
- The Zachman Framework
The Zachman Framework was created by John Zachman in 1987 and is one of the first EA frameworks that was ever published. This framework revolves around two sets of perspectives detailed in a matrix form – 6 types of stakeholders or perspectives on the rows and on the columns, Kipling’s 6 honest serving men “the 5 Ws and an H” as focal questions:
Business Functions and KPIs
Cross function interactions
Business Sponsors Organization Hierarchy
Enterprise Goal and Objectives
Business Services and Business Objects
In-scope Business System
Feature Execution Schedule
Conceptual and Logical Data Model
Solution and Application Architecture
Functional and Non-functional Requirements
Physical Data Model, Application Service Contracts
Technology Architecture & Deployment
Data and event definition
Data & Metrics
The interconnected matrix that is formed between these 12 parameters provides a structure to effectively capture operations of an enterprise from the strategic layer driving towards standardized execution.
- The Open Group Architecture Framework (TOGAF)
According to The Open Group, which first developed in 1995, TOGAF is one of the most popular EA frameworks used in the industry currently. TOGAF is a comprehensive framework offering an entire gamut of principles, guidance, standards/best practices, reference models, governance methodologies, and tools to practitioners embarking on their architecture journey.
TOGAF focuses on four primary architectural domains:
- Business Architecture
- Data Architecture
- Application Architecture
- Technical Architecture
TOGAF introduces the concept of Architecture Development Method (ADM) to develop and manage the key aspects of architecture, as bulleted above, along with other iterative concepts – with requirements management at its core. ADM, along with TOGAF’s Architecture Content Framework and Reference Models provide the kick start that new architects can leverage and customize based on organization goals and customer maturity. The business architecture domain is a prerequisite for the other three architecture domains and defines the business strategy, organization, governance and processes for the entire landscape.
There are a few others such as Federal Enterprise Architecture Framework (FEAF) which is one of the latest attempts established to capture the architectural blueprints across the enterprise. The FEAF was published by the US Federal Government first in 1999 and then updated in 2013. In 2005, Gartner jumped into the EA bandwagon and established its own guidance on EA frameworks – the Gartner EA Process Model. Not a framework by itself, the model provides a pragmatic approach to business and solution architecture, emphasizing on a holistic current state analysis of existing systems before arriving at a future state while cognizant of environmental trends and overall business strategy. There is also The Unified Architecture Framework (by OMG) that was initially developed by the Object Management Group to establish standard and consolidated EA practices based on US DOD Architecture Framework (DoDAF) and the UK MOD framework (MODAF) and aims to evolve into a more widely used industry agnostic framework.
So, do they work?
The end goals, as espoused by the founders of Enterprise Architecture Concepts, are noble in theory:
- Bridges the gap between strategy and execution
- Breaks functional siloes and create a holistic business landscape
- Streamlines analysis of complex business scenarios
- Provides business blueprints from multiple perspectives
- Elaborates a go-to framework, easy to adopt and modify
- Define purpose and transparency between the business and IT architecture
- Drives IT transformation and provides a method to the madness of it
In reality, deriving the benefits of leveraging enterprise architecture (primarily business and technology) is as twisted to comprehend as the frameworks themselves. As practitioners ourselves, we present our take on what works and what doesn’t!
- Over selling “THE” framework: Neither true business nor the technically savvy buy into the frameworks when they seemingly encourage complexity of upfront current state analysis thereby extending timelines of actual execution
- Focusing on size of initiative, org culture, and business needs, setting high level business context (what business capabilities or functions are in scope, and who uses them) and moving on to target state establishment (how processes work, what information is used to make them work) is a more realistic approach that can be gleaned from any of the frameworks
- Lead architect capabilities mismatch: When adopting enterprise architecture, it is imperative for the enterprise architect to not just be a technology lover, but also someone who is inclined toward understanding the business domain. Having a strategic mindset will enable that all critical executive buy-in towards the architecture concept
- Being process driven, not outcome driven: Organizations embarking on transformation journeys make it a goal to adhere to process established by a framework, rather than adapt to changing timelines, budgetary constraints, and newer risks
- A conscious effort to notice patterns in what works and what doesn’t and then adjusting by cutting noise to ensure outcomes are delivered in line with the overall business goals
- Lack of feedback loop from all relevant stakeholders: Architecture is treated as larger than life and in the process, focus is lost on the true consumers of architecture content. This results in weaning impact of even the most relevant architecture steps
- Move on from creating content because it is defined, to creating content as used by various stakeholders – short term content, as leveraged by currently executing teams, and long living content, as used by future users and change management/support teams
To use a classic adage, business architecture and technology architecture are two sides of the same coin. While technology architecture captures the inner mechanisms of a system, identifies the technical know-hows, and provides a ready model to plug in future enhancements, business architecture provides the contextual, conceptual, and logical blueprints depicting the driving force behind the final technological outcome. Both together, when done right, can help organizations align, accelerate and attain their business goals in line with the next unforeseen change!