Open in App
Dr Mehmet Yildiz

A Quick Taste To Enterprise Architecture

2021-02-24

The term enterprise architecture is widely used in technology news and articles. However, sometimes this term is misused and gives a wrong impression on readers. I decided to provide a high-level introduction to enterprise architecture in simple terms with examples to inform my readers.

https://img.particlenews.com/image.php?url=1zMd5t_0YiPJaBh00

Photo by Emiliano Bar on Unsplash

I have been practising enterprise architecture for a long time. Enterprise refers to organisations at a massive scale. Large business organisations are substantially challenged with rapid change in technology and the increasing demands of consumers.

Every large organisation that I worked for had some digital transformation and technology modernisation programs to some extent. Many of these initiatives were at the enterprise level.

Enterprise architecture is so critical that a failure caused by wrong architecture can have a massive impact on an organisation's financial and business results.

I witnessed several failed initiatives caused by multiple factors. Some factors were in their control and some beyond their control. One of the major causes of the failure was difficulty in dealing with complexity.

Enterprises have multiple dimensions spanning many business and technology domains. These domains are tightly interrelated; hence, a minor issue with one domain can impact many others.

For example, in a typical large organisation, the strategy and planning phase took over a year while hundreds of highly paid employees were churning and debating the ideas extensively.

Once the program executives and stakeholders finally reached a consensus on the scope and approached the requirements management phase, the program's entire budget 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 it is to approach technology modernisation iteratively rather than 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, test it with the allocated budget, and produced some desirable results.

Agile approaches are still foreign to enterprise architects and program managers.

The other reasons for failure are too much focus on challenging technologies to implement enterprise-wide due to inhibitive cost, lack of required functionality, and capabilities perspectives.

For example, while an organisation could have started testing Cloud Computing with a cheap public Cloud service offering and move their workloads iteratively, they were trying to build a full-fledged private Cloud platform with many emerging technologies and expensive gear.

Unfortunately, the hidden cost in such a monolithic approach destroyed all good intentions and cost millions of dollars to the organisations.

There are many more similar lessons learned from failure. Therefore, I want to share my experience of how these deadly business errors can be prevented with a different mindset, novel approach, innovative structure, supportive tools, and empowering technologies.

Let me define and briefly introduce Enterprise Architecture based on my knowledge and experience.

The Enterprise Architecture (EA) discipline in Information Technology (IT) defines a macro level IT architecture at the enterprise level. This unique and high-level architecture approach focuses on mapping technology capabilities to business needs using a governance method.

Traditionally, thought leaders used the town planning metaphor to define and visualise enterprise architecture. So far, this town planning metaphor is the most prominent explanation to provide a common understanding of enterprise architecture. I use this metaphor in my articles and papers to convey the message and clarify the abstract points.

The primary goal of enterprise architecture has been defining and describing the relationships, logical flows, business processes, activities, functions, data, information, applications, underlying technology, and supportive tools in large business organizations.

Leadership vision, business process, and project planning are the critical aspects of enterprise architecture.

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

An enterprise architecture framework has five distinct phases.

The phases in order of maturity are:

  • Initial phase,
  • Baseline phase,
  • Target phase,
  • Integrated phase, and
  • Optimised phase.

Enterprise technology modernisation initiatives must consider these five phases and deal with them both individually (component model) and in an integrated manner.

Enterprise architecture inherits several reference models to explain its fundamental domains. The most common models are:

  • BRM (Business Reference Model),
  • CRM (The Components Reference Model)
  • TRM (The Technical Reference Model)
  • DMR (The Data Reference Model),
  • PRM (Performance Reference Model).

These models cover six broad aspects:

  • Business capability,
  • Business functionality,
  • Technology standards,
  • IT systems,
  • Data descriptions, and
  • Quality measurements.

These models are well-established in various publicly available and proprietary methods. The popular frameworks in many of my solutions were:

  • TOGAF - The Open Group Architecture Framework
  • FEAF - Federal Enterprise Architecture Framework
  • Zachman

One of the most common enterprise architecture framework, FEAF (Federal Enterprise Architecture Framework) in North America, also uses the models I mention above. It is an established framework in use for a long time.

FEAF was established in 1999 by the Chief Information Officers in response to the Clinger-Cohen Act of 1996. The FEAF aims to facilitate the shared development of common processes and information among Federal Agencies and other government agencies.

Enterprise architects use several traditional methods for developing Enterprise Architecture solutions for large business and government organizations.

Some large organisations have their established proprietary methodologies used for internal purposes and not shared publicly.

Knowing an established method and understanding enterprise architecture principles 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.

Enterprise environments can be too involved 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 assume that we are dealing with a network system. We partition the overall network into 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.

Once we partition an overarching system, then we can start simplifying it to deal with complexity. Simplification is a broad technique. We can customise the process of simplification for different scenarios and activities. One way of simplifying a system is reducing the quantity.

Take the number of servers, for example; looking at a thousand 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 maintain its core identity. This book offers a chapter on the importance of simplification for enterprise modernisation as it is a critical factor.

After partitioning and simplifying, the third critical method is iterating. 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 results. If the effect is positive, we make progress and go to the next iteration. If the result is negative, we fail but learn how not to do it and try another iteration.

The positive side of this negative result is that we fail cheap, and we fail quickly. Failing cheap and promptly don't make a big difference from a financial and project schedule perspective.

In summary, we can remember these three basic methods using daily examples. For example, we have separate teams for different functions at work; this is the partitioning of groups.

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. I plan to cover them in my upcoming articles.

Thank you for reading my perspectives.

Reference: A Modern Enterprise Architecture Approach

If you enjoyed this story, you may check my other technology articles on News Break.

Internet of Things (IoT) Is The Next Big Thing In Our Lives

Introduction to Big Data Platforms

Why Big Data Matters And How We Define It

Discovering Millions of Free Datasets

Importance of Protocols And Standards For IoT Solutions

I Solve The Mystery of IoT and Explain It In Plain Language

Edge Computing Is Not As Complicated & Scary As You May Think

My View Of Blockchain Is Different Because I Design It.

How To Deal With Big Data For Artificial Intelligence?

An Overview of Business Architecture For Entrepreneurs

Remarkable Leadership Traits for Technology Executives

How To Design Data Lakes

Expand All
Comments / 0
Add a Comment
YOU MAY ALSO LIKE
Most Popular newsMost Popular

Comments / 0