A Modern Enterprise Architecture Approach: Enterprise Architecture

Chapter 1: Introduction

Purpose of this book

THE REVISED VERSION of this book to provide essential guidance, compelling ideas, and unique ways to Enterprise Architects so that they can successfully perform complex enterprise modernisation initiatives transforming from chaos to coherence. This is not an ordinary theory book describing Enterprise Architecture in detail. There are myriad of books on the market and in libraries discussing details of enterprise architecture. My aim here is to highlight success factors and reflect lessons learnt from the field within enterprise modernisation and transformation context.

As a practising Senior Enterprise Architect, myself, I read hundreds of those books and articles to learn different views. They have been valuable to me to establish my foundations in the earlier phase of my profession. However, what is missing now is a concise guidance book showing Enterprise Architects the novel approaches, insights from the real-life experience and experimentations, and pointing out the differentiating technologies for enterprise modernisation. If only there were such a guide when I started engaging in modernisation and transformation programs.

The biggest lesson learned is the business outcome of the enterprise modernisation. What genuinely matters for business is the return on investment of the enterprise architecture and its monetising capabilities. The rest is the theory because nowadays sponsoring executives, due to economic climate, have no interest, attention, or tolerance for non-profitable ventures. I am sorry for disappointing some idealistic Enterprise Architects, but with due respect, it is the reality, and we cannot change it. This book deals with reality rather than theoretical perfection. Anyone against this view on this climate must be coming from another planet.

In this concise, uncluttered and easy-to-read book, I attempt to show the significant pain points and valuable considerations for enterprise modernisation using a structured approach and a simple narration especially considering my audience from non-English speaking backgrounds.

The architectural rigour is still essential. We cannot compromise the rigour aiming to the quality of products and services as a target outcome. However, there must be a delicate balance among architectural rigour, business value, and speed to the market.

I applied this pragmatic approach to multiple substantial transformation initiatives and complex modernisations programs. The key point is using an incrementally progressing iterative approach to every aspect of modernisation initiatives, including people, processes, tools, and technologies as a whole.

Starting with a high-level view of enterprise architecture to set the context, I provided a dozen of distinct chapters to point out and elaborate on the factors which can make a real difference in dealing with complexity and producing excellent modernisation initiatives.

As eminent leaders, Enterprise Architects are the critical talents who can undertake this massive mission using their people and technology skills, in addition to many critical attributes such as calm and composed approach.

Let’s keep in mind that as Enterprise Architects, we are architects, not firefighters! I have full confidence that this book can provide valuable insights and some ‘aha’ moments for talented architects like yourself to tackle this enormous mission of turning chaos to coherence.

Audience

THIS BOOK CAN BE AN ideal supplementary source for Enterprise Architects who engage in enormous enterprise modernisation and transformation initiatives as the first time. The guidance in this book can jump-start the process.  

Another target audience type could be IT architects who are planning to be Enterprise Architects and to undertake transformation and modernisation initiatives in complex environments and large organisations.

In addition to architects, this book can provide useful insights to IT executives like - CTOs (Chief Technology Officer), CDOs (Chief Digital Officer), CIOs (Chief Information Officer), and Head of Enterprise Technologies - who are responsible for substantial enterprise modernisation and digital transformation programs.

From an execution perspective, this book can be also helpful for the program managers and portfolio directors responsible for enterprise modernisation and transformation programs.

As a supplementary educative resource, this book can also be useful for students studying Enterprise Architecture and relevant disciplines who want to understand the practical aspect of the discipline, especially from the modernisation and transformation perspectives.

Lessons Learned from my Background

I HAVE BEEN PRACTISING enterprise architecture over two decades. Large organisations are substantially challenged with rapid change in technology and increasing demands of consumers. Every large organisation that I worked for had some transformation and modernisation programs to some extent at the enterprise level.

I witnessed several failed initiatives caused by multiple factors which could be in their control to some extent or beyond their control. One of the major causes of the failure was difficulty in dealing with complexity. Enterprises have multiple dimensions spanning to many domains with a multitude of stakeholders with overlapping or conflicting interests. These domains are tightly interrelated; hence, a minor issue or conflict with one domain can be reflected in many others.

For example, in a typical large organisation, just strategy and planning phase took over a year while hundreds of highly paid employees were churning and debating the ideas extensively. Once the program finally reached a consensus on the scope and approached the requirements management phase, the entire budget for the program was consumed.  The organisation had to make all those talented people redundant.

This typical and unfortunate example was a valuable lesson learned on how important to approach the modernisation iteratively rather than trying to perfect everything upfront. From hindsight, they could have set the strategy at a high level for a single domain and only plan one aspect of the strategy in the selected domain, tested it with the allocated budget, and produced some desirable results.

The other reasons for failure are too much focus on technologies which were challenging to implement at enterprise-wide due to inhibitive cost, lack of required functionality, and capabilities perspectives. For example, while an organisation could have started testing the Cloud with a cheap public Cloud offering and moved their workloads iteratively, they were trying to build a full-fledged private Cloud platform with many emerging technologies and expensive gear. The hidden cost in such a monolithic approach, unfortunately, destroyed all good intentions.

There are many more similar lessons learned from failure; therefore, I want to share my experience how these deadly errors can be prevented with a different mindset, novel approach, an innovative structure, and with use of supportive tools, and empowering technologies. Simplicity and agility must be the two powerful tools in our pocket.

Chapter 2: Fundamentals of Enterprise Architecture

Purpose

IN THIS CHAPTER, WE cover the fundamentals of enterprise architecture briefly so that we all think on the same page. In any business venture, principally, fundamentals must be met first so that further progress can proceed.

For this reason, we start with the definition of enterprise architecture within the modernisation and transformation context and introduce the fundamental techniques to deal with enterprise complexity.

In consecutive chapters, as another fundamental aspect, we touch on the changing and essential roles and responsibilities of Enterprise Architects for leading successful modernisation and transformation initiatives.

After setting these fundamentals, we highlight other necessary pillars in this novel framework. Now, let’s attempt to define enterprise architecture in our context.

Defining Enterprise Architecture

THE ENTERPRISE ARCHITECTURE (EA) discipline in Information Technology (IT) defines a macro level IT architecture at the enterprise level focusing on the mapping of IT capabilities to business needs using a governance method.

Traditionally, thought leaders used the town planning metaphor to define and visualise EA. So far, this town planning metaphor is the most prominent explanation to provide a common understanding of EA.  Therefore, now and then in this book, we use this metaphor to convey the message and clarify the abstract points.

The focus of EA has been defining and describing the relationships, logical flows, implementation of business processes, activities, functions, data, information, applications, security, compliance, underlying technology stacks, and supportive tools in the enterprise. 

Vision, process, and planning are the critical aspects of EA. These three significant aspects – vision, process, and planning- are driven by and closely aligned with business needs, capability, and requirements at the enterprise level.

EA has five distinct phases.  The phases in order of maturity are initial, baseline, target, integrated, and optimised. Enterprise modernisation initiatives must consider these phases and deal with them both individually and in an integrated manner. Our goal is to reach the optimised level realistically and in an iterative way.

EA has several reference models to explain its fundamental domains. These reference models are guiding documents and can help us understand each domain at least at a high level.

The most common models are BRM (Business Reference Model), CRM (The Components Reference Model), TRM (The Technical Reference Model), DRM (The Data Reference Model), PRM (Performance Reference Model).

These models cover business capability, business functionality, technology standards, IT systems, data descriptions, and quality measurements. These models are well-established. For example, one of the most common EA methods, FEA (Federal Enterprise Architecture), also uses these models. These models can be viewed from Enterprise Architecture textbooks and establish method artefacts’ in your organisations. Due to the limited scope of this book, we cannot go into the details of these basic models.

There are many traditional methods for Enterprise Architecture. The popular ones are TOGAF, Zachman, and FEA. Some large organisations have their established proprietary methodologies which are used only for internal purposes and not shared publicly.

However, knowing an established method and understanding the principles of enterprise architecture in a broad sense, Enterprise Architects can quickly learn other proprietary methods by reviewing them and working with the actual work-products in a relatively short time.

Managing Enterprise Complexity

ENTERPRISE ENVIRONMENTS can be extremely complex with multiple layers of systems, technologies, tools and processes. One of the critical roles of Enterprise Architects is to manage complexity. There are different approaches and techniques to manage complexity in enterprises.

The most common simplification technique is the partitioning approach. Some Enterprise Architects may use different terms for partitioning such as dividing, subdividing, segregating, and apportioning. These alternative terms all mean the same thing.

The process of partitioning refers to making smaller parts of a large object. Let’s say that we are dealing with a network system. We partition the overall network to smaller groups such as a wide-area network or a local-area network. We can partition the wide-area network from tools perspectives such as routers, switches and other devices.  Dealing with smaller parts can be more comfortable, faster, and more economical.

Once we partition an overarching system to smaller components, then we can start simplifying each component to deal with embedded complexity in the specific component.

Simplification is a broad technique which can be applied to different objects and circumstances. We can customise the process of simplification for different systems and activities by understanding its nature, function, purpose, and relationships.

One effective way of simplifying a system is reducing the quantity. Take the number of servers, for example, looking at a thousand units of servers, and ten servers can make a massive difference.

Another technique could be moving an item from a large group of the clustered items but still, keep the relationship to keep its core identity. Due to importance of simplicity, this book offers an entire chapter on the importance of simplification and simplifying various aspects of the architecture for enterprise modernisation Simplification is a critical factor for change.

After partitioning and simplifying the third critical method is iterating. Probably you heard a lot about this term while working with agile methods. Iteration is progressing activities in smaller steps and chunks. Iteration is one of the best approaches to deal with complexity and uncertainty.

Moving with iterative steps, we achieve some tangible results. If the result is positive, we make progress for our goal and go to the next iteration. If the result is negative, we fail but learn how not to do it and try another iteration.

Paradoxically, the positive side of this negative result is that we fail cheap, and we fail quickly, as touted by many wise entrepreneurs.  Failing cheap and quickly don’t make a significant negative difference from a financial and project schedule perspective. As iteration or iterative approach is so critical in enterprise modernisation, this book offers a chapter on Agile methods and approach for successful modernisation initiatives.

In summary, we can remember these three basic methods using daily examples such as we have separate teams for different functions at work; this is partitioning of teams. We only belong to a single nation; this is a simplification. We plan for a school or certification exam chapter by chapter; this is iteration. There are also different tools that we use for these techniques. In various chapters of this book, we will cover and unfold them.

Enterprise Solutions Cost

EVERY ITEM IN ENTERPRISE modernisations and transformation activities generates substantial cost. There are known and hidden costs.

It is relatively more comfortable to deal with the known costs; however, the challenge is to deal with the hidden costs. Hidden costs are the more substantial part of the iceberg.  

Even though the cost of projects is managed by project managers and financial teams, Enterprise Architects are expected and need to find ways to make enterprise modernisation solutions inexpensive, affordable and lowering the cost gradually without compromising quality. Quality considerations are the critical requirements of enterprise modernisation initiatives.

There is a common perception that making solutions cost-effective without compromising quality is not possible as a considerable number of trade-offs are made in the architecture development phase. It is true that there are many challenges and factors to be considered to achieve this goal.

However, the solution cost can be reduced by making trade-offs with a methodical approach by obtaining collaborative input from business and technology departments. We can also use the Agile approach appropriately. It is possible to increase the quality of the solutions by applying professional diligence, architectural rigour, delivery agility, and smart collaboration. These principle-based approaches are critical to maintain and increase quality.

Enterprise Architects need to participate in cost model development proactively. For example, we must develop a solution Bill of Materials (BOM) once we set the solution strategy and complete all high-level design artefacts. The BOM may include hardware, software, other procurement, and services costs. This BOM can provide useful insights into the funding and sponsoring executives about the cost of our initiatives; however, other stakeholders want to use this BOM for different purposes.

For example, there may be tremendous pressure from project managers and procurement staff to generate an upfront BOM to meet the project deadlines. No one wants to get blamed for any delay in an organisation; hence, there may be a huge rush to get things in place quickly. However, we can point out that without an approved architecture, no BOM can be formalised and released. This assertive and straightforward input from the Enterprise Architects can save a considerable amount of funds to the enterprise modernisation programs or save wasting well controlled and tight budgets.

There are extensive infrastructure and maintenance costs in the enterprise associated with large data centres, server farms, IoT devices, Mobile BI,